Modern Architecture Paradigm — A quick guide to identify when to use what..
Microservices, Serverless computing & Containerization
In today’s digital age there is no dearth for tech terminologies and they are being used so randomly that at times it can make you feel exhausting.
If you have worked in a cloud environment or been around a modern IT team, you are likely to have heard either or all of the terms “Microservices”, “Serverless” or “Containerization”. They all popular approaches to building and deploying modern software applications. But if you are an architect starting out to think when to use what this article is for you..
Serverless architecture is a way of building and running applications and services without the need to provision and manage servers. Instead, the cloud provider is responsible for managing the infrastructure and scaling the resources required to run the application. Serverless can reduce costs and increase scalability, but also has limitations on the types of workloads that can be run and the amount of control over the infrastructure.
Containerization is a way to package and deploy software applications in a portable and consistent way. Containers allow for easy deployment and scaling of applications, as well as improved isolation and security.
Microservices is an architectural style that structures an application as a collection of small, independently deployable services. Each service is responsible for a specific business capability and communicates with other services through well-defined interfaces.
In this article we would like to give you a glimpse of these concepts and provide real examples of when to use what based on our experience. Let’s go straight into it.
To understand the evolution of these architecture styles you have to go back a few decades…
The Conway’s Law
Conway’s Law is a theory by Melvin Conway in 1967, stating that:
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
This means that an organization’s output will be directly related to how it communicates internally. The Conway’s law can be looked at from two perspectives.
1) Applying the law while developing software applications
Small distributed teams are most likely to produce modular service-oriented architectures. In contrast, large co-located teams are most likely to create monolithic architectures. The progression from a monolithic architecture to virtualization to containerization is a common pattern in the evolution of software systems. The same can be related to big large teams to lean agile teams creating software.
A monolithic architecture is a software design in which all components are tightly integrated and interdependent, making it difficult to change or update individual parts without affecting the entire system.
Virtualization is a technique that allows multiple virtual instances of an operating system or application to run on a single physical machine, each with its own dedicated resources. This allows for more efficient use of hardware resources and greater flexibility in deploying and managing software.
The evolution of Virtualization paved way to Containerization. A technology that allows for the packaging of an application and its dependencies into a single container that can run consistently across different environments. Containers provide a lightweight, portable, and isolated environment for running applications.
While you can in theory containerize all applications but they key is to associate it with the right business value. The return on investment for containerization is a key aspect for you to determine which applications require containerization. Also, the picture below provides some examples and associated complexity of candidates for containerization purely based on the workload characteristics.
2) Application of the law while creating communication structures within the organization
Driven by container technology’s success, microservices have become a fashionable item to have and are being used in ways they really shouldn’t. Organizations are turning once-centralized monoliths into confusing, newly-distributed monoliths.
If your architecture is distributed, but your Integration still relies on a centralized team managing a centralized technology like an enterprise service bus (ESB), the business goals of microservices can be negated.
So what are Microservices and what's it got to do with Containerization?
Let’s look at a few scenarios
Scenario1: A large bank whose IT systems were built over time on multiple technologies and operating systems. The cost of technical upgrade to the applications and underlying operating system is high with no business value. Their hybrid cloud strategy demands the applications to be future proofed without tying with the underlying Infrastructure in order to rationalize them at a later point.
The best cloud strategy for them would be to choose a containerization tool (such as Docker) which will give them the ability to remove the dependency with underlying infrastructure and hence contain cost. The docker could be hosted on a Cloud based container or on premises depending on the Infrastrcture strategy of the company.
The picture below depicts the key challenge, business objectives and solution that can be adopted by the organization.
The key is to measure the business value of containerization that requires equal balance between benefit and cost measurement.
Scenario2: A brick & mortar retailer who wants to increase the online presence from a mere x customers visting to 10x customers. The retailers systems are built on monolithic technology deployed on the cloud.
Well there are a number of ways you could suggest to handle this situation. One of the key aspects of growing business is the ability to build systems at scale. Its hard for large teams to continue to build on Monoliths and hence Microservices is a key technology construct that could help in breaking a monolith into smaller managable set of applications / services. This helps in independent delivery of each product, scaling of different product streams of the retailer. Leveraging microservices coupled with a container and orchestration service such as Docker and Kubernetes will help the retailer gain the best of all worlds.
Scenario3: An electricity company wants to Digitize their customer facing operations. They expect infrequent loads typically peaking during the billing cycle of their customers and lower traffic otherwise. The application works with a System of Record which is optimized to respond in millisecond and typically the electricity company serves the customers with their requests in near real-time with no long running processes. The company has very little in-house IT/Infrastructure experts and would like an out of the box solution without any need for detailed setup
Serverless is the best fit for the requirement. Serverless is usually out of the box from the cloud provider with very little setup required. It is ideal for infrequent loads and short running process as it is billed for the time for which the request is processed and hence will be very cost effective for short processes.
Recap
Let’s do a recap of what we have seen
Authored by Arun Srinivasan & Srinivasan Padmanabhan
References
