Microservice
- airbnb microservices architecture journey to quality engineering
- another way to test your microservices
- architecture microservice - difficulties
- microservices - architecture nihilism in minimalisms clothes
- microservices antipatterns and pitfalls
- microservices design patterns
- microservices got talent - the event driven beautiful dance
- outbox and inbox patterns
- outbox pattern
- service mesh
- testing microservices join the revolution
- the macro problem with microservices
A microservices architecture consists of a collection of small, autonomous services where each service is self-contained and should implement a single business capability within a bounded context. A bounded context is a natural division of business logic that provides an explicit boundary within which a domain model exists.
Each service has a separate codebase, which can be managed by a small development team. Services can be deployed independently and a team can update an existing service without rebuilding and redeploying the entire application.
Services are responsible for persisting their own data or external state (database per service). This differs from the traditional model, where a separate data layer handles data persistence.
Characteristics
The microservices architecture style has the following characteristics:
- Loosely coupled: Services should be loosely coupled so that they can be independently deployed and scaled. This will lead to the decentralization of development teams and thus, enabling them to develop and deploy faster with minimal constraints and operational dependencies.
- Small but focused: It’s about scope and responsibilities and not size, a service should be focused on a specific problem. Basically, “It does one thing and does it well”. Ideally, they can be independent of the underlying architecture.
- Built for businesses: The microservices architecture is usually organized around business capabilities and priorities.
- Resilience & Fault tolerance: Services should be designed in such a way that they still function in case of failure or errors. In environments with independently deployable services, failure tolerance is of the highest importance.
- Highly maintainable: Service should be easy to maintainable and test because services that cannot be maintained will be re-written.
Advantages
Here are some advantages of microservices architecture:
- Loosely coupled services.
- Services can be deployed independently.
- Highly agile for multiple development teams.
- Improves fault tolerance and data isolation.
- Better scalability as each service can be scaled independently.
- Eliminates any long-term commitment to a particular technology stack.
Disadvantages
Microservices architecture brings its own set of challenges:
- Complexity of a distributed system.
- Testing is more difficult.
- Expensive to maintain (individual servers, databases, etc.).
- Inter-service communication has its own challenges.
- Data integrity and consistency.
- Network congestion and latency.
Best practices
Let’s discuss some microservices best practices:
- Model services around the business domain.
- Services should have loose coupling and high functional cohesion.
- Isolate failures and use resiliency strategies to prevent failures within a service from cascading.
- Services should only communicate through well-designed APIs. Avoid leaking implementation details.
- Data storage should be private to the service that owns the data
- Avoid coupling between services. Causes of coupling include shared database schemas and rigid communication protocols.
- Decentralize everything. Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.
- Fail fast by using a circuit breaker to achieve fault tolerance.
- Ensure that the API changes are backward compatible.
Pitfalls
Below are some common pitfalls of microservices architecture:
- Service boundaries are not based on the business domain.
- Underestimating how hard is to build a distributed system.
- Shared database or common dependencies between services.
- Lack of Business Alignment.
- Lack of clear ownership.
- Lack of idempotency.
- Trying to do everything ACID instead of BASE.
- Lack of design for fault tolerance may result in cascading failures.
Beware of the distributed monolith
Distributed Monolith is a system that resembles the microservices architecture but is tightly coupled within itself like a monolithic application. Adopting microservices architecture comes with a lot of advantages. But while making one, there are good chances that we might end up with a distributed monolith.
Our microservice is just a distributed monolith if any of these apply to it:
- Requires low latency communication.
- Services don’t scale easily.
- Dependency between services.
- Sharing the same resources such as databases.
- Tightly coupled systems.
One of the primary reasons to build an application using microservice architecture is to have scalability. Therefore, microservices should have loosely coupled services which enable every service to be independent. The distributed monolith architecture takes this away and causes most components to depend on one another, increasing design complexity.
Microservices vs Service Oriented Architecture (SOA)
You might have seen Service Oriented Architecture (SOA) mentioned around the internet, sometimes even interchangeably with microservices, but they are different from each other and the main distinction between the two approaches comes down to scope.
Service oriented architecture (SOA) defines a way to make software components reusable via service interfaces. These interfaces utilize common communication standards and focus on maximizing application service reusability whereas microservices are built as a collection of various smallest independent service units focused on team autonomy and decoupling.
Why you don’t need microservices
So, you might be wondering, monoliths seem like a bad idea to begin with, why would anyone use that?
Well, it depends. While each approach has its own advantages and disadvantages, it is advised to start with a monolith when building a new system. It is important to understand, that microservices are not a silver bullet instead they solve an organizational problem. Microservices architecture is about your organizational priorities and team as much as it’s about technology.
Before making the decision to move to microservices architecture, you need to ask yourself questions like:
- “Is the team too large to work effectively on a shared codebase?”
- “Are teams blocked on other teams?”
- “Does microservices deliver clear business value for us?”
- “Is my business mature enough to use microservices?”
- “Is our current architecture limiting us with communication overhead?”
If your application does not require to be broken down into microservices, you don’t need this. There is no absolute necessity that all applications should be broken down into microservices.
We frequently draw inspiration from companies such as Netflix and their use of microservices, but we overlook the fact that we are not Netflix. They went through a lot of iterations and models before they had a market-ready solution, and this architecture became acceptable for them when they identified and solved the problem they were trying to tackle.
That’s why it’s essential to understand in-depth if your business actually needs microservices. What I’m trying to say is microservices are solutions to complex concerns and if your business doesn’t have complex issues, you don’t need them.