Evaluating Microservices: Real World Lessons
August 11th, 2015
Truly, What is a Microservice?
Simply put, if you have taken a monolithic service and decomposed it into a set of mostly independent services, then you have created microservices. Microservices are a popular topic in developer circles, because they are a means of solving problems that have plagued monolithic software projects for decades. Namely, tardiness and bugs, both caused by complexity.
The general idea behind the microservices movement is to create small, independent pieces of software that do their jobs well and can be tested and deployed easily and quickly. As a large application is decomposed, component responsibilities naturally fall into place, forming the outlines of services that will be created. Multiple teams are dispatched to focus on developing services concurrently, accelerating development. Automating tests and deployment allows quickly iterating on features and bug fixes, further accelerating development.
Not One of “Those” Posts
Others have criticized microservices. My goal is to help you understand when microservices may be the right choice for your organization by highlighting the stress points that can be aggravated when you choose to develop microservices. At SVDS, we have recently gone through this process with a client, and learned a few things in the process.
The benefits touted by microservices are real. The key to success is to recognize that creating them stresses your development processes differently than if you were creating a monolith. If your organization cannot adjust, then developing microservices will probably exacerbate the problems you are already experiencing. If your organization can make the right adjustments, then you will be able realize the benefits of microservices. Those adjustments fall into two categories: cultural and technical.
Culture and Process
Microservices require that teams embrace a decentralized approach to development. This means that developers or team managers need to be empowered to make decisions so that work can move forward. Without this autonomy, decisions must be pushed up through layers of process or management. This process will quickly become a bottleneck that slows down progress by making iteration difficult. Worse, it is demotivating to watch from the ground level.
Microservices require regular and responsive communication between teams. APIs sometimes change. If teams aren’t notified, or have no way of finding out about these changes, they cannot respond to them. Surprises like this slow work down. Communication can be traditional (email, IM, chatroom), or you can take a more transparent approach by documenting your APIs (wiki, github) and letting your repository communicate these changes to the teams that need to know. It helps to have a proactive project manager or team lead who is familiar with all the teams and APIs.
Moving to microservices will not compensate for teams that communicate poorly or decision-makers who punt decisions upward. In fact, the shorter iteration cycles seen with microservices will amplify the ill effects of this (anti)culture.
Service Architecture
Using microservices will not solve problems with the architecture of your monolithic service. However, the act of decomposing the systems that make up your monolith will be useful as you uncover points of excessive coupling and identify what your microservices should do.
Resist the temptation to decompose to the microservices too much. You know this has happened when services become interdependent and have to be developed in lockstep. Often times this slows development because it is essentially no different from a monolithic application.
You will also want think sooner about continuous integration and deployment (CI/CD). In fact, CI/CD should be in place as you start development. When combined, the work to test, bundle and deploy many smaller services often is greater than with a single monolith service deployed infrequently. Automation compensates for this nicely by ensuring that your services are deployed easily and consistently, and allowing you to maintain a tight feedback loop as development moves forward.
Finally, any rough edges in your testing and deployment process need to be eliminated before moving to microservices, simply because you will bump up against them often as you build, test, and deploy more frequently.
Conclusion
The choice to use microservices should mesh with your existing team culture and technical practices. The key to success with microservices is figuring out how your development teams will need to adjust to a slightly different process of developing software. A good first step may be to create and deploy a few microservices before migrating a pre-existing monolithic service. Pay close attention to any rough spots—understand their causes and iterate. Remember that poor processes and engineering cannot be compensated for with microservices.
Good luck developing!
Header image by Martin Grandjean. Used under CC BY-SA 3.0.
