Microservices Architecture

Hi LinkedIn Community,

In this article, we will divide into Microservices Architecture and examine it from several key perspectives:

1. What are Microservices?
2. When to Use Microservices Architecture
3. Benefits of Microservices Architecture
4. Challenges of Microservices Architecture
5. Pros and Cons of Microservices Architecture
6. Reference Architectures for Microservices

What are Microservices?

• Microservices are small, independent, and loosely coupled services that can work together.
• Each service is a separate codebase, which can be managed by a small development team.
• Microservices communicate with each other by using well defined APIs.
• Microservices can be deployed independently and autonomously.
• Microservices can work with many different technology stacks which is technology agnostic.
• Microservices has its own database that is not shared with other services.

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP or g-RPC API.

• Microservices are built around business capabilities and independently deployable by fully automated deployment process.
• Microservices architecture decomposes an application into small independent services that communicate over well-defined APIs. Services are owned by small, self-contained teams.
• Microservices architecture is a cloud native architectural approach in which services composed of many loosely coupled and independently deployable smaller components.
• Microservices have their own technology stack, communicate to each other over a combination of REST APIs, are organized by business capability, with the bounded contexts.
• Following Single Responsibility Principle that referring separating responsibilities as per services.

Microservices Characteristics

• Componentization via Services.
• Organized around Business capabilities.
• Decentralized Governance.
• Decentralized Data management.
• Infrastructure Automation.
• Design for failure

Benefits of Microservices Architecture

• Agility, Innovation and Time-to-market

Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.

• Flexible Scalability

Microservices can be scaled independently, so you scale out sub-services that require less resources, without scaling out the entire application.

• Small, focused teams

Microservices should be small enough that a single feature team can build, test, and deploy it.

• Small and separated code base

Microservices are not sharing code or data stores with other services, it minimizes dependencies, and that makes easier to adding new features.

• Easy Deployment

Microservices enable continuous integration and continuous delivery, making it easy to try out new ideas and to roll back if something doesn’t work.

• Technology agnostic, Right tool for the job

Small teams can pick the technology that best fits their microservice and using a mix of technology stacks on their services.

• Resilience and Fault isolation

Microservices are fault tolerance and handle faults correctly for example by implementing retry and circuit breaking patterns.

• Data isolation

Databases are separated with each other according to microservices design. Easier to perform schema updates, because only a single database is affected.

Challenges of Microservices Architecture

• Complexity

Each service is simpler, but the entire system is more complex. Deployments and Communications can be complicated for hundreds of microservices.

• Network problems and latency

Microservice communicate with inter-service communication, we should manage network problems. Chain of services increase latency problems and become chatty API calls.

• Development and testing

Hard to develop and testing these E2E processes in microservices architectures if we compare to monolithic ones.

• Data integrity

Microservice has its own data persistence. Data consistency can be a challenge. Follow eventual consistency where possible.

• Deployment

Deployments are challenging. Require to invest in quite a lot of DevOps automation processes and tools. The complexity of microservices becomes overwhelming for human deployment.

• Logging & Monitoring

Distributed systems are required to centralized logs to bring everything together. Centralized view of the system to monitor sources of problems.

• Debugging

Debugging through local IDE isn’t an option anymore. It won’t work across dozens or hundreds of services.

When to Use Microservices Architecture

• Make Sure You Have a “Really Good Reason” for Implementing Microservices

Check if your application can do without microservices. When your application requires agility to time-to-market with zero-down time deployments and updated independently that needs more flexibility.

• Iterate With Small Changes and Keep the Single-Process Monolith as Your “Default”

Sam Newman and Martin Fowler offers Monolithic-First approach. Single-process monolithic application comes with simple deployment topology. Iterate and refactor with turning a single module from the monolith into a microservices one by one.

• Required to Independently Deploy New Functionality with Zero Downtime

When an organization needs to make a change to functionality and deploy that functionality without affecting rest of the system.

• Required to Independently Scale a Portion of Application

Microservice has its own data persistence. Data consistency can be a challenge. Follow eventual consistency where possible.

