Tuesday, January 17, 2017

Baking cookies and making Microservices

Microservices are getting a lot of attention recently: articles, blogs, discussions on social media, and conference presentations. Everyone has questions regarding Microservices:  What is Microservices? How is it different from Service Oriented Architecture (SOA) or traditional monolithic architecture? What are the benefits of using Microservices over SOA system? and so on... This blog will attempt to explain Microservices in layman 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 application becomes a success; traffic and usage increase dramatically. More features are added and more and more developers are brought in to work on it. Your once-simple application is now large, complex.... beast. You now have multiple independent development teams working on it simultaneously. These presumably independent development teams are actually not independent at all. They are actually working on the same code base and changing the same sections of code - or may be meddling in each others code.  These activities go on for the life of the application, which is years and at times tens of years. In this situation, code quality—and hence application quality and availability—are likely to suffer. So, the traditional process is based on tightly knit highly coupled approach that can introduce bugs, issues and lead to application failures, performance bottlenecks and can at times affect the business operations in a big way.

Microservices based architecture is a more distributed and loosely coupled one. A single application would be constructed as a collection of independent Microservices each of which would perform single or minimum task individually. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances cohesion through independence, decreases coupling and gives you the flexibility to change and add functions and features to the system at any time.

We all love cookies and at some point of 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 cookies making process. Sounds 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 packing 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 of your efforts for that batch of cookies are now in the trash bin. 

But what if all these processes were distributed, then it would be easy and flexible to manage, scale and auto-heal. Now, you must be thinking… Hell how? What is the benefit in dividing the process? The owner has to buy more machinery instead of having one automated cookie maker, right? 

Let’s divide each of the process to make the cookies as below and checkout the benefits.
Fig1: Cookie making flow chart with independent processes 

Now, you don't make the cookies in a single machine. You have multiple machines to take care of distinct independent tasks.


Independent Entity and Reusability

If all tasks are divided between different machines, it would be as below. Each machine knows the task it has to perform. Each can work independently and can be reused/utilized for some other work as well e.g. in the idle time, oven can be used to bake bread, croissant, pies etc. Similarly Microservices are also independent entities with distinct task . So if one Microservice is assigned to insert data into database then multiple instances with different configurations of the same Microservice can be used in a larger project to handle different task with the similar functionality. We are 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





Flexibility to add new features and functionality 


Now,  the owner wants to manufacture chocolate chip as well as coconut cookies. With automatic machine, it is not possible to make multiple types of cookies. 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 whole process. 
Fig 3: Adding a new feature or a functionality

To add new features in monolithic system, developer needs to change some code and  compile the whole piece or the pieces code. Now,  a single bug in that new feature could effect 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 existing process and if there is any issue in the new feature, it could be removed or updated very easily.

Scalability

System is decoupled and each component is doing well defined work. But baking process does take a lot of time. And there is a queue of hungry customers at the door.  Did I say with crisp dollar bills? How do we accelerate the cookie making process? 

In the decoupled scenario, the baking is the time consuming process. We might call it 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. Meanwhile with the old automatic cookie machine, accelerating the production process would not be easy. To scale up cookie production there, you will need to buy multiple automated cookie making machines. Doesn’t it seem silly to buy an entire systems because oven is taking more time to bake? 
Fig 4: Illustrating Scalability


Getting back to Microservices vs. the traditional application development, in Microservices based flows, if one Microservice is facing heavy load/traffic, more instance of the same Microservice could be deployed to divide the load and accelerate the process. And this scaling could be automated in through container management services to scale up on heavy load and scale down during idle time. It would be very difficult to do auto scaling in response to variable load in a monolithic or SOA based system.



Conclusion 

We at RoboMQ adopted this architecture early on. For all our integration services development, we have followed Microservices architecture. The Microservices architecture needs few simple building blocks:`

1) An API gateway
2) Messaging fabric or message queue infrastructure
3) Container technologies like Docker that is used to package Microservices as atomic and autonomous unit

Fortunately, we have all of the above and more. As part of RoboMQ product we provide a multi-protocol gateway, “ThingsConnect” and the hosted message queue service. 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 cloud boundaries.

This blog tries to explains 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 sales@robomq.io if you have specific questions or need us to help you out in your Microservices journey.

No comments:

Post a Comment