5 Steps to Successfully Prepare for Microservices
Microservices have been a hot topic for quite a while now — hundreds of conferences have been held, webinars streamed and articles written on the subject. By now, you would assume that everybody is already aware of all the benefits and commodities they provide, as well as all the risks they come with. However, many organizations have jumped into the trend without many prior preparations. This, naturally, led to a lot of failures upon implementing this type of architecture. A wise man once said:
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.” — Bill Gates
I believe this philosophy also applies to microservices. Not preparing your organization for this transition will most probably result in failure. That’s why in this article, I will go through the 5 steps you need to follow in order to prepare for the implementation of the microservices architecture.
1. Start With Drawing
Many developers make the mistake of going straight to coding when developing a certain microservice. This is probably the biggest mistake you can make. Yes, maybe you will succeed in making one service; however, as their number increases the whole thing will become a huge mess.
Like every other product that needs to be created, the process must start with designing. And by designing, I mean gathering around the table with the team and literally drawing the services on paper (or a whiteboard). Start by determining the main function of the application you are building. Then, by doing the top-down approach, break it down to the smallest possible units. Finally, present the inter-connectivity of all those distinct pieces. These are the functionalities that will become your microservices.
For example, in a book review application, the main function is the comparison of different books. However, many other functionalities have to be developed, such as creating user profiles, rating, commenting, book database, etc. Identifying every single one of these is crucial for capturing them into microservices.
This process will last longer than a day and will require many iterations until perfected. Of course, you’ll need input from many people from various departments in order to get diverse viewpoints and opinions, as well as to make sure you don’t miss any functionalities of your system.
2. Microservices Are NOT Organizational Units
It seems natural to define the microservices according to the organizational units of your company. This might seem like an appropriate solution if you are building a monolithic application. However, it can be a wrong decision when implementing this architecture.
Maybe it would work for the sales department or customer services, but many organizations have a single unit that handles all databases. Thus, by creating a microservice for all databases will lead to having a single point of failure. And that is one of the key features of microservices — NOT having a single point of failure!
Some of the functions you want to present through your services will probably stretch through several organizational departments. Or maybe, you’ll need to build many microservices for a single department. To conclude, you should focus your architecture on the functions you want to provide, rather than the organizational structure of your company.
3. Creating The Proper Team Structures
Switching to a completely different architectural structure will certainly demand changes in the managerial and monitoring activities in the company. The focus in the first two steps was on designing the application to provide the right function to your end users. Now, it’s time to make sure you have the appropriate operational support for the new architecture.
You will have to abandon the old departmental structure and focus teams around certain microservices. This means that each of these teams will consist of various members with different skill sets such as system analysts, UX/UI designers, backend & frontend developers, etc. This way, the teams are responsible for their project (microservice) from end to end — from development and deployment to operations, monitoring, and management. This, in turn, will increase their motivation to create the product they feel their own.
The size of the teams will be determined by the overall size of the company/project; however, experts suggest that the ideal size is 8–10 people per team. Furthermore, unlike the monolithic architecture, a microservices architecture lets you scale the teams as you grow the business.
Of course, all teams will be actively collaborating towards the finalization of the whole project. This leads us to the main benefit of this kind of structuring — a much faster delivery of the end product to the market.
4. Performance & Reliability Are Important Too
The whole idea behind switching to microservices architecture was to create an end product that has greater performance than the monolith, is more reliable (i.e. has a lower risk of downtime) and, of course, can be delivered to the market faster.
It’s important to address performance as part of the design process to make sure any potential issues are considered early. Oftentimes, problems arise from the fact that microservice designs focus mainly on functionality. However, the service will become useless if it crashes or slows down significantly the first time it receives a larger load. Every service should have two or three alternative mechanisms it can use to continue operating when underlying resources fail, and it should quickly cycle through them if one fails to respond within an acceptable time frame.
Thinking about how to prepare your service for greater load variations upfront will help your application stand up to real challenges, giving you a competitive advantage on the market.
5. Plan Changes Ahead
It is impossible to ignore application changes. Developers add and remove functionalities all the time, they change the code, replace core elements of the app and so on, all the time. This is even more true with microservices applications. It’s actually more correct to say that microservices are constantly evolving.
When you deal with code updates several times a day, it’s better to accept that change is a constant, rather than an occasional interruption to a stable state. Once you’ve recognized this, you will realize it’s important to integrate the flexibility necessary for change right from the beginning. One way to make sure your app works properly the whole time is to prepare services APIs so that individual microservices can continue to interact with each other, even as they change. Furthermore, you should include version control, in order to allow services to include both old and new service interfaces.
On the other hand, data storage evolution is much more challenging. Evolving database schemes to support new functionality traditionally has been the most difficult part of upgrading an application, and microservices do not make it any easier. However, the new technology of NoSQL databases is far more flexible in terms of adding new fields without disrupting the existing structure. If you expect your data storage requirements to evolve (and who doesn’t?), you should incorporate evolvable data storage as part of your microservices design effort.
Conclusion
We can agree that preparing right for the transition to a microservices architecture is a key factor in the success of the whole project. Only with careful planning, innovative design thinking and the proper operational and managerial structure — you will be able to reap all the benefits that microservices provide.
