Microservices Best Practices

Microservices is an architectural pattern that involves the development and design of software as a collection of small and independent services that interact over well-defined lightweight application programming interfaces (APIs) to meet business requirements. The main aim of microservices architecture is to help software development companies to accelerate the process of development by enabling continuous delivery and development.  

At its primitive phase, each of these microservices acts as an individual app in itself. In the past few years, microservices architecture has gained immense popularity as it offers several benefits over monolithic architectures such as:

• Higher scalability
• Faster time to market
• Higher maintainability
• Easy and faster deployment
• Increased modularity
• Easy and quick troubleshooting turnaround times

For all these benefits, you might wonder what challenges you’re going to face. You’ll face challenges such as security, testing, design, and operational complexity. But you’re not required to worry about these challenges as we have the best solution available. Just by adhering to some of the below microservices best practices, you can create a whole microservices ecosystem that is more effective, improves productivity and free of unwanted architectural complexity.

Phase 1: Planning and Organizing

1.1 Check Whether Microservices Architecture Best Fits the Requirements

Microservices architecture should be planned and designed based on the custom business requirements. The first step in the process is to decide whether Microservices architecture will best fit for the custom requirements or not. So, make sure to study your requirements carefully. It will help you to decide which architecture pattern you must follow. Also, don’t forget to determine that your program can be segmented into value-added operations while maintaining its key features and functionalities by executing the necessary research. 

Let’s understand this through an example where you want to build  a server-side enterprise application which has the below mentioned requirements :

• Supports various clients including native mobile applications, desktop browsers, and mobile browsers. 
• Allows 3rd party application integration.
• It should be capable of handling requests by executing the business logic, accessing databases, sending/receiving messages with other systems, and returning an HTML/XML/JSON response.
• Includes all the necessary business operations and services. They are complex in nature.

To develop an application that follows above requirements, illustrate an architecture that structures the application as a coordinated group of loosely coupled, and collaborating services.  And each Service should be: 

• Highly maintainable and testable – For faster development and deployment.
• Loosely coupled with other services –  So, it won’t affect other services and allows each team to work independently on their separate service(s).
• Independently deployable –  To deploy services without coordinating with and impacting other team members.
• Have the ability to be developed by a small team – which is important for better productivity.

These we can achieve through Microservices architecture as it offers numerous benefits such as:

• Enhanced maintainability – each service is somewhat small which can be easily understood and changed.
• Better testability – as we mentioned, the services are smaller, so they can be tested thoroughly and quickly.
• Better deployability – you can independently deploy each service.
• It allows you to manage development efforts around autonomous teams. Each team has the ability to develop, test, deploy and scale its services without depending on other teams.

Now, let’s see when not to use microservices architecture. Monolithic architecture can be a better alternative when

• The application complexity is less. It should have a small number of functionalities to include and be simple to develop. 
• The development team size is small. 

1.2 Define Microservices

You must draw a precise difference between your company operations, services, and microservices. Without this, you may develop large microservices. Because of this under-fragmentation, the microservices methodology will not be useful.

On the opposite side of the table is the prospect of developing an intense number of microservices. This will lead to an excessively fragmented architecture. Note that in order to operate and maintain a microservices architecture, an experienced operational staff is required.

Another challenge that you might face while using such services is deciding how to partition the system into microservices. We can say that it is an art, but you can find several strategies that can help you with this:

• Decompose using business capability
  • Define microservices using business capabilities. A business capability often refers to business objectives like,
    • Customers Management (Responsible for Customers)
    • Supplier Management (Responsible for Suppliers)
    • Order Management (Responsible for Orders)
• Decompose using domain-driven design subdomains.
  • Domain Driven Design refers to the app’s problem space- the entire business as the domain. 
  • A domain includes multiple sub-domains and each one of them is related to different functions of the business. 
  • Identifying subdomains requires proper knowledge of the business and its structure. It can be best identified using an iterative approach. One can start from
    • Organization structure: Different groups or departments in the organization 
    • Key objective: Every subdomain has a key objective to follow. 
  • Example: Sub-domains for an education platform are
    • Lecture Management
    • Schedule Management
    • Payment Management 
    • Attendance Management
    • Exam Management, etc.
• Decompose using a use case or verb and determine services responsible for certain actions such as a Shipping Service that’s responsible for complete shipping of orders.
• Decompose using  resources by determining a service responsible for all functions on resources of a given type such as an Account Service responsible for handling user accounts.

1.3 Build Teams around Microservices

Creating separate teams to manage multiple microservices entails that these teams have the required expertise and tools to develop, implement, and maintain a given service. Make sure that the teams should be adaptable and strong enough to manage their activities independently without spending much time in communicating. 

Here are a few factors and challenges that you need to consider while building teams around microservices.

