Microservices Architecture
Glossary
Introduction
A microservice is a small software component in a larger software system that is easily replaceable, independently developed and independently deployable.
Microservices communicate or coordinate with each other via technology agnostic network protocols in a loosely coupled manner to solve business problems.
They are also technology agnostic and create a distributed system encapsulating data storage and retrieval and exposing data via well defined service interfaces.
They support continuous integration.
This implies that services are loosely coupled by having well-defined and stable contracts between services. This biggest challenge to this? Databases! They shoudn’t be shared, even if they are duplicating data. Reducing coupling is more important than data duplication among different microservices.
Benefits of a microservices architecture
By adopting a microservices architecture, an application can be:
stable, decoupled, reliable, scalable, fault tolerant, performant, monitored, documented and prepared for any catastrophe.
the application can be pushed out quickly
developers get involved in the operational aspects as well as coding the application.
because of this, new technology adoption can occur more easily.
Adopting a microservices architecture also involves:
having a sophisticated application execution platform
having a team structure that is around 5 to 8 people strong with the ability to make decisive changes to their application design according to the needs of the client.
A well designed and sustainable microservice is abstracted away from all the infrastructure - the hardware, networking, build and deployment pipeline, service discovery, routing and load balancing. The developer should be able to commit the code and let the platform handle operational infrastructure complexities.
Microservices
Small, Simple and Decoupled Services = Scalable, Resilient and Flexible Applications
Microservices vs an Enterprise Application Important
An enterprise application often incorporates an n-tier architecture (a more sophisticated version of a client/server architecture), enabling it to be distributed across serveral systems. Even though this results in processes on different machines communicating with each other, because each tier depends heavily on each other (tightly coupled), it is still a distributed application instead of a micro-service.
An enterprise application (usually based on SOA principles) is responsible for a handling a wide range of functionality and data domains, while a microservice is responsible for manging a single data domain and the corresponding functions for that data domain.
Communication between the different systems in an enterprise application tends to be syncrhonous while coordination between microservices are fairly independent and loosely coupled.
Disadvantages of micro-services
The Autonomous Nature
It requires a change in the IT organisational structure to have distributed teams who are fairly isolated from each other, allowing them to be autonomous. With the approach taken at Spotify with Tribes, Squads, Chapters & Guilds, we can reduce this isolation between teams. Spotify has been able to scale this method of working to over 30 teams across 3 cities in 2012. In 2018, it had 3,500 people split over 180 autonomous teams, using this same model. It resulted in a high level of empowerment and trust, a focus on personal development and each team’s sense of purpose.
Every member of the microservices development team needs to be responsible for operational duties and tasks associated with their microservice.
It introduces a lack of focus on architectural, technical and process standardization which brings challenges to the organisation. Hence, a good approach would be to look at the middle ground between very autonomous teams and encouraging them to follow technical, architectural and process guidelines. One of the ways to get around this is to allow teams technical and architectural autonomy, but every month or so, let the teams that show the most successful results share their best practises with the other teams and influence these other teams to adopt the successful approach.
External Dependency
Most likely, communication with external systems are synchronous and they are not able to process the increased load placed when our microservices scale up. This can result in external systems crashing, which can lead to cascading failures.
The way around this is to introduce messaging or a similar mechanism that is non-blocking for sending and recieving requests with external systems.