5 steps to prepare for a successful microservices journey

[Editor's Note] This article introduces 5 preparatory steps for migrating to a microservices architecture, including how to divide microservices, misunderstandings between microservices and organizational structure, how to divide the organizational structure, and some issues that need to be considered as early as possible in implementing a microservices architecture. It is worth your reference.

Today, there is a lot of buzz about microservices, hundreds of conferences, online discussions, and articles. You can assume that everyone is aware of the benefits and risks that come with it. However, many organizations jump on this bandwagon without being prepared. Naturally, this leads to failures in the architectural implementation process.

A wise man once said, "For any technology used in business, there are two rules. First, automation applied to efficient operations will increase efficiency; second, automation applied to inefficient operations will reduce efficiency." I think this philosophy is also valid for microservices. If your organization is not prepared for this and rushes to migrate, it is likely to fail. The above is the starting point of this article. I will bring you 5 key steps that you need to prepare before implementing a microservice architecture.

1. Start with a drawing

When developing a particular microservice, many developers make the same mistake: just write code. Perhaps, this is the worst mistake you can make. Sure, you may be successful for one service, but as the number of services increases, everything will become a mess.

Like any other product, it needs to be created, and design is the first step. Gather the team around the table and freely draw services on paper (or whiteboard). First, find the main function of the application you are building. Then, break it down into the smallest units from top to bottom. Finally, find the interconnectivity of different units. These functions will become your microservices.

For example, in a book preview application, the main function is to compare different books. However, there are many other functions that need to be developed, such as creating user profiles, ratings, reviews, book databases, etc. Identifying each function is the key to turning them into microservices.

The entire process will take longer than a day and will require multiple iterations until it is complete. Of course, you will need input from people in many different departments to ensure that their perspectives and opinions are known and that you do not miss any system functionality.

2. Microservices are not an organizational structure

It may seem natural to define microservices based on your company's organizational structure. If you are building a monolithic application, this may be an appropriate solution. However, it may be a wrong decision when implementing a microservices architecture.

Maybe this is feasible for a sales department or customer service, but many organizations have only one department that handles all databases. Therefore, creating a microservice for all databases would result in a single point of failure. And not having a single point of failure is one of the key features of microservices.

Some of the functions you want to implement through services may involve several organizational departments, or you may need to build many microservices for one department. In summary, you need to focus your architecture on the services you want to provide, rather than the organizational structure of your company.

3. Create the right organizational structure

Transition to a completely different organizational structure that meets the company's changing needs in terms of governance activities. The previous two steps focused on designing the application to provide the right functionality to the end user. Now, it's time to make sure you have the right operational support for the new architecture.

You will have to abandon the original department structure and make the team focus on a microservice. This means that these teams will be composed of members with different skills, such as system analysts, UX/UI designers, backend engineers, front-end engineers, etc. In this way, the team will be able to be completely responsible for their projects (microservices) - from development and deployment to operation, monitoring and management. In turn, because the team feels that they own the product, it will increase their enthusiasm for creating the product.

The size of the team depends on the total number of people in the company/project; of course, according to experts, the ideal size is 8-10 people per team. Unlike the monolithic architecture, the microservice architecture allows you to scale the team size as the business grows.

Of course, all teams will (need to) actively collaborate to ultimately make the entire project a success. This is the main benefit of this structure, allowing us to deliver products to the market as quickly as possible.

4. Performance and reliability are equally important

The whole idea of ​​switching to a microservices architecture is to create a final product that has better performance, better stability (for example, lower risk of downtime) than a monolithic application, and can be delivered to the market faster.

It is important to consider improving performance as part of the design, which will ensure that potential problems are considered early. Often, (performance) problems arise from microservices being designed with functionality in mind. However, if a service crashes or becomes slow within the larger service, it is of little use. Each service should have 2-3 alternative mechanisms that it can continue to operate when the underlying resources fail. When one of the mechanisms fails to respond within an acceptable time window, the service also needs to be able to switch quickly.

By considering supporting larger load fluctuations in your services in the early stages, your applications will be able to cope with real challenges and you will be ahead of the market. Of course, this is also the main reason why you should consider switching to microservices at the earliest opportunity!

5. Changes first

It is unrealistic to ignore the changes in applications. Developers are constantly adding and removing features, changing code, replacing core elements of applications, etc. This is even more true in microservice applications. More precisely, microservices are constantly evolving.

When you need to deal with multiple code upgrades every day, it is best to accept the view that change is continuous, not a one-time interruption to a stable state. Once you recognize this, you will realize the importance of integrating the flexibility requirements of change from the beginning. One way to ensure that the application always works properly is to prepare service APIs so that microservices can continue to communicate even if they have been changed. In addition, you also need to introduce version control to allow services to expose new and old interfaces at the same time.

On the other hand, data storage evolution is a bigger challenge. Traditionally, improving the database schema to support new features is the hardest part of upgrading an application, and microservices don't make it any easier. However, NoSQL databases are more flexible in terms of adding new domains without breaking the existing structure. If you expect your data storage requirements to continue to evolve (and who doesn't?), then you should make evolvable data storage one of the design goals of your microservices.

When migrating to a microservices architecture, we can all agree that proper preparation is a critical factor in the success of the entire project. Only with careful preparation, innovative design thinking, and the right operations and management structure in place, can you reap all the benefits of microservices!