• Data Partitioning with different Database Technologies

Microservices are extremely useful when an organization needs to store and scale data with different use cases. Teams can choose the appropriate technology for the services they will develop over time.

• Autonomous Teams with Organizational Upgrade

Microservices will help to evolve and upgrade your teams and organizations. Organizations need to distribute responsibility into teams, where each team makes decisions and develops software autonomously.

When Not to Use Microservices Anti-Patterns of Microservices

• Don’t do Distributed Monolith

Make sure that you decompose your services properly and respecting the decoupling rule like applying bounded context and business capabilities principles.

• Distributed Monolith is the worst case because you increase complexity of your architecture without getting any benefit of microservices.
• Don’t do microservices without DevOps or cloud services

Microservices are embrace the distributed cloud-native approaches. And you can only maximize benefits of microservices with following these cloud-native principles.

1. CI/CD pipeline with DevOps automations.
2. Proper deployment and monitoring tools.
3. Managed cloud services to support your infrastructure.
4. Key enabling technologies and tools like Containers, Docker, and Kubernetes.
5. Following asynch communications using Messaging and event streaming services.

• Limited Team sizes, Small Teams

If you don’t have a team size that cannot handle the microservice workloads, This will only result in the delay of delivery.

• For a small team, a microservice architecture can be hard to justify, because team is required just to handle the deployment and management of the microservices themselves.
• Brand new products or startups

If you are working on a new startup or brand new product which require significant change when developing and iterating your product, then you should not start with microservices. Microservices are so expensive when you re-design your business domains. Even if you do become successful enough to require a highly scalable architecture.

• The Shared Database anti-pattern.

Monolithic vs Microservices Architecture Comparison

• Application Architecture

Monolith has a simple straightforward structure of one undivided unit. Microservices have a complex structure that consists of various heterogeneous services and databases.

• Scalability

Monolithic application is scaled as a whole single unit, but microservices can be scaled unevenly. encourages companies to migrate their applications to microservices.

• Deployment

Monolithic application provides fast and easy deployment of the whole system. Microservices provides zero-downtime deployment and CI/CD automation.

• Development team

If your team doesn’t have experience with microservices and container systems, building a microservices-based application will be difficult.

Architecture Comparison

Deployment Comparison

The Database-per-Service Pattern

• Core characteristic of the microservices architecture is the loose coupling of services. every service should have its own databases, it can be polyglot persistence among to microservices.
• E-commerce application. We will have Product - Ordering and SC microservices that each services data in their own databases. Any changes to one database don’t impact other microservices.
• The service’s database can’t be accessed directly by other microservices. Each service’s persistent data can only be accessed via Rest APIs.

Benefits of the Database-per-Service Pattern with Ploygot Persistence

• Data schema changes made easy without impacting other microservices.
• Each database can scale independently.
• Microservices domain data is encapsulated within the service.
• If one of the database server is down, this will not affect to other services.
• Polyglot data persistence gives ability to select the best optimized storage needs per microservices.

E-Commerce with Database-per-Service Pattern and Polygot Persistence

• Product service using NoSQL document database for storing catalog related data.
• Shopping cart service using a distributed cache that supports its simple, key-value data store.
• Ordering service using a relational database to handle the rich relational structure.
• NoSQL databases able to massive scale and high availability, and also schema less structure give flexibility.

Adapt the Microservices Architecture with real world technologies

Evaluate: Microservices Architecture

Main considerations in the microservices architecture

• Decomposition - Breaking Down Services
• Communications
• Data Management
• Transaction Management
• Deployments
• Resilience

Problem: Break Down Application into Microservices

Problems

• Our E-Commerce Business is growing.
• Teams wants to agile and add new features immediately to compete the market.
• Required Independent Scale and Deployments.
• We should clearly identify microservices which parts could be independent scale and deploy.

Solutions

• Microservices Decomposition Patterns

In the next article we can see about Decomposition Patterns, How microservices can be divided into several microservices based on business context.

Thanks for reading...