Serverless (01) — RPC to Serverless. How did we get here?
A software system can not work efficiently in a silo. To build a complete system, various applications need to communicate with each other.
In the last 3 decades, I’ve seen many paradigm shifts in the principles of Software System Architecture just to incorporate the changes in intercommunication techniques.
Here is a quick summary of some major intercommunication technologies.
RPC-RMI-CORBA-SOCKETS
RPC (Remote Procedure Calls) and RMI (Remote Method Invocations) were the prehistoric communication techniques for Gen-Z. :-).
ORB/CORBA (Common Object Request Broker Architecture) is the earliest thing that I can remember. But they had tight coupling with client and server details.
I even remember in the first job I wrote a few Java applications, where I used to open server sockets in a different thread and used to ping those pre-known sockets from client applications. This all jazz was just for facilitating communication between a few in-house applications.
EJB
In 1997, IBM released EJBs to the world. It was quickly embraced by the java community and became a de-facto standard for designing java-based enterprise application systems.
EJB used to be of three types, session beans, entity beans, and message-driven beans (MDB).
Entity Beans were the representation of a persistent entity, MDBs were pieces of codes that could be invoked upon reception of a message on a configured JMS queue or topic. Everything else fell under the umbrella of the Session Beans, which contained business logic. They were further divided into two subtypes, stateless & stateful session beans.
MDB was the best way to communicate, but MDB required a dedicated infrastructure, it wasn’t a cloud-era infra was not an easy thing to procure. So sometimes we used to have non-JMS-based communication between internal applications, which required a plethora of configurations.
We also used to create client jars, containing remote interfaces and some lookup code. The client jars were then distributed to the applications wanting to call the server running business logic with EJB.
SOA-ESB
Little later SOA (Service-oriented architecture) gave birth to a new thought process, we started designing decoupled systems, by designating specific responsibilities to specific applications, we called these applications web services.
Various vendors leveraged this new decoupled architecture principle and flooded the market with proprietary middleware solutions in that era.
They gave them a fancy name ESB (Enterprise-Service-Bus). ESBs became an integral part of big enterprise systems to integrate heterogeneous applications.
SOAP
The commonly used mechanism for interacting with web services was SOAP (Simple Object Access Protocol). We called these web services SOAP services.
But there was nothing simple in the Simple Object access protocol, even with the autogeneration from IBM Rational Application Developer and eclipse plugins, it was cumbersome to work with the SOAP services.
Until this time, the enterprise java work was directed by Vendors, and their specifications, having a lot of the product lock-in code & configurations.
REST
The first step towards the giant leap, was in the year 2000, when Roy Fielding, came up with this doctoral dissertation for his Ph.D. I highly recommend reading at least chapters 4 & 5 if not all.
This was the birth of REST (Representational State Transfer)
It took some time for this Ph.D. dissertation to be implemented in the enterprise world. Until then, XML-based SOAP was the main method for WebService interaction.
APIs
Salesforce created the first XML-based API in the year 2000. And that started the ubiquitous ”***" AS A SERVICE business model.
Very soon eBay created the world's first Public API with REST principles. This was to help embed their products on different websites, and in the second half of the first decade of the 20th century REST web services became the de facto standard for public APIs
Microservice
Another major step toward the future was in the year 2005 when Peter Rogers introduced the term Micro-Web-Service in one of his seminars. But that's all for the first decade, nothing major happened on this front in the open space.
In 2011, during a workshop, a bunch of Software-Architects used the term Microservice to describe an architectural style that many of them had been exploring. And in 2013, Fred Geroge & James Lewis from Thoughtworks presented their different case studies with Microservices design.
Soon Netflix presented to the world, how they had already migrated their system to the AWS (Amazon web services) cloud infrastructure, following the fine-grained SOA principles, everyone was calling that Microservices. Very soon under the umbrella of Netflix-OSS, they open-sourced many of the useful code & libraries they used.
This was the first domino that burst the whole world in the second half of the second decade of the 21st century. The world never looked back. Every enterprise, big or small, migrated its systems to the cloud, with Microservice architecture.
Serverless
As they say, what's new today will be old tomorrow. Unlike other industries, in the software world, things don’t get old/obsolete in years but months or sometimes in weeks. “Microservices” The hottest thing in town, the solution to all problems also lost its charm (in some cases).
In the era of pay-per-use infrastructure, people did not want to pay for the time their applications are not in use. They thought for quick tasks, wouldn’t it be great if we can run the server only to perform the task. And do not use any infrastructure when there is no processing happening. And that's where serverless comes into the picture.
Not sure why It's called Serverless, there is still a server where our code runs. Maybe it was named because you can worry less about the server.
Cloud providers have provided the mechanism to pay by execution time. AWS Lambda, Google Cloud Functions & Azure Functions are some such offerings from three big cloud providers Amazon, Google, and Microsoft respectively. Here we provide the code/Function and the event to trigger that code/Function and we are billed only when it's triggered and processed.
That's all for now, this is all about the journey that I’ve lived in software system communication techniques. I have never worked on Azure functions so can not write anything about it, but I have a few posts for AWS lambda and will write something for Google Cloud Functions soon.
Stay Tuned.
