Why Microservices?
Microservice pattern architecture or simply called as Microservices is a distinctive method of developing software applications and systems for range of platforms — Web, mobile, IoT etc. Microservices architecture is a way of developing applications as a group of independently deployable components which are smaller, runs as an independent process and communicates with other similar Microservices, mostly via HTTP/REST with JSON, based on overall applications requirements. Any protocol can be chosen for communication but REST (Representational State Transfer), because of its lower complexity and overheads among others, is preferred.
Evolution
There are many enterprise applications and websites that have implemented or transitioned from Monoliths to Microservices. Best examples include Netflix. Once login to Netflix, you notice movies under various predefined categories such as Family, Drama, Recommendations, Action etc. Each of those category listing is a Micro service displaying titles under certain category. Imagine if recommendations engine goes down, should entire dashboard become unresponsive? Due to Micro service architecture, only the affected service goes down and disappears, and nothing else is affected. Amazon and Ebay have also migrated to Microservices. Both the sites receive enormous traffic from end users and applications, and the core site process is managed via many smaller micro services from different areas. Amazon is said to use about 200+ Micro services to display the homepage content.
Why do we need Microservices Architecture?
All successful applications grow more complex over time and that complexity creates challenges in development. There are two essential strategies to manage this problem: A team can keep everything together (create a monolith) or a team can divide a project into smaller pieces (create micro services).
What is a monolith? — A single code base that contains all of an applications logic and to which all programmers involved contribute. A single code base helps reducing the cost involved in deploying distributed systems but at the same time velocity is compromised overtime and makes it more difficult to handle with a large team contributing.
Drawbacks
- Single code base. Many project components typically packaged together in WAR/EAR packages.
- Reduce developer productivity — As application grows, it overloads your IDE while loading the application.
- Difficult to change the technology stack for specific components since everything is tied together. Refactoring of code base also becomes very difficult.
- One application point failure brings the entire application down.
- Scaling is achieved via Horizontal scaling — Deploying EAR/WAR packages in more servers.
MicroServices
Defines strategy to decompose a large project into more manageable smaller pieces that can be tweaked, deployed, and redeployed independently without affecting or need to redeploy the entire application. One big factor pushing Microservices architecture is Scalability. As I am discovering and exploring Microservices in depth, I found everywhere is a reference to a designing model called Scale Cube. This is explained in the book called The Art of Scalability. The model describes three models of scalability, one alongside each axis of the cube.
X axis represents horizontal scaling by cloning, a usual way for monoliths. Y axis represents the scalability by functional decomposition — idea suggested by Microservices, and Z axis is the scalability achieved by Data sharding/partitioning.
Usually Microservices are broken down around verbs or nouns. Consider applying Microservices pattern in an ecommerce website — When using verbs, a monolith can be broken down into service components like login, inventory search, order management, credit card validation etc. Using nouns can break the components like UI, Database access, server side logic etc. where development teams can focus on specific technology and functional areas.
Another key difference here — Monolithic systems use a single logical database across different applications while in a microservice application, each service usually manages its unique database.
Advantages
- Using Microservices approach, developers are free to deploy services independently as opposed to deploying a single application once all the components are ready. This brings lots of flexibility for periodic code change and redeployments.
- Failure isolation — Failure of one service doesn’t affect the overall system. Microservice architecture recommends a graceful exit of failed services.
- Easier for new developers to learn and adopt the codebase, functionality of the system.
Drawbacks
- One big downside of the approach is expensive Microservice- Microservice calls and defining roles and responsibilities among smaller components. Inter service communication should also support fault isolation for e.g. handing the scenario when there is a dependency on a service and that is down. Latency can be another issue.
- Testing with interdependent services can also become challenging and each related microservice has to confirm the agreement before testing can begin.
- Since each Microservice is expected to have its own database, managing multiple databases and schemas can be cumbersome.
- It is easier to deploy independent Microservices but when there are many Microservices requiring coordination among each other, more planning is needed than deploying a conventional monolith.
Each application is different. Having migrating some of big monolith applications to Microservices architecture, a thoughtful 1-on-1 strategy to decompose applications into smaller pieces can lead to many benefits including technology adoption, increase in productivity, less downtime and more availability.
References:
http://theartofscalability.com/
http://microservices.io/patterns/microservices.html
