What is Microservice

Based on definition on wikipedia, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others.

In general, microservice has some characteristics

• Microservices achitecture decomposes an application into small independent services
• Microservices are small, independent, and loosely coupled services that can work together
• Each service has a separate codebase which can be managed by a small development team
• Microservices communicate each other using well defined APIs
• Microservices can be deployed independently and autonomously
• Microservices may have their own technology stack, can work with many different technology stacks.
• Microservices has its own database that is not shared with other services
• Microservices are organized by business capability, with the bounded contexts.
• Following Single Responsibility Principle that referring separating responsibilities as per services.

Each microservice may has its own design pattern implemented in. The design pattern implemented on each microservice may different one another on the cluster. Since each microservice is idenpendent each others. The following picture ilustrated how it can be.

The choosing of what design pattern that is suitable applied on each microservice depends on the aim of the microservice itself. Each pattern has pros and cons. So we should be wise on choosing which the best fit to the business need.

Benefit of Microservices

• 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 toleranced 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

• Don’t do Distributed Monolith
  Distributed Monolith is the worst case because you increase complexity of your architecture without getting any benefit of microservices.
  Make sure that you decompose your services properly and respecting the decoupling rule like applying bounded context and business capabilities principles.

• 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.

    a. CI/CD pipeline with devops automations
    b. Proper deployment and monitoring tools
    c. Managed cloud services to support your infrastructure
    d. Key enabling technologies and tools like Containers, Docker, and Kubernetes
    e. Following asnyc 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.

• The Shared Database anti-pattern
  Shared database will potentially make each service depends on one onothers. It will break the idea of microservice itself.

Monolithic vs Microservices

Focus	Monolithic	Microservice
Application Architecture	Simple straightforward structure of one undivided unit	Complex structure that consists of various heterogeneous services and databases
Scalability	Scaling a whole single unit	can be scaled unevenly
Deployment	Fast and easy deployment of the whole system	zero-downtime deployment and CI/CD automation.
Development team	No need containerazation knowledge	Need containarization knowledge
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.

• 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 Polygot Persistence

• Data schema changes made easy without impacting other microservices.
• Each database can be scaled 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.

References

• https://martinfowler.com/articles/microservices.html
• https://www.freecodecamp.org/news/solid-principles-single-responsibility-principle-explained/