Microservices have been getting a lot of attention recently: articles, blogs, discussions on social media, and conference presentations. Everyone has questions regarding Microservices: What are Microservices? How are they different from Service Oriented Architecture (SOA) or traditional monolithic architecture? What are the benefits of using Microservices over a SOA system? and so on... This blog will attempt to explain Microservices in simpler terms.
Traditionally, software developers create large, monolithic applications. The single monolith would encompass all the business activities for a single application. As the requirements of the application grow, so does the monolith. If the application becomes a success, traffic and usage increase dramatically. This means more features are added, and more developers are brought in to work on it. Your once-simple application is now a large, complex.... beast. You now have multiple independent development teams working on it simultaneously. However, these presumably independent development teams are actually not independent at all, they are working on the same code base, and changing the same sections of code; in some cases, they may even be meddling in each other’s code. These activities go on for the life of the application, which is typically years, and at times can be tens of years. In this situation, code quality—and hence application quality and availability—are likely to suffer. The traditional process is based on a tightly knit and highly coupled approach. This can introduce bugs and issues, and may lead to application failures, performance bottlenecks, and can affect the business operations in a big way.
Microservices based architecture is a more distributed and loosely coupled approach. A single application would be constructed as a collection of independent Microservices, each of which would perform a single task individually. The benefit of distributing different responsibilities of the system into different smaller services is that it gives you the flexibility to change and add functions and features to the system at any time. With how quickly things can change in today’s business world, this adaptability feature actually enhances cohesion through independence.
On to the analogy; We all love cookies, and at some point in time we have made them, or helped someone make them. If not, we have at least eaten the yummy cookies. Let’s understand Microservices in terms of the cookies making process. Sound sweet?
The traditional monolithic or SOA based application, which is explained above, is like an automatic cookie maker. A single unit completes every step from collecting ingredients, mixing, preparing dough, shaping, baking and finally packaging the baked cookies. But, if something goes wrong somewhere in that machine, cookie production will stop until you locate and fix the issue. And all your efforts for that batch of cookies are now in the trash bin.
But, what if all these processes were distributed? It would be easy and flexible to manage, scale, and auto-heal. Now, you must be thinking… how? What is the benefit in dividing the processes? The owner must buy more machinery instead of having one automated cookie maker, right?
Let’s divide each of the processes to make the cookies as below and checkout the benefits.
|Fig1: Cookie making flow chart with independent processes|
If all tasks are divided between different machines, it would be as below. Each machine knows the task it must perform, and can work independently from each other. This means services can be reused, or utilized for other work. For example, if there is idle time where the oven is not being used to bake cookies, then the oven can be used to bake bread, croissant, pies etc.
Similarly, Microservices are also independent entities with distinct tasks. So if one Microservice is assigned to insert data into a database, then multiple instances with different configurations of the same Microservice can be used in a larger project to handle different task with similar functionality.
We are essentially reusing the functionality, rather than rewriting redundant code again and again as in a monolithic development style.
|Fig 2: Cookie making in action with independent machine|
Now the owner wants to manufacture chocolate chip, as well as coconut cookies. With the automatic “monolithic” machine, it is only possible to make on type of cookie at a time. But with a decoupled system, it is just a simple tweak to add one more process to add chocolate chips or coconut shredding before preparing dough without touching or impacting any existing functionality. Just add one more feature in the whole process and you can completely change the scope of your business.
|Fig 3: Adding a new feature or a functionality|
To add new features in a monolithic system, developers needs to change code and then compile the whole piece of code. Now, a single bug in that new feature could affect the whole flow. but with Microservices based architecture, new features would be added as a new Microservice and chained in the existing flow where it is required. Nothing else will change in the existing process, and if there is any issue in the new feature, it could be removed or updated very easily.
The baking process is taking a lot of time, and there is a queue of hungry customers at the door. Did I mention they have crisp dollar bills? How do we accelerate the cookie making process?
With the old automatic cookie machine, accelerating the production process would not be easy. To scale up cookie production you would need to buy multiple automated cookie making machines. Doesn’t it seem silly to buy an entire system because the oven is taking more time to bake?
However, in the decoupled scenario, we can easily identify the baking as a step in the critical path, or the bottleneck. Applying the theory of constraints is simple here, just add another oven and you accelerate the baking process. This is what is known as scalability in the technical terms.
|Fig 4: Illustrating Scalability|
We at RoboMQ adopted this architecture early on. For all our integration services development, we have followed Microservices architecture. The Microservices architecture needs only a few simple building blocks:
- An API gateway
- Messaging fabric or message queue infrastructure
- Container technologies like Docker that is used to package Microservices as atomic and autonomous unit
Fortunately, we have all the above and more. As part of the RoboMQ product we provide a multi-protocol gateway, “ThingsConnect” and the hosted message queue service. Our Multi-protocol gateway allows Microservices to use any data integration protocols without any language constraints. It also allows easy integration with existing legacy services facilitating a brownfield approach.
Message Queues as a service, including the hybrid messaging cloud, provides the wiring or the plumbing for services to interact, process and delegate tasks to each other thereby assembling complex business processes. Using RoboMQ, you can build your business processes across networks and clouds without worrying about boundaries.
This blog tries to explain the advantages of using Microservices based architecture over monolithic or SOA architecture with a simple example. Building complex applications is difficult. A Monolithic architecture only makes sense for simple and small applications. The Microservices architecture pattern is certainly a better choice for complex, evolving applications, and RoboMQ provides all the basic building blocks.
For more details on Microservice based architecture, please checkout out the microservices page on our website. You can also reach us on email at email@example.com if you have specific questions or need us to help you out in your Microservices journey.