Skip to main content

Break a monolith to microservices - 12 best practices & design principles to follow in 2020

(Image credit: Image source: Shutterstock/violetkaipa)

There was once a time when applications were traditionally developed as monoliths, being packaged into a bundle of code and deployed as a single unit. However, the complexity of sustaining a monolithic architecture coupled with product complexity and lack of speed to evolve has led to enterprises seeking new alternatives to sustainability, flexibility, and ease of integration.

While breaking a monolith and switching to microservice architecture seems easy, many enterprises tend to underestimate the overall complexity of the initiative and make catastrophic mistakes.

Microservices architecture basically represents a myriad of small, automated and self-contained services that carry out a single business functionality.

If you have been aiming to make a similar shift from a monolithic architecture to the new-age microservice architecture, jumping the gun might end up doing more harm than good. After all, you would not want your costs to shoot up or unexpected bugs to be encountered at crucial moments in the product’s lifecycle.

So here’s a look at 12 of the microservices best practices that you should be following at all costs:

Have separate data storages

Before you even consider the migration, figure out how you will segregate the data storage according to the various constituting microservices. This can be done by using the architecture pattern such as CQRS (Command and Query Responsibility Segregation) to make the data private to each of the microservices.

Failing to make each service the sole owner of its data will allow multiple services to access privately owned databases, resulting in the issue of coupling between them. While this does not mean that data cannot be shared between microservices, it should only take place via APIs.

Build dedicated teams

Microservices have their shining moment in the sun only when they can help you make cloud-native applications. But, this also means that updates need to be released relatively quickly and in real-time, with every second lost to downtime resulting in significant losses for the business. Hence, it makes more sense to allocate dedicated teams for every microservice if you are planning to scale linearly and efficiently.

It is difficult for developers to grasp the complete end to end scenario of large-scale applications. Switching technologies or a development mindset can take a lot of time and effort on their end. Having dedicated teams to keep them familiarised with the nuances of management while ensuring maximum possible efficiency is a microservices best practice that should be followed.

Use automation for independent deployment

It would make no sense to break down the monolithic architecture into individual microservices if they cannot be deployed independently. Also, while you are at it, make sure to implement a ‘build and release’ automation structure. Not only will this help you to reduce the overall lead time, but it will also make releases quicker and enhance the deployment process.

With automation, microservices can be wrapped in containers and efficiently deployed to any environment, including the cloud.

Leverage the benefits of REST API

The REST (Representational State Transfer) APIs can work wonders for microservices as developers need not install any additional software or libraries while creating a REST API. At the same time, they provide a great deal of flexibility since the data is not tied to any particular method or resource. The result is an ability to handle multiple types of calls, return different data formats, and alter the structure with the correct implementation of hypermedia.

You don’t even need a framework or SDK since HTTP requests are relatively sufficient. Out of the four levels of REST, simply begin at level 0 and make your way up to level 3, as proposed by Leonard Richardson, an expert in the subject of RESTful APIs.

Understand the cultural shift

Making a move from a monolithic to a microservices-based architecture may not be as smooth of a shift for old developers as you might think it to be. They have been working in an environment that required them to run end to end tests. Now, they have to suddenly make the shift to a small aspect of the big picture, with management expecting a return of maximum efficiency.

You need to understand that this is more of a cultural shift and not merely an operational one. Developers need to be sensitised with the expectations of the new working environment and how the long term vision of the company impacts their day to day working capacities.

Break down the migration into steps

If you have not handled such a migration in the past, you need to understand that it is not an easy task. Moreover, if you have made plans to make the shift all at once, you need to go back to the drawing board. Monolithic architectures often involve a web of repositories, deployment, monitoring, and other complex tasks. Changing (or migrating) all of this at once may not be feasible for teams and is bound to leave behind errors and gaps.

One of the best ways to handle this is to retain the monolithic structure for now and develop any additional capability as a microservice. Once you have enough new services in place (and the teams have been sensitised about the new processes) figure out how you can break down the old architecture into relevant components and begin migrating them one by one.

