Why
The idea of distributed, componentized applications goes back a long way. Most notoriously, it emerged in the form of the SOA trend. Now, it’s back — as micro services architecture. It is gaining momentum primarily due to the following factors:
- Frustration related to not getting the desired output expected from architecture like monolith.
- Availability of tools and technologies to develop and deploy microservices applications with ease.
- Gaining momentum in adaptation of Infrastructure as a Service (IaaS), like AWS, Azure, or others, that have opened the door for easy DevOps operations.
- Success stories of adaptation for microservices architecture by big technology product companies.
What is microservices architecture?
Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces. Microservices are a more concrete and modern interpretation of service-oriented architectures used to build distributed software systems. Like in SOA, services in microservice architecture are processes that communicate with each other over the network in order to fulfil a goal.
Micro services architecture and SOA aren’t the same. In contrast to SOA, microservices gives an answer to the question of how big a service should be and how they should communicate with each other. In a microservices architecture, services should be small and the protocols should be lightweight. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it much easier to change and add functions and qualities to the system anytime. It also allows the architecture of an individual service to emerge through continuous refactoring hence reduces the need for a big up-front design and allows for releasing the software early and continuously.
Good parts
- Each microservice is relatively small and easier for a developer to understand
- Organized around Business Capabilities
- Product mentality over project.
- Each service can be deployed independently
- Decentralize standards. Each independent component can use their exclusive standard
- Decentralized Data Management
- Easier to scale development.
- Improved fault isolation
- Eliminates any long-term commitment to a technology stack
Bad Parts
- Team communication overhead
- Formal documentation overhead
- Non uniform application
- Dev-Ops complexity
- Increased resource use
- Increase network communication
- Marshalling and unmarshalling
- Network security
- Testing
- Production monitoring
- High upfront cost
Who all are using them
- Netflix
- eBay
- Amazon
Conclusion
Whether or not microservice architecture becomes the preferred style of developers in future, it’s clearly a potent idea that offers serious benefits for designing and implementing enterprise applications. Many developers and organizations, without ever using the name or even labeling their practice as SOA, have been using an approach toward leveraging APIs that could be classified as microservices.
Thoughts rants musings 