When deciding on making changes in IT infrastructure, the most important consideration is whether or not those changes will add value that exceeds their cost. While few things in IT are low cost/high value, this is especially true of a microservices architecture. Properly implemented, microservices can be highly beneficial for an organization. Those benefits include isolation of failures, scalability and increased productivity. And while these benefits typically pay off in the long term, the journey there is often costly and requires changes unrelated to technology, including cultural shifts to smaller teams, DevOps, and a greater emphasis on release and test automation.
For new projects, where requirements are light and the full scope is not yet clear, it's probably best to steer away from a microservice architecture. The operational overhead of setting up proper continuous-integration mechanisms, establishing deployment strategies, building out proper automation throughout the product's life cycle, and coordinating all these tasks will likely overwhelm the team early on.
The good news is that an organization can ease into a microservice architecture. Early decisions about the monolithic service layer will allow for a gentle transition to microservices later. First, the engineering team should view the monolith as a future gateway into the microservices. Eventually, this monolith may be the API that serves a front-end application or some other client. Second, ensure that developers are properly decoupling modules within the monolith. This will make it much easier for them to break out the services in the future. Third, and most importantly, make sure that each of those modules corresponds to a vertical slice of the business.
It's tempting for developers to want to create specialized abstractions over low-level concepts and to think of those as microservice candidates. For example, a service that performs CRUD operations on a database is not a good candidate for a microservice. But a service that manages the order processing of an e-commerce site could be.
When choosing where to start, it's a good practice to work on the service that is least impactful. This will give the team an opportunity to make and correct mistakes and refine their methodologies. Make sure to choose a team with a good working knowledge of the requirements for that service and empower them to explore the best technology stack for the use case. Where applicable, try to leverage serverless technology because it can help in the transition, maintenance and cultural changes required.
Preparation will make for a smooth transition into microservices. This is true whether you're breaking off pieces from a modern monolith or from a well-established legacy product. Microservices can be very demanding for an engineering team. To start, an organization will need at least one strong DevOps engineer to lead parallel initiatives. Container orchestration tools like Kubernetes and ECS do a great deal of the heavy lifting in a microservices infrastructure. They are typically the foundation upon which the microservices will be deployed, scaled and discovered by other services. However, they require configuration and maintenance.
Properly staffing the development teams is another concern. There should be enough engineers in an organization so that they can be reasonably split up into smaller teams, and each team is responsible for one or more services. The number of services each team is responsible for depends on the application, size and complexity of each service.
Ultimately, I recommend that business leaders be cautious of the buzz surrounding microservices. An organization may find itself paying a steep price for implementing something that is trendy but that it is not entirely ready for. This is not to say that the buzz is not warranted. Microservices solve very real business problems in elegant ways. For optimal results, only pursue the implementation if you've developed a good understanding of how your business will benefit from the architecture.
This article was originally published on forbes.com