Build the splitting system right into the mix

Not having a splitting system right from the beginning of the project can lead to massive hassles in the future. Defining the interactions and processes between different pieces of the puzzle is one of the key microservices best practices and design principles that should be followed in order to make the bigger picture clearer, even more so if you are in the migration phase.

Every splitting system is unique to the architecture that is being built. It depends on the methodology that you are following and the results that you are expecting at the end.

One tip is to inspect the monolithic structure to understand the gaps it has and components that are causing the most trouble and then go on to transform this part into a microservice.

Although, this is only possible if you have been monitoring the performance of individual components in the first place. So, if monitoring is not something that you have focused on, it is a great place to begin the cleaning process.

Tools that you can use for the monitoring process include:

  • New Relic
  • Datadog
  • Influxdb
  • Grafana
  • Isolate the Runtime Processes

Since we now have different processes for different verticals, you are bound to have isolation at the runtime level too. You need to implement some form of distributed computing to pull this off from a pool of possible choices. Do you need to adopt containerisation, event architectures, various HTTP management approaches, service meshes, and circuit breakers? Figure this out before it is too late to backtrack.

Pair the right technology with the right microservice

While one member in your team may not give importance to the technology or language that is being used, another might opine that the life of the product depends on it. Whatever the case, implementing the technology directly and iteratively might make it easier to make changes or even replace it later.

The choice of the language can come down to personal preferences and the comfort level of your team members. But whatever you do, make sure that your team is equipped enough to handle the decision. For instance, choosing an architecture that involves a dozen different programming languages may also translate to a hiring spree, which is often not recommended.

If you are not sure which technology is best for your project, consider the following parameters during the decision-making process:

  • Maintainability
  • Fault-tolerance
  • Scalability
  • Cost of architecture
  • Ease of deployment
  • Consider Using Domain-Driven Design

In one way, Domain-Driven Design is nothing more than Object Oriented Programming applied to business models. It is a type of design principle that makes use of practical rules and ideas to express an object-oriented model. In simpler terms, microservices are designed around your business domains. It is used by platforms such as Netflix who use different servers to run their content delivery and related tracking services.

Distinguish between dedicated and on-demand resources

If your primary aim is to deliver a superior customer experience, consider distinguishing between dedicated and on-demand resources. How does this help? For instance, let’s take an e-commerce platform that builds its microservices and cloud architecture in ways that quickly (and securely) moves workloads between its on-premise and cloud environments. Not only does it increase the response time, but it also makes migrating to a cloud-based working environment much more intuitive.

Govern the dependency on open source tools

It is fairly common for developers to use open-source microservice tools for security, monitoring, debugging and logging. However, ensure that they are not over-relied upon in ways that interfere with the performance or security of the architecture. Depending on your development needs and the types of tools that you are using, implement proper organisational policies regarding their usage. This can be related to:

  • Establishing formal repositories for approved versions of the software
  • Understanding the open-source software supply chain
  • Establishing governance for exception processing

Conclusion

Prior to initiating the process of transforming your system to microservices, it is crucial to have real reasons as to why you want to do it. Take the distinctive features of your system and work on changing one part of the system that hurts the most. Work on an incremental approach where you take out a not so critical part of the system and assess how it works which is also a great way of getting stakeholder buy-in and proceeding from there.

In addition to these microservices' best practices, you also need to make sure that the project manager is capable of handling end-to-end service-oriented architecture migrations and development. The actual process of your migration will heavily depend upon the exact reason you want to do it. Moving from a monolithic architecture to a microservices-based architecture, you will need to take a step by step approach and take out a small, non-critical part of your system to see how it works. This will pave the way to get organisational buy-in for creating more microservices. Only businesses that understand the nuances of the cultural shift towards microservices will be able to leverage the technology at their full potential.

Mitul Makadia, Founder, Maruti Techlabs