Over years of building software, distinct architectural patterns have emerged. As newer technologies get introduced, we move to keep pace. Here, we compare and contrast some of the characteristics and benefits of each iteration.
Applications based on monolithic architectures were developed and deployed as one large unit on shared infrastructure. The code might have been split up into components in the development phase, but they were tightly-coupled, meaning deployments are all-or-nothing. Versioning of releases was done at the application level. When problems arose in one area of the application, the whole application needed to be rolled back. Deploying new functionality required long planning and tedious approval processes across different teams. Deployments followed longer release cycles.
With the advent of Web Services, applications based on SOA became popular and gradually replaced monolithic architectures. In practical use, the ubiquitous Web services standards enhanced the mainstream appeal of SOA design. With beginnings in client-server or n-tier architecture, the 3-tier architecture became most popular, with distinct separation of concerns via presentation, business logic, and data tiers.
The presentation tier encapsulated the UI or the front-end, the business logic was kept decoupled in the logic tier, and the data sources abstracted behind the data tier. With each layer decoupled from the other and remotely accessible via Web Service APIs, they could be deployed and scaled independently of each other. This also encouraged reuse of the business logic and data tiers across different presentation views, i.e. a web site and a mobile front-end.
Smaller groups with specialized skill sets formed teams that were aligned to the tier they owned. Decisions regarding infrastructure, planning, and approval were scoped to fewer individuals. Releases for each tier could be versioned and deployed independently. In the case of failure, rollbacks were limited to the tier in question. Deployments of new functionality were quicker, less risky and each tier could follow its own release cycle.
The last couple of years has seen the advent of microservices architecture, which still preserves many tenets of SOA. In essence, a lot of time and effort was being wasted in managing servers and subsequent scaling of applications; microservices architecture allows teams to break an application into fine-grained, smaller services. They can communicate using a lightweight protocol. Microservices mean teams can develop, test, deploy and scale each service independently. As we saw with SOA before, even smaller, more autonomous teams tend to emerge.
The notion of being serverless took off when AWS launched Lambda in late 2014. The benefits were too good to ignore: serverless computing let you have a microservices architecture in which it wasn't necessary to manage underlying infrastructure. The provider would auto-scale your application in response to load.
Serverless architectures are really opinionated microservices architectures. It's a combination of FaaS (Functions-as-a-Service) for compute and MBaaS (Mobile Backend-as-a-Service) for everything else: authentication, databases, search, cache, CDN etc. The focus of application development changed from being infrastructure-centric to being code-centric.
Serverless architectures have radically changed how applications are being built and deployed at scale. It has caused teams to interact with increased autonomy and higher productivity. Decomposing microservices into functions has led to decoupling at a finely-grained level, and given developers the flexibility to map functions to events that bubble up from disparate sources.
Taking advantage of the event-driven nature of serverless applications, many use cases became relevant. Widely popular use cases being data processing, SPAs, Mobile and IoT applications, chat bots, event workflows to name a few.
Credits: Rupak Ganguly (@rupakg)