Microservices fundamentals in a nutshell

The Concept of Microservices :

Microservice: it is an independently deployable component of limited scope that supports interoperability through message-based communication, while microservice architecture is a style of highly automated engineering, and evolvable software systems made up of capability-aligned microservices.

The term “micro web services” was first used by Dr. Peter Rogers during a conference on cloud computing in 2005. “Microservices” themselves premiered at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name. James Lewis presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices — Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as “fine grained SOA” was pioneering the style at web scale .Netflix and Amazon were among the early pioneers of microservices.

Important Characteristics For The Microservice Applications

One of the most important characteristic for the microservices applications is
to be small in size by keeping the service focused on an explicit boundary , where service boundaries focus on business boundaries, and code lives for a given piece of functionality, also microservices have to be messaging enabled and this will enforce loss coupling and make all communication between the services done via network calls.

Another important characteristic is that microservices have to be autonomously developed and independently deployable where the former means that services must be able to change independently of each other, and the latter means that services must be deployed by themselves without requiring consumers to change. Also, in microservices we need to decentralize both conceptual models and data storage decisions

Some Benefit of The Microservices:

1- Technology Heterogeneity: With a system composed of multiple,
collaborating services, a different technologies can be used inside each
service.
2- Resilience: A key concept in resilience engineering is the bulkhead. If one
component of a system fails, but that failure doesn’t cascade, the problem can
be isolated and the rest of the system can carry on working. Service boundaries become is the obvious bulkheads. With a monolithic system, multiple machines can be used to reduce the chance of failure, but with microservices, the systems can handle the total failure of services and degrade functionality accordingly.
3- Scaling : In microservices just scale those services that need scaling, allowing other parts of the system to run on smaller, less powerful hardware.
4- Ease of Deployment: Since microservices are small, bounded and independent from each other, it makes code deployed faster.
5- Organizational Alignment: Align the architecture to the organization, this can help to minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity. Also the ownership of services can be shifted between teams to try to keep people working on one service colocated.
6- Composability: Reuse of functionality where the functionality can be
consumed in different ways for different purposes.
7- Optimizing for Replaceability: since the individual services is small in size, the cost to replace or delete them altogether is much easier to manage.

Important consideration for Microservice design

1- Loose Coupling: When services are loosely coupled, a change to one service should not require a change to another. The whole point of a microservice is able to make a change to one service and to deploy it without needing to change any other part of the system. A loosely coupled service knows as little as it needs to about the services with which it collaborates. This also means that there is a need to limit the number of different types of calls from one service to another, because beyond the potential performance problem, chatty communication can lead to tight coupling.

2- High Cohesion: Related behavior has to sit together, while unrelated behavior has to sit elsewhere. If want to change behavior, have to be able to change it in one place, and release that change as soon as possible. If have to change that behavior in lots of different places, we will have to release lots of different services (perhaps at the same time) to deliver that change. Making changes in lots of different places is slower, and deploying lots of services at once is risky

both of which we want to avoid. So, we want to find boundaries within our problem domain that help to ensure that related behavior is in one place, and that is communicate with other boundaries as loosely as possible.

Further reading:

I. Nadareishvili, R. Mitra, M. McLarty, M. Amundsen,”Microservice Architecture Aligning Principles, Practices, and Culture”, O’Reilly Media
https://www.amazon.com/Microservice-Architecture-Aligning-Principles-Practices/dp/1491956259

Sam Newman. “Building Microservices”
https://www.amazon.com/Building-Microservices-Designing-Fine-Grained-Systems/dp/1491950358

almamon rasool abdali , Rana Fareed Ghani “A proposed Intelligent Surveillance System for Smart Cities Using Microservice Architecture”
https://www.researchgate.net/publication/338548769_A_proposed_Intelligent_Surveillance_System_for_Smart_Cities_Using_Microservice_Architecture