Microservices is a style of structuring an application as loosely coupled services. Think of one service as a whole which executes the role of a department (Technical, HR, Sales, Marketing) in an organization. Each service is a component of the system which can be developed, maintained, scaled individually. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other services. And one more exciting thing about microservices is you can write different microservices in different programming languages i.e. polyglot development support.
Why Microservices, what’s wrong with Monolithic?
There are two ways of designing the architecture of your application: The traditional Monolithic and Microservices
Monolithic Approach
Monoliths are built as a single unit, so they are responsible for every possible functionality: handling HTTP requests, executing domain/business logic, database operations, background processing, communication with the client, handling authentication and so on.
Because of this, even the smallest changes in the system involves building and deploying the whole application. Like even if in your application, there is need to change a single line of code, you will have to make a new build of whole system and deploy which requires a lot of time
This is not the only problem — just think about scaling. You have to run multiple instances of the monolith, even if you have to scale a part of system with specific functionality.
Difficulties are :
- Lack of innovation
- Difficult to scale
- Lack of Agility
- Interdependency- tightly coupled system
Microservices Approarch
An approach to developing a single application as a suite of small services. — Martin Fowler
When there is a large and complex system which needs component management, scaling, individual development then you need microservices. Giant Organisations like Netflix, Uber converted their Monolithic to microservices.
Microservices let you break your large application into distinct domains. They allow work to be done independently on individual services by separating the responsibilities without impacting ongoing work on other services. Your application can grow as your company and other requirements grow with time.
Microservices is a solution to every difficulty I mentioned above in the case of Monolithic approach.
What should be the design considerations while thinking of microservices?
CI/CD: Continuous Integration and Continuous Development is a modern development practice which merges development with testing, allowing developers to build code collaboratively, submit it to the master branch, and checked for issues. This allows developers to not only build their code but also test their code in any environment type and as often as possible to catch bugs early in the applications development lifecycle.
Logging and Tracing: To understand the performance, the behavior, the problems and to monitor the application, you need logging and tracing. Although for monitoring you can use external resources from that you can only get response time information and no. of calls etc but not the insight into application. So for that record information like start time, end time and operations performed. Include an external request id in log messages.
Bounded context: Bounded context tries to define the boundaries of our complex domain into business context. Bounded contexts are important because they allow us to define a ubiquitous language that is shared and valid within a boundary. Domain Driven Design is an architectural pattern which has Bounded Context as a central pattern. DDD deals with large models by decomposing them into different Bounded Contexts.
Control Latency: Latency is an important part of Quality of Service that determines the degree of consumer satisfaction. Every service in microservices architecture requires a network call. And there is latency even with a single call. Latency becomes a crucial thing when a single call becomes many because latency increases as the traffic increases. When services comes under more load, risk of latency and response time increases. When services are waiting for responses, delays can become unbearable and can create a grid lock in the system. If this occurs, there will be a catastrophic failure of the entire system.
Other grid lock can arise due to circular calls, In a pure microservices architecture, any service can call any other microservice. This calling stack can become circular when any service is being subsequently called by some downstream service. When this occurs, latency can become a problem much more quickly as multiple services can depend on a circular service call stack. When moving to microservices architecture you should give significant time to grid lock and latency.
Asynchronous system: One of the best strategies to deal with reducing latency is to not rely on a purely synchronous model. leveraging well designed asynchronous communication is a fantastic way to take care of system health. Asynchronous communication is however not easy. You need to put sufficient work to ensure that your communication reaches the destination. Event driven approach is one that ensures asynchronous communications. This model is the most discussed but definitely not the only one. The stream data platform is a very strong pattern when building a large distributed system. By leveraging this kind of system you can do more stuff with less overall stress on the system.
Orchestrate: In microservices, as we start to build more and more complex logic, we have to deal with the problem of managing business processes that stretch across the boundary of individual services. And with microservices, we’ll hit this limit sooner than usual. There are two styles of architecture which we could follow:
- Orchestration
- Choreography
With orchestration, we rely on a central brain to guide and drive the process, much like the conductor in an orchestra.
With choreography, we inform each part of the system of its job and let it work out the details, like dancers all finding their way and reacting to others around them in ballet.
If you have any insight, respond here! Otherwise, I hope this article helped you answer a lot of microservices and monolithic architecture questions and begin to frame more of the Microservices world in your head. Stay Tuned!
Top comments (1)
Are you moving your traditional monolithic system to microservices?