• Each team should have clear objectives. 
• Developers should be aware of the partial rework that they need to face while executing the inter-service communication mechanism.
• Implementing requests that span more than one service can be more challenging.
• Testing the interactions that take place between services can be complicated.
• Implementing requests that span numerous services demands more coordination between the teams.

Phase 2: Designing

2.1 Adopt Single Responsibility Principle

As we all know, Microservices have focused responsibilities that help to investigate incidents and monitor the status of each service that connects to a particular database. You might first not consider the Single Responsibility Principle while designing microservices but it should be applied to the various levels of software programming such as methods, classes, modules, and services where each of these levels states that they must have a single responsibility component. This phrase is concrete but it still doesn’t explain how large or small the responsibility should be or what the responsibility is for each method, service, class, or module. Apart from this, you’ll get various benefits by implementing SRP such as:

1. Understandability and learning curve: While splitting the responsibilities not just among microservices but also between smaller methods and classes, the entire system becomes easier to learn and understand. 
2. Flexibility: It provides flexibility to combine independent microservices  in various ways depending on the configuration.
3. Reusability: It allows you to reuse the microservices and their components having a single, narrow responsibility.
4. Testability: You can write and maintain test cases easily for each microservices, classes and methods with independent concerns.
5. Debuggability: If the tests fail while obscuring a single production method or class, we can immediately detect where the bug is and thus it accelerates the process of software development.
6. Observability and Operability: If the microservice has only one responsibility, the performance issues become easier to detect as the profiling results become more informative. As microservices are decentralized, it can run on different servers and still work together for an application. If any microservice gets a higher number of hits than others, we can allocate a larger server for that specific microservice. 
7. Reliability: Microservices architecture designed using SRP can increase reliability. If any microservice is under maintenance, others can still serve their responsibilities. 

So, to sum up, we have an interesting quote from O’reilly that says:

“Gather together those things that change for the same reason, and separate those things that change for different reasons.”

This is one of the best fundamental principles to create a good architectural design.  It signifies that a microservice, class, function, subsystem, or module should not have multiple reasons to change.

Let’s understand it with an example: 

An online store can have a microservices architecture like this:

Here, all the services (i.e. Catalog Service, Cart Service, Order Service, Payment Service, etc.) have individual and single responsibilities. One should not merge order service with payment service or any other services as it can make the architecture more complex to program, maintain, and test.

2.2 Use REST APIs and Events Optimally & Make Proper Version Control Strategy

If you’re using RESTful APIs optimally, the microservices architecture pattern delivers significant value and numerous advantages, e.g., you’re not required to install anything on the client side. You don’t need to worry about choosing frameworks since HTTP requests consuming the API gateway service is acceptable. To know the best value of microservices architecture, you must reach the highest level in this model.

To easily access provisioning, ensure each service has its repository while keeping version control logs clean. This can be handy if you’re implementing any change that can break other services.

Let’s discuss this through an example where you’re creating an online store using the Microservice architecture pattern and executing the product details page. For this, you need to develop more than one version of the product details user interface:

• HTML5/JavaScript-based user interface used for browsers (desktop and mobile) – HTML is rendered by a server-side application
• Native Android and iPhone clients – both these clients communicate with the server through REST APIs

Additionally, the online store must uncover product details through a REST API for use by third-party apps. A product details interface (UI) displays various information related to the product. For instance, a clothing product related page displays:

• Basic information related to clothing such as price, size, brand, etc.
• Product purchase history
• Seller ranking
• Availability
• Customer ranking
• Buying options
• Other frequently purchased products with this item

So, in the Microservice architecture pattern, product information is spread over multiple services. Like,

• Pricing Service – Price of the product 
• Product Details Service – basic details about the product such as brand, size, color
• Inventory service – Availability of the product 
• Review service – Feedback of the customers
• Order service – purchase history for the product

Therefore, the code that demonstrates product details needs to fetch required information from various available services.

Now you may be thinking, how to access individual microservices?

• Microservices provide the granularity of APIs that might change depending on the requirements of the clients. It provides fine-grained APIs so that clients can communicate with more than one service.
• The data for the same page will vary as per the client requirement. Let’s take an example: For a product details page, desktop browser and mobile app’s interfaces and details may differ.
• The total number of service instances and their locations can change dynamically
• These services use a wide range of protocols where some of which are not web-friendly

And to overcome such problems, you should implement an API gateway that has a single entry point for each client so that it can easily handle all the access requests in one of two ways. Here you’ll find that some requests are routed to the particular service and handle other requests by fanning out to various services.

Phase 3: Development

3.1 Keep Consistent Development Environment

Set up the development environment of your microservice as VM(virtual machines) as it allows developers to adopt the framework and initiate the development quickly. Also, the virtual machine emulates the functionality of a computing system and physical hardware that runs on top of emulating software. The physical hardware resources available in the hypervisor replicates the functionality that is referred to as the host machine. It also offers various benefits such as:

