Microservices Tooling
Previously in this three-part series, I wrote about how to introduce microservices in a legacy environment and provided an overview of domain driven design (DDD) and how this development philosophy can be used to represent the real world in code, while also being well-suited to a microservices implementation. This time, I will cover some of the tools and frameworks that can be used when implementing microservices.
I deliberately saved the tools discussion for last because I often find clients like to jump into tools before they have completely thought through why, and if, a new architectural approach can or should be implemented in their environment. After you have decided that you should move to microservices then it’s appropriate to think about how it can be done and with what tools.
Containerization
Microservices architectures do not require containerization, but it is one set of tools that will make your life easier on a number of fronts.
The metaphor of a shipping container is used because through standardization containers allow goods to be transported by different shippers via ship, rail, or truck regardless of items in the container, knowing that the contents of one container will not affect the others. These containers can be stacked and moved easily.
In software, containerization facilitates the packaging and deployment of services across environments with no modifications. Additional benefits of containers include:
Application isolation
Application scalability; containers allow you to easily scale your application services up/down as needed
Application portability
Allows for, but does not require, microservices implementation
Continuous integration/continuous delivery (CI/CD)
As you can imagine, there are tools in the market place that allow you to containerize your applications and manage/orchestrate those containers in your environment and in the cloud. The three leading products are Docker, Kubernetes, and Mesos, with Docker having become the industry de-facto standard. There are some use cases where one of the other tools may make more sense, such as Mesos for extremely high scalability (e.g. Twitter and Apple).
Developing microservices is only the beginning; the effort and thought necessary for testing, deploying, running, and maintaining services should not be underestimated. To a large extent, the types of tools and techniques you will select will be driven by your existing technical infrastructure. If, for example, you are a heavy user of IBM products then you will be looking to them for solutions.
I have come to believe that the cost of adopting and developing with new tools and frameworks, or in a new language, outweighs the benefits so you should be very careful if you plan to move from your primary vendor’s ecosystem to new one. There is, however, a rich set of tools for microservices deployment and maintenance to choose from that can be used to complement or create your DevOps environment. Here’s an overview of some of these tools and frameworks below.
For CI/CD build management and automation the most widely used tool is Jenkins. Jenkins has a rich library of plug-ins that extends Jenkins to almost any external tool in support of the CI/CD process. Jenkins runs on multiple operating systems; Windows, OS X, or Linux. Configuration of Jenkins is not difficult and has strong support in the industry, so hiring staff -- which should always be a consideration -- is manageable.
There are, of course, other tools. I have worked with companies that are 100 percent Microsoft and wish to stay in that environment whenever possible. Microsoft offers a product called Team Foundation Server (TFS), which also has garnered strong support in the industry. TFS is tailored for Visual Studio IDE but will work with Eclipse and other integrated development environments. In addition to support for the usual CI/CD functionality, it offers integration with Microsoft’s cloud platform and tools such as Azure Service Fabric and Azure API Management (for gateway and portal services). Combining Docker and CI/CD tools can have a profound change on your microservices implementations and deployments.
Testing of microservices poses some unique challenges due to the distributed and the inter-connected, but loosely coupled nature, of their design. The basic principles of testing should be familiar – in 2009, Mike Cohn descried a testing pyramid that has, with some modifications, been widely adopted. This approach is applicable for microservices testing and the need for automation may even be greater now.
Here again, vendor frameworks can help. Microsoft Team Foundation Server offers a full suite of testing tools and services that work on Azure. Jenkins, too, comes with microservices test tools. In addition, some specialized testing tools are available, such as Rest-Assured for Java testing of REST services and WebInject for testing.
Lastly, I want to touch on using microservices for front-end UI development. It is typical for companies to start their journey with server-side microservices. As you move up the maturity curve it will become apparent that a monolithic UI becomes a bottleneck in your development/delivery process as the front-end becomes more unweidly. To solve this I have used a composite UI with microservices. You can develop composite UI with traditional tools such as ASP.net and you can augment your development process with a with services and libraries like Project Mosaic (https://www.mosaic9.org).
I hope this blog series has helped you gain a better understanding of how to begin your journey to microservices in a legacy environment, how domain-driven design can be used to jumpstart your design efforts, and the tools that are available to facilitate your work.