Microservices Architecture Part II

This is Part II of our series of blog posts targeting building applications using Microservices Architecture. This post will cover the benefits of Microservices architecture.

Decomposing your monolithic application into microservices has its benefits.

Development Agility & Speed

With Microservices a service can be architected, implemented, and deployed without affecting other microservices. The application can be modified in a continuous way as frequently as daily in some scenarios especially when used with Containers and a Devops culture. Since microservices represent a specific business functionality the changes are limited to a much smaller codebase. This makes it easy to add a new service to the application or retire the old implementation of a service without affecting the other services, thus enabling rapid development and innovation.

Also since each microservice is independently developed and maintained by an independent team and with the codebase that performs one business function only, it is far more easy for every member of the team to understand the code and make changes at a more faster pace. Any changes to the microservice can be tested independently and in much smaller time since it is decoupled from other services.

Right Language/Framework

While the recommendation engine service could be better written in Java the catalog service could be better suited in Python. Microservices Architecture supports this freedom to choose what is right for the microservice whether it's the language, framework or tool. One can have technology diversity within the application as each of the service teams can choose the best technology that is most appropriate for the service while interacting with the rest of the services through APIs.

Resilient And High Availability

Every now and then we encounter bugs that bring down our applications. With microservices architecture, these bugs only affect a single service and the rest of the applications still works normally. One need to design microservices for unavailability of other microservices within the application thus making them more resilient.

The smaller codebase also makes it easier to track down and fix bugs. For example, if an alert notification microservice goes down, the rest of the functionality still work normally and the impact is limited to users not being notified about events. Nowadays Microservices are used with containers. In this scenario, the container orchestration frameworks provides added resiliency by starting a new container when one container fails, thus restoring full redundancy.

Scalability and extensibility

In order to scale out the capacity of the application or to add new features, microservices can be added easily and seamlessly to an existing application. With microservices since you can scale only that particular service that is in demand gives you more flexibility in deployment. This allows to scale specific microservices independently and push things faster into production.

Cost Efficiency

Organization are always trying to bring down their development and hosting costs as they develop more complex applications. Microservices help control costs since each service can be scaled independently as required.

When a particular functionality for e.g. Orders is in demand, one need to scale up only the particular Orders microservice without scaling the other services. This saves on the infrastructure resources. In contrast a monolith application would need the entire application to be scaled up which would have far more resource requirements and hence higher cost as well.

Faster Time To Market

The speed at which new features are introduced by the businesses give them a crucial advantage. A monolithic application makes it very difficult to introduce any kind of change big or small in the application as it requires testing the entire application for any regressions thus resulting in longer release cycles.

With microservices, any kind of change to a service can be deployed in a short period of time as there is almost no chance of the change breaking the code outside the service. This makes the testing of the service very precise and limited to the service boundary and hence making the testing. Also since one only need to deploy the particular microservice and not a big monolith application makes the deployment faster.

Development collaboration

Each microservice is owned by an independent team that is responsible for the development, testing, deployment and support of the service. This break up into smaller services that have strong module boundaries and owned by independent teams enables the development of a large application through very loose collaboration of a large number of small teams.

Deployment & Rollback

Deployments and rollbacks are faster & simpler due to the independent speed of delivery by the different teams. At a time one needs to deploy just the one microservice that has changed making it easier to deploy. Also when coupled with containers and a container management framework like Kubernetes it become alot more easier.

Microservices Architecture : Part I

This is part 1 of our series of blog posts targeting building applications using Microservices Architecture.

Microservices retains its position as one of the Top Technology Buzzwords of 2016. There is a good reason for this. CIOs of most of the large organizations want to align IT with the business and want to develop products & features faster. This need for speed at which a feature is delivered to production and the need to scale to rising customer traffic has led these organizations to consider microservices architecture .

Monolith Applications

Almost all of the web applications started off as monolithic applications at times written in Ruby on Rails with small engineering teams and a simple product. A typical monolithic architecture would follow the 3 tier approach and will be bundled in one big fat Webapp in war file. Every code that you can think of is part of that monolithic application.

Once upon a time it was a right thing to do. The advantage was that it has good IDE support because as you open your preferred IDE Eclipse, InteliJ your whole code is right there. It makes it easy to look at the entire code and its APIs. All the calls are in memory calls. Its easy to scale as well because all you have to do is to spawn more instances of this single application and set them up behind a load balancer.

Over time the product adds more features organically or through acquisitions. With time the code becomes very large. Also the team working on it becomes bigger with developers from varied background with experience in different languages. The next thing to happen is that the code starts looking like spaghetti resulting in the components getting entangled with each other with no clear ownership of the functionality. This leads to it becoming difficult to add new features.

One small change in the codebase most likely breaks somewhere else in the application. As the product starts adding more users, the application ends up failing to tackle the growth in traffic. Any new developer to the team has the difficult and intimidating task to understand the humongous codebase of the application.

With the team growing and as the code base becomes larger the deployment cycle becomes longer. A small change in the code could impact multiple feature functionality in such a large code base and hence the test cycles become long. While one may argue that the monolithic applications are easy to scale however it is difficult to scale them in a differentiated manner. For example if the catalog listing functionality/feature is high in demand you cannot scale only the catalog listing feature. You have to scale the entire monolith application. If a new change that is applied to a monolith application goes wrong it brings the entire application down.

Microservices

A Microservice Definitions

Loosely coupled means that each of the capabilities of the system is put into a separate process. Thus the system is a network of communicating processes somewhat similar to unix command line where you would put together different unix programs into a pipeline to achieve objective. The microservices need to be organized around business capabilities and each team owning a microservices has representatives from each layer of the technology stack.

Microservices are about many many smaller services that have to adhere to the "Single Responsibility Principle" that is to do one thing and do it right. They are also independently managed. Think of microservices as multiple cars with each car representing a microservice as compared to a monolithic application that can be represented as a train. Each of these microservices have their own database. Each individual team responsible for the microservice is expected to manage it independently.

Unlike monolith applications where everything is put into one big application, Microservices Architecture make smaller services that do one thing and do it really well. Even if the microservice fails it does not make the rest of the ecosystem to fail.

With microservices since you can scale only that particular service that is in demand you’ve got more flexibility in deployment. This allows to scale independently and push things faster into production.

When to Move To Microservices

If your organization has grown into a large organization with multiple teams and each of these teams works on a specific functionality, features and you have reached a bottleneck in your deployment architecture, that is the point where you need to start thinking of moving to microservices architecture.

Microservices, Containers, Devops, Serverless

Nowadays you cannot talk about Microservices in isolation. For a web scale application one would seriously consider containers and Devops along with moving to microservices architecture to succeed.

With microservices architecture teams have end to end ownership and are expected to develop, deploy and support the microservice which is greatly helped by containers. When coupled with standardized container deployment saves time and effort.

With containers one can deploy a microservice in seconds. This is further extended to serverless computing where one can deploy and have the instances up only when they are needed bringing the cost down drastically. All these approaches helps an application to scale elastically. Containerized Microservices also aides in a big way the Continuous Delivery of features to production which is crucial for a web scale organization to get an edge over its competitors.

Conclusion

A microservices based architecture has proven to work at hyper scale. Millions and billions of messages are processed by application designed on microservices based architecture. When combined with containers, Devops and serverless computing, Microservices architecture would give optimum results.

References

http://samnewman.io/books/building_microservices
https://en.wikipedia.org/wiki/Domain-driven_design
http://www.martinfowler.com/articles/microservices.html