• Easy provisioning
• Increased productivity
• Efficient DevOps
• Excellent storage and computing power
• Environment-friendly IT operations

3.2 Keep Asynchronous Communication between Microservices

Have you ever wondered how these services communicate with one another? While interacting with each other, a single unavailable service can lead to a miscommunication which can collapse the entire application. For instance, you have developed a system with microservices for an ecommerce store where one microservice sends the text notification to the customer when their order is placed. The other microservices take orders placed on the website. The third microservice notifies the warehouse when to courier the product. And the last microservice updates the inventory. 

Synchronous and Asynchronous: basically, these are the two types of communication among microservices. First, let’s try to understand the above example using synchronous communication. When any customer creates an order, the web server will process the order and send a request to the notification service to send a text notification for the status of the order (either confirmed or failed). After receiving the response, the web server will send the request to the delivery service for the delivery date and time.  

To stay away from all the complications of tightly coupled components, try using asynchronous communication among microservices. There are several practices for asynchronous communication: 

• Request/response – when a service sends a request message to any recipient, it expects to get a response promptly
• Notifications –  here a sender, without waiting for a response, sends a message to the recipient 
• Request/asynchronous response – a service sends a request message and waits to receive a reply message at the end
• Publish/subscribe – a service publicizes a message to zero or more recipients
• Publish/asynchronous response – a service publishes a request to multiple recipients from which some of them might send a response

3.3 Use the Right Tools and Frameworks

If you’re using the right frameworks, libraries and tools, you can easily implement the microservice architecture. But it is a challenging task to select the right tools and frameworks as it requires you to invest a lot of time and effort. So before you choose any tools and technologies, make sure to always put across the below-mentioned questions for yourself or your team:

• What  tools and technology-related challenges current  teams are facing?
• Why does our team need any new tools/technology?
• How will any new tool or framework benefit the team?
• What challenges that you may face while using this new tool/technology?
• When and Where can we use this new tool and technology in the current technology stack?
• Is the new tool compatible with our workflow and architecture?

Now, for instance, imagine that you’re creating microservices using “Spring Boot” which is a popular open-source framework, and implementing DevOps tools to automate the build and deployment process. Here are a few examples of tools and technologies that you can use:

• Github for source code management and version control
• Kubernetes for deployment
• Jira for issue tracking and project management
• Postman for API testing
• Logstash for monitoring
• Nagios to monitor your infrastructure to detect and fix problems
• SonarQube to check the code quality and security
• Docker for containerization
• Puppet enterprise for managing your infrastructure as code
• Ansible for managing your configuration
• Azure DevOps to manage your entire DevOps cycle from one integrated interface
• AWS DevOps to manage your entire software development lifecycle
• Amazon simple queue service for messaging
• Jenkins and Bamboo for deployment automation

3.4 Adopt the DevSecOps Model and Secure Microservices

When it comes to software development automation, DevSecOps (development, security, and operations) and Microservices both are very helpful. By combining  these two concepts, microservices security, software quality and deployment speed can be improved. DevSecOps is responsible for handling major security issues that might occur during the development, deployment, and production phase. Apart from this, it becomes easier to build independent microservices for software parallelly using Microservices and DevSecOps.

Despite this, the DevSecOps teams tend to use the microservice architecture when it comes to the development phase so that it makes sure that Continuous Integration is maintained with increased security measures. We know that Microservices are loosely coupled and not dependent on each other, the development becomes a little easier for developers who’re using the DevSecOps strategy. Also, Microservice architecture helps to increase the speed of DevSecOps-enabled applications and also offers several benefits when combined with Microservices:

• Reduction in errors
• Improved product quality
• Lower development costs and efforts required
• Increased productivity of Development teams

As we mentioned earlier, the combination of DevSecOps and microservices is beneficial and is becoming popular nowadays as more and more development teams have already started using this combination when it comes to Machine Learning and Artificial intelligence. Combining these two strategies helps to enhance the performance of technologies and it makes sure that the scalability of the software is maintained.

Phase 4: Data Management

4.1 Separate Data Store for Each Microservices

For managing the data, make sure you’re choosing a separate database, customize the infrastructure, and keep it only to your microservice. Instead, if you’re using a shared or monolithic database, then it won’t serve the purpose. Any change to that database would impact all the microservices that are used in that database. So make sure that the database you choose to store your data is exclusively for your microservice.If any other service wants to access the data, then it should only be done via APIs that have write access for the particular microservice. 

If you choose the same database for all microservices, you’re making it fragile, in essence, a monolithic architecture. So, each microservice must have its separate database specific to the responsibility.

Sometimes, it can be possible that various microservices need to access the same database to fetch the data. However, an in-depth examination helps you to reveal that one microservice works with a subset of database tables and on the other hand, a microservice only works with an entirely different subset of tables. The key reasons to separate the data of each microservices are: 

• Flexibility in storing and retrieving the data
• Reduced Complexity
• Lesser Dependence
• Cost optimization, etc.

Lastly, make sure to keep each microservice’s data private to that particular service. It must be accessible only via its API. If any service wants to access the data of any other service, it can also be done via service mesh and distributed hash table. 

Phase 5: Deployment

5.1 Deploy Every Microservice Separately

If you deploy each microservice separately, you’ll save a lot of time to coordinate with numerous teams while regularly maintaining or upgrading efforts. Also, if one or more microservices have similar resources, then it is highly recommended to use a dedicated infrastructure as it helps to isolate each microservice from faults and helps you to avoid a full-blown outage.

Here are several recommended patterns for deploying microservices:

Multiple Service Instances Per Host

It allows you to run multiple instances of different services on a host and provides many ways to deploy a service instance on a shared host which include:

• You can deploy every instance as a JVM process
• You can deploy multiple service instances simultaneously in the same JVM for instance, OSGI bundles.

Service Instance Per Container

After packaging the service as a Docker container image, deploy each service instance as a container. This service instance promotes easy deployment and scalability. 

Single Service Instance Per Host

You can also deploy every service instance on its host. 

Service Instance Per VM

This pattern offers numerous benefits and one of the main benefits of VMs is that it runs in a completely isolated manner and deploys each service instance as a separate VM.

5.2 Orchestrating Microservices

Orchestration is one of the most important factors for your microservices to gain success in both process and tooling. Technically, you can use Docker to run containers on a virtual machine, but make sure that it does not provide the same level of resiliency that a container orchestration platform offers. This means that it negatively affects the uptime that comes with adopting a microservices architecture. For effective microservice orchestration, you need to make sure that you’re dependent on a battle-tested container orchestration platform such as Kubernetes.

Kubernetes helps you to manage all your containers’ provisioning and deployment. Apart from this, it also handles load balancing, network communication concerns, scaling, and replica sets for high availability.

5.3 Automate the Deployment Process

An important factor in recognizing the DevOps model is to improve efficiency by facilitating automation. For this, you can use automation tools like Jenkins as it helps you automate DevOps workflows by enabling Continuous Integration and Continuous Delivery.

Phase 6: Maintenance

6.1 Use an Effective Monitoring System

An architecture created with microservices helps you to lead the massive scaling of thousands of modular services. While that provokes potential for increased speed and systematic approach to monitoring. Make sure to have a look at all your microservices and check whether they are functioning as expected and are using resources efficiently or not. So, you can take proper actions if any of the expectations are not met. 

Let’s analyze a situation: You have applied the Microservice architecture pattern which is not capable of handling requests but they are still running. For instance, it might run out of database connections and when this happens, the monitoring system should be able to:

• Generate an alert when an instance fails
• Requests should be routed to working service instances

Fortunately, you’re not required to reinvent the wheel for monitoring. Instead, you can use monitoring solutions to integrate seamlessly within your infrastructure. You can find numerous monitoring solutions that allow you to integrate seamlessly within your infrastructure. 

Now that your monitoring tools assemble metrics, they can be used by visualization tools for beautiful dashboards using which you can see the numbers behind your microservices. Like: How many users were recently online at 9:00 PM on Friday? What is the latency between the invoicing API and product shipping API? How much CPU load has increased or decreased since the last features or updates were released? 

Monitoring microservices, and keeping these stats presented clearly, helps to make informed decisions on how to keep microservices available and where improvement is needed. 

7. Conclusion

So that’s it for the post. Microservices best practices that are  discussed here will help you achieve maximum gains and you’ll end up with a loosely coupled and independent microservice system. You’ll gain benefits of scalability, faster deployment, and overall improvement of your business functions. Before choosing a microservice best practice, make sure to consider your business requirements and use cases. Also, if you’re looking for the right microservice solution, make sure to invest a significant amount of time in searching for the best solution and then get in touch with them.

FAQs:

1. Which API used in microservices?

The most commonly used APIs in the microservices are REST APIs. They act as communication mechanisms in the app architecture between various microservices. The microservices or external systems can interact with each other leveraging functionalities known as RESTful APIs. 

2. Why are microservices faster?

In Microservices, every service is developed and deployed independently. This helps reduce the time and risks associated with coordinating changes throughout the entire application. That is why microservices have fast time-to-market. 

3. What are the 4 pillars of microservices?

Process, People, Platform, and Practice are the four pillars of microservices. 

4. Which database for microservices?

Because every service is independent in microservices, you can use a separate database for each of your microservices as per their requirements. It not only helps scale your database services but also helps in breaking down the monolith data store.