A successful application grows more complex over time, and that complexity creates challenges in development. Microservices provides a strategy for decomposing a large project into smaller, more manageable pieces. Microservices encapsulate many of the best practices of some of the industry’s biggest software development organisations and are at the core of the development practice of many organisations today, not least among them Netflix and Amazon.
While a monolithic app is One Big Program with many responsibilities, microservice-based apps are composed of several small programs, each with a single responsibility. When new technologies become available that makes more sense for a particular service, it’s feasible to rewrite just that service.
Microservices community and Martin Fowler describe the common characteristics of microservice as follows:
- Componentization via services
- Organized around business capabilities
- Products not Projects
- Smart End Point and dumb pipelines
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Design for Failure
- Evolutionary Design
Componentization via services
The basic idea behind microservice is to split monolithic services to several small manageable components. A component is something that can be independently replaceable and independently upgradable. For example, replace or upgrade breaks on a car without replacing the entire car for a new break.
Components can be a library or a Service. A library is a piece of code, which is custom or third party, that we reference in our project. For example, an XML processing library we use in our project, we should be able to upgrade this library without having many problems as long as we have all the dependencies figured out.
Service is a different kind of component, run on its own process. If you have an application with components running.NET 2.0 framework, and if you want to use the component in .NET 4.5 framework, you are out of luck. But with services, it is possible to move the.NET 4.5 component to a service and access via its endpoints.
Orgaserviceound business capabilities
A lot of the development organisation are organized around technologies. There is a team for UI, a team for Database etc and team for Business Logic etc. The key thing about the microservices world is to organize around business capabilities rather than technologies. Each team should have some elements that directly impact end user experience.
Smart End-Point and dumb Pipeline
When you talk about SOA (Service oriented Architecture), we often talk about getting a power piece of middleware which does a lot of the heavy lifting or processing logic automatically. This called the ESB, enterprise Service Bus.
Microservice community rejects this idea, and they suggest moving all the processing logic to the end point themselves. What we want is connect everything together and process message effectively but it should be up to the end point to how and when to process the messages.All we want is a dumb set of pipes to route the messages.
Decentralized Data Management
Microservices strongly argues against the way the technology landscape is governed today, particularly the way data is managed. When you look at the monolithic application, all of the data is sitting in one big data store, often time in a company standard relational databases. Even in SOA architecture, multiple services pulling data in and out of the same database.
Microservices way of managing data is to have each service responsible for its own data. A service should never talk to another services data store directly, but only through its APIs. This approach has some advantages; first, it removes the mess of integrating through the database, second, the service developer is free to choose a datastore best fit for the service.
To make all these works, we need infrastructure automation. Things like continuous delivery and blue/green deployment where you can deploy with zero downtime are mandatory for microservice to be successful. With Microservices, we are talking about one application with a dozen or so services, so we need an automated way to doing things. You should be able to spin new instances of VM relative quickly.
Also in order to make Microservices successful, we need effective monitoring capabilities. So when things go wrong, we can quickly spot them and fix them.
Design for failure
Traditional approaches often equate reliability with preventing failure. When you have several components/services deployed on multiple nodes, chances are some of them are going to fail. So we need to design the services with failure in mind. That’s why monitoring should be an integral part of the microservice architecture.
A microservice application separates functionality into separate smaller services and scales out by deploying each service independently. This preserve modularity, allows us to choose multiple platform/technologies and work well with the cloud. In order for this to work, we need to adopt a better DevOps culture, better infrastructure and monitoring capabilities. But overall, microservies provide a better development experience and agility of the technology landscape.