Microservices are nothing but fine grained SOA offerings. We can say more politely “it does one thing but very well” means without affecting others or waiting something to trigger. It gives lot of freedom for developers more importantly to decide how to use, design, language to choose, platform to run, deploy, scale etc. It decouples from the main deliverable but revolves in satellite mode support with thick coupling.
Let us see one by one:-
1) It help us to develop, deliver as a smaller component services importantly in an agile way. Each of these services can be owned by a smaller team can be fed with 2 Pizza’s team which they call in Amazon (read about 2PT’s) which I picked from this fantastic book.
2) It gives us the freedom to develop and deploy services independently without waiting for the complete release say quarterly release or half yearly release cycle as in monolithic world. The consumer can start seeing the enhancements or features rolled out now and then and enjoy greatly.
3) These Microservices though deployed separately, but it has to be orchestrated together in one way or another to work closely for a bigger applications. It is designed to run as a unique process or service in silos bundled including separate DB to maintain its state values. It communicate with each other services over Web API/Broker messages way of signalling and syncing. By going this way, we make the team into small units owning the end-to end service responsibility focusing and pushing without waiting for a big release day.
4) DevOps role kind of guys comes in here to develop, configure, release, maintain and also monitor these services exposed as an API endpoint or stateless REST API’s or HTTP/XML/TCP/JSON and of course even binary format too. Typical example would be, heavy trafficked eCommerce site like Amazon, the recommendation shown at the bottom of the page would come from one such microservice, payment gateway code logic on another microservice, or themes or catalogue.. so who knows there could be 25+ such microservices supporting the complete portal. These kind of service separation allows the developer guys to evolve quickly and also fix their bugs/changes in real time by updating one after the other. Live example is, amazon.com relies on more than 150+ API’s to render its any of their page.
5) These services can be written in any programming language or using any framework hosted in any platform too. It gives us the choice to decide and roll out quickly with our known languages.
6) It gives us the flexibility to test out these individual services individually for scaling scenarios to sustain black friday sale days kind of sudden burst.
7) As I said earlier, these services do one thing so it has to do well. So having this in mind, developers design them to live and serve for longer time by having newer version side by side. In case of an issue in deployment, we can always redirect to older or newer version in agile way. Most of the steps are carried out through scripts or portals GUI for config changes to act quickly
8) Next important benefit is “resilience“. A typical monolithic application would be deployed in big fat server whereas these microservices would spread across servers or even between different data center also. If one such service goes down, then the request would get served from other available copy to continue the business as usual. It also allow us to “scale out” efficiently with duplicate copies of those critical core services by deploying across servers/VMs/containers. There are open source tools which comes handy to perform these scaling operation. In monolithic design, we can maximum scale up to support the additional load but cannot live in separation- tightly coupled in same basket.
9) List of companies known for using Microservice as an early adaptor are Amazon, Netflix, Twitter, Bluemix, Souldcloud, Google, Azure. In recent times, many many big websites and application has already moved from monolithic to Microservices architecture to reap it benefits. Recently, this area is hotter than Big Data or IoT trend and also players like Google Kubernetes, Mesos/Marathon, Docker Swarm, Amazon ECS, CoreOS Fleet or Rancher, Azure Container Service, Service Fabric etc are there to fill in one or the other form. The Main objective of the Service Fabric is to reduce the complexities in building complex applications using Microservice approach. Definitely Containers and actor based programming model are the examples but as said earlier, this area is going to have more update this year.
10) Microservices are usually designed to function as stateless because stateful is tricky & difficult to design for storing its state maintained. But Service Fabric allows us to build such stateless/stateful service without much effort. Service Fabric is a PaaS system for building highly scalable, distributed applications composed from microservices. It enables an > application runtime, > patching and innovative rolling upgrade > health-model support > all while maintaining local state replication. I will try to cover the rest in next part in detail with hands on. Here is the bunch of links to think through.