What was before Microservices ???

What is Microservices ???

Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

- - Martin Fowler, James Lewis - -

Why Microservices Better than Monolithic Architecture


Microservice: Since Microservice is a domain-driven architecture, components are divided into a well-defined scope and a dedicated purpose with a single business capability. So in a use case like an online shopping application, components like listing items, order items, searching items will be deployed separately. Therefore when the developers need to scale the searching component during shopping seasons, they can perform Granular Scaling on that needed component.


Microservices: Since each module is developed and deployed independently and if developers need to do any change in a single module or component don't need to redeploy the entire application just redeploy the module with the changes.


Microservice: But in Microservice, we can develop each component like listing items, order items, searching items using different technology stacks since all the components are loosely coupled and independently deployable. Then they can communicate with lightweight mechanisms, often an HTTP resource API. Another advantage is that depending on the need of each component can utilize different technology stacks. Because some components might be CPU-intensive, and some components might be Resource-intensive.

Fault Tolerance (Reliability)

Microservice: Since the application is deployed and developed as a set of small autonomous components, there are failover mechanisms and design patterns to use when developing the microservices to avoid defaults or bugs in one component bring down the entire application. (We will discuss how we can perform failover mechanisms in future articles).

The main difference between Monolithic and Microservice

🔸 The monolithic application put all their functionality in a single process and scales by replicating the monolithic on multiple servers

🔸 The microservice application puts each element of functionality into separate services and scales by distributing these services across servers replicating as need.

Figure 1: Overview of Monolithic Vs Microservices Applications

Some Characteristics of Microservices

Componentization via Services

Organized around Business Capabilities

Products not Projects

Decentralized Data Management

Figure 2: Database Management in Monolithic vs Microservices

Design for Failure (Fault Tolerance)

Best Practices of Microservices

🔸 Don’t use hardcoded values for configuration parameters. Instead, use a service discovery mechanism to like Service Registry.

🔸 Logging: Logging is a vital part of microservices because it will help us to track the flow of requests as well as to track bugs or errors that will occur in microservices applications. When logging, we have to be mindful about logging at the correct level and position. Otherwise, it will be a mess. We should only log once for a particular error at the initial layer that will call multiple-layer like Service, Repository, DAO, etc. Therefore, log in to the place where we initiated the process, and we must log the stack trace or some information to understand where the error exactly happens on multiple service call layers.

🔸 Versioning: Use Semantic Versioning to maintain application versions. When our microservice application version is updated to 3.0.0 from 2.0.0, it is considered a breaking change. Therefore consumers using our services have to adjust their services depend on our new version. We can maintain both those versions parallelly and direct traffic to both of those versions. Then it will give some time to the consumer to update their service to consume our new service.

🔸 Dependency: Each service should be independently deployable. Therefore avoid any tight coupling between any services. Therefore we must maintain independence among services when developing as a best practice.

🔸 Executable Contracts: We should always make some test cases or scripts for services we develop. Therefore whenever we build any of our services CI tools will execute those tests. Then if those tests are passed we know that we haven’t broken our consumers.

🔸 Documentation: For documentation, we can use a tool like Swagger. It will allow us to write technical terms, and the swagger toolset will convert the technical terms we wrote into a proper documentation.

Figure 3: Overview of Microservices Architecture

The above figure shows how different components of the microservices architecture work together. A brief functionality of each component is listed below.

  • Clients: Different users from various devices send requests.
  • Identity Providers: Authenticates user or client identities and issues OAuth Tokens using an identity provider service.
  • API Gateway: Handles client requests.
  • Static Content: holds static all the content of the system.
  • Management: Balances load on services and identifies failures.
  • Service Discovery: Helps in finding the way to communicate with other microservices.
  • Content Delivery Networks: A distributed network of proxy servers and their data centers.
  • Remote Service: Enables remote access to information that resides on a network.

Some Disadvantages of Microservices

  • Hard to test because services are isolated. If we need to run the integration testing, it would be a bit difficult since it depends on various other services.
  • The debugging of microservices applications can be difficult.

Software Engineer at Virtusa, Graduate of Sri Lanka Institute of Information Technology (SLIIT).