Microservice architectures are all the rage these days, and with good reason. In a nutshell, microservices is a software architecture pattern which decomposes monolithic applications into smaller single-purpose services that are built and managed independently. The benefits of a microservices architecture are:
- Quality: separation of concerns minimizes the impact of one service’s bugs on another service.
- Agility: upgrading an existing service or adding a new one can be done on a granular level, without impacting other services.
- Scalability: Each service can be provisioned individually so it has the hardware and software resources it needs.
- Reuse: Services can be shuffled and combined in new ways to provide new functionality.
As CTO of Ness Digital Engineering, I frequently meet customers who want to implement a microservices architecture, so they can enjoy all these benefits. But, I’ve learned that a microservices architecture is not for everyone, and adopting it will not succeed unless the organization has already embraced several other modern software development practices and technologies:
- Agile development: In a microservices architecture, each service is single purpose, and should therefore be developed by a fairly small team. If a problem is encountered, a fix can be quickly deployed for that service alone, without affecting the stability of other services. That’s the essence of agile development: small teams delivering frequent releases in short iterative cycles. If your development process is still waterfall or “fragile” (faux agile, i.e., waterfall disguised by daily standups), you won’t be able to develop or maintain microservices at the required pace.
- Automated testing: To maintain and upgrade a microservice quickly, you need to be able to quickly assess the impact of a change. Multiply this by hundreds or thousands of services, and you quickly realize that there aren’t enough manual testers in your company to keep up. The only solution is test automation, where unit tests and end-to-end system tests are automatically run and the results are automatically validated.
- DevOps: A microservices architecture vastly increases the velocity and volume of deployments, which can present severe operational challenges. To solve this problem, you’ll need to break down the walls that separate development from operations. That is precisely the goal of DevOps, which is the practice of operations and development engineers participating together in the entire product lifecycle, from design through development to production support. The core values of DevOps are summed up by the acronym CAMS, which stands for:
- Culture: DevOps is first and foremost about breaking down the barriers between development and operations, fostering a safe environment for innovation and productivity and creating a culture of mutual respect and cooperation. This value may sound “soft”, but it is the most important (as Peter Drucker once observed, “Culture eats strategy for breakfast”), and it is the most difficult to implement, because there are no shortcuts or workarounds for the hard work of changing people’s attitudes.
- Automation: To develop high quality microservices at scale, you’ll need to perform continuous integration, where regression tests are automatically run each time a piece of software changes. To deploy at scale, you must eliminate the possibility of human error by automating the deployment process, to the point where your infrastructure is code, i.e., recipes that that have been proven correct and can be run on demand across a myriad of machines.
- Measurement: You need to capture metrics about each stage of the development and deployment process, and analyze those metrics in order to create an objective, blameless path of improvement.
- Sharing: A key to the success of DevOps in any organization is sharing the tools, techniques and lessons across groups, so that duplicate work can be eliminated and so that teams can make new mistakes instead of constantly repeating other teams’ mistakes.
- Docker: You’ll need a well-defined, consistent, self-contained environment to run each of your microservices. The most popular environment today is Docker, a Linux-based container which provides fast provisioning and low performance overhead. Implementing some microservices will require running several cooperating containers, e.g., one container for a NoSQL database and another container that generates data and stores it in the NOSQL database. To manage these container swarms, you’ll need to master a toolchain that includes tools like Kubernetes (for orchestration), Spring Boot (for deployment), Consul (for service discovery) and Hystrix (for failure recovery).
- Cloud computing: The cloud is the ideal environment for deploying a microservices architecture, because the cloud provides the needed scalability and automation, with higher reliability than on-premise infrastructure. But, you’ll need to choose a cloud provider and then familiarize yourself with their tools and interfaces for deploying and monitoring cloud-based applications.
If your organization is comfortable with all or most of these practices and technologies, then you are ready to enter the world of microservices architectures and reap the benefits. If not, then your organization is not ready for microservices, and the pain of attempting such a project will probably far outweigh the benefits. You would be best served in the short term by adopting a more traditional non-monolithic architecture that is better suited to your development culture, e.g., a Service Oriented Architecture (SOA) based on coarse-grain services.
For the longer term, you’ll need to up your game, because the rate at which applications are released and updated will only increase over time, and you’ll need to embrace modern software development practices that support the new pace of business. Unfortunately, there are no short cuts to cultural change. Get help from a partner who can guide your organization through adoption of Agile and DevOps practices, so that you can then painlessly benefit from microservices architecture and whatever comes after that in the ever-evolving world of software engineering best practices.