In software development, microservices refer to a novel approach to building applications that involves creating small, independent services that collaborate with each other. To better understand this concept, it is important to delve into the specific attributes that distinguish microservices from other software development approaches.
Microservices Introduction
Single Responsibility : Small, and Focused on Doing One Thing Well
As we add new features to our codebase, it inevitably grows larger, making it challenging to identify where changes need to be made. Despite efforts to maintain clear, modular monolithic codebases, the arbitrary in-process boundaries can break down over time. This can result in code related to similar functions being dispersed throughout the codebase, leading to difficulties in bug fixing or implementation.
In a monolithic system, we counteract these challenges by striving for cohesive code, often by creating abstractions or modules. Cohesion, which refers to the grouping of related code, is a crucial concept in microservices. Robert C. Martin's Single Responsibility Principle emphasizes the importance of cohesion, stating that we should "gather together those things that change for the same reason and separate those things that change for different reasons."
Microservices employ a similar approach by using independent services that are designed to align with specific business boundaries, making it clear where the code resides for a particular functionality. By limiting each service to a distinct boundary, we prevent the temptation for it to become overly large and complicated, which can lead to a host of issues.
Autonomous :
Our microservices are designed as separate entities and can be deployed as isolated services on a platform or their own operating system process. We aim to avoid combining multiple services on the same machine to maintain simplicity and ensure that communication between services is through network calls. Services must be able to change independently without affecting consumers, and we need to consider what services should expose and what should be hidden to maintain autonomy. To ensure technology-agnostic Application programming interface (API), we may need to pick the right technology that doesn't constrain technology choices. Decoupling is vital for our microservices, and any changes must be deployable without changing anything else to achieve the benefits of this approach.
Key benefits
Technology Heterogeneity
In a system with multiple collaborating services, we have the flexibility to use different technologies for each service. This approach allows us to select the most suitable tool for each task, rather than being limited to a standardized, one-size-fits-all approach that can compromise performance.
If we need to enhance the performance of a specific component in our system, we may opt to use a different technology stack that can better meet the required performance levels. We might also decide to store data differently for different parts of our system. For instance, for a social network, we could store user interactions(friends) in a graph-oriented database to capture the intricate network of connections. However, we might choose to store user posts in a relational data store, resulting in a heterogeneous architecture, as depicted in the diagram.
Microservices also enable us to quickly adopt new technologies and understand how they can benefit us. In traditional monolithic applications, one of the biggest challenges in experimenting with new technology is the associated risks. Even small changes can have significant impacts on the entire system. However, with microservices, we can introduce new programming languages, databases, or frameworks without affecting the entire system, thus reducing the risks involved in technology adoption.
Resilience
In a microservices architecture, service boundaries act as bulkheads that help to isolate problems in case of a component failure. This means that if one service fails, it doesn't cause a cascade effect, and the rest of the system can continue working. On the other hand, in a monolithic service, the failure of one component can bring down the entire system. Although a monolithic system can run on multiple machines to reduce the risk of failure, a microservices architecture can handle service failures and degrade functionality accordingly.
Scaling
In a monolithic service, scaling is an all-or-nothing affair, meaning that we have to scale the entire system, even if only a small part of it is experiencing performance issues. This constraint can lead to unnecessary costs and complexity.
With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware .
As illustrated in the figure below, we have chosen to scale the post's service and chat service in our social media platform due to the higher traffic volume on those services.
Easy of deployment
Imagine changing one line to a monolithic application with hundreds of lines of code , as you guessed this required to re-deploy the whole application. That could be a larger impact . Regrettably, this implies that our modifications accumulate over time, and we keep piling up changes until the new version of our application that is released to production has an overwhelming number of changes. The greater the difference between releases, the more likely we are to make mistakes, increasing the risk involved.
By using microservices, we can modify and deploy a single service without affecting the rest of the system, enabling us to deploy our code more rapidly. If there is an issue, it can be isolated to a single service, allowing us to quickly roll back. This approach also enables us to provide new functionality to customers more quickly.
Organizational Alignment
Usually large teams and large codebases attract organisational problems . These problems can be exacerbated when the team is distributed. We also know that smaller teams working on smaller codebases tend to be more productive. Microservices allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity. We can also shift ownership of services between teams to try to keep people working on one service colocated.
Subscribe to newsletter for more :
https://architechinsider.substack.com/
Top comments (3)
Microservices are the future
Try to add some more visuals or demo 🔥
Thanks for your feedback @lovepreetsingh