The Cloud Native Computing Foundation defines Cloud-native technologies as tools that empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. Cloud-native systems are designed to embrace rapid change, large scale, and resilience.
In the cloud-native industry, there are two main approaches to architecting applications which are monoliths and microservices.
Design consideration for cloud-native applications
Before designing the architecture of a cloud-native application we should:
- List the Functional requirements, and
- List all available resources
This makes it easier to choose between monoliths and microservices
Functional requirements.
Its very important to make sure that the business requirements are sorted, which means to find out what functions should be implemented and for whom: good questions to ask are:
- Who are the stakeholders- identifying the personas to sponsor and require the application
- What functionalities are needed, e.g should this provide a chatbot? Basically what purpose is this application serving?
- Who are the end-users/consumers/customers: is it an internal employee-facing tool or is it a customer-facing application?
- How input and output should be processed e.g should the application send out notifications as part of the output or does the input require any additional info from the customer to execute successfully
- What engineering teams can build the project, deciding which teams have the right skill set and time
Available resources:
Equally important to define the available resources of an organization to proffer a cloud solution or what could block the product release for example
- Listing the engineering resources, such as the number of engineers that can work on a project or the ability to hire contractors
- Financial resources or how much can the business spend to ensure a successful release of the product
- Timeframe within which the product has to hit the market
- Internal knowledge of the programming language or tool which can facilitate the development of the cloud application
Design phase
After listing and analyzing the application requirements, we can move to the design phase. Two major types of applications have been referenced earlier, Monoliths and microservices. Regardless of the type of application structure that is chosen the end goal is to create an application that best serves your users and at the same time allows the engineering team to easily adjust and extend existing functionalities.
Application Tiers
A tier is a logical separation of components in an application. There are multiple components that make up a software application.
- User Interface(client side)
- Database layer.
- Business logic - which includes the following:
- Backend application server
- Messaging
- Caching
Monolithic Architecture Approach:
In this architecture, all tiers of the application are part of one unit, in this case, all the business logic shares one single repository, shares the same resources, and are written in the same language. Packaging, distribution, and deployment of a monolith application is represented by a single artifact or binary file(which includes the code for an entire stack).
Microservices Architecture approach:
This architecture style breaks down the application into several small independent units. Each functionality represents a separate service for its own logic and has allocated resources for CPU memory. In addition to this, each microservice exposes an API(application programming interface) for interaction with the UI and other available units. Every unit is written in a programming language of choice that is best suited for context-off development. This method Enables concurrent development cycles, as multiples teams can work simultaneously to develop multiple services at the same time. Packaging, distribution, and deployment, each service has its own separate repository with its own binary and that contains the code and dependencies for that unit alone.
Trade-offs between Monoliths and Microservices
When trying to choose a type of architecture for your application, these are the things you should take into consideration.
- Development complexity
- Scalability
- Time to deploy
- Flexibility
- Operational cost
- Reliability
Developement Complexity
| Monoliths | Microservices |
|---|---|
| One language is used. | Multiple Languages can be used. |
| One repository is used for the codebase. | Multiple repositories. |
| The engineering pattern for development is sequential, usually an update requires changes to multiple functionality to ensure backwards compatibilty. | The engineering pattern for development is concurrent because different teams can work on the different services. |
Scalabilty
This captures how an application scales under load.
| Monoliths | Microservices |
|---|---|
| To be scalable, it requires the replication of the entire stack. | Replication of only the units that require scaling. |
| Resources are overconsumed because we scale replicate everything. | Since only the units that absolutely require scaling are replicated, there is a more efficient consumption of resources. |
Time To Deploy
Ability to build a delivery pipeline and ship features.
| Monoliths | Microservices |
|---|---|
| One delivery pipeline is required. | Multiple delivery pipelines. |
| Entire stack is deployed and there is a higher risk of violating the "zero-downtime principle". | Each functionality can be deployed independently without affecting the availability of the entire app. |
| Has a low velocity at scale because the entire stack has to be redeployed with each update | Allows an increased velocity of future development. |
Flexibility
Implies the ability to incorporate new technologies and adapt to new principles and tooling.
| Monoliths | Microservices |
|---|---|
| Low. | High. |
Operational cost
This encapsulates the resources to build, deploy, release and maintain the application.
| Monoliths | Microservices |
|---|---|
| Low initial cost because only one codebase is built and deployed | High initial cost because multiple languages and tools are used which sometimes requires different teams |
| Higher cost when its time to scale. | Low cost at scale. |
Reliablity
Ability to recover from failure and ways to monitor the application.
| Monoliths | Microservices |
|---|---|
| When failure occurs, the entire stack requires recovery. | If a service fails, that service alone requires recovery. |
| Getting visibility for each functionality would be difficult because all the metrics and logs for the entire application would be aggregated together | Its easier to get metircs and logs for each functionality/service |
NB: There is no "better" architecture to implement, but a good understanding of the trade-offs would create a clear roadmap that ensures that your application would be optimized and it can allow the addition of new capabilities or functionality.