By Marco Fioretti
The microservice architecture shortens development and deployment time of large, highly scalable online platforms… if those platforms are developed and managed with the right tools. Here we present the major categories of applications that would be useful for developing microservices, focusing on areas or phases of development and omitting full featured, one-size-fits-all frameworks, for two reasons. One is that, for better or for worse, the field is so dynamic and there are so many tools that any list would be incomplete or out of date upon being written.
The other, more important reason is that focusing on development areas makes it easier to give an idea of the main, underlying issues that should always be considered, before starting any kind of microservice development.
This is the last in a five-part series on microservices; before digging into this topic, you may want to first read the earlier pieces in this series, Microservices: Definition and Main Applications, APIs in Microservices, Introduction to Microservices Security, and How Microservices Work Together.
Languages
Microservices development can happen in many languages, from general purpose workhorses like Python to specialized tools like Ballerina, with Golang, Java EE, ASP.Net, Node.JS and many more in the middle. Sometimes, an organization may be tempted to always use only one of those languages, usually the one already known by a team, for all their microservice projects.
In reality, this would be both wrong in principle (because it would often preclude usage of well-tested, immediately available code) and pretty hard to achieve in practice for a lot of reasons, from differences in initial requirements to the convenience of reusing code from previous projects, or using existing third party libraries. Therefore, maybe the only suggestions about choosing languages or libraries that would be valid for most microservice projects are to look for support for features like high observability of the code, concurrency, high-performance I/O capabilities, and testing automation.
Containers, and their management
The main use case for microservices is online platforms that must scale or change very quickly to follow business demands. So far, the most popular tools to deploy microservices in such scenarios are some version of those lightweight alternatives to virtual machines called containers. As of early 2022, the most popular, but by no means the only choice remained Docker. This situation may change now that Docker deprecation by Kubernetes has been finally implemented. Whatever container engine one uses for microservices, however, there must be the possibility to lock it down for security, as we mentioned here.
Regardless of their content, the actual deployment, scheduling and load balancing of containers requires dedicated tools that can run on-premise, or as cloud services, or as a combination of both, to automate operations, maximize security and minimize the probability of errors, for example decoupling container configuration from container images. For Docker, the most popular solution is Kubernetes, alone or side by side with frameworks to connect and secure microservices like Red Hat’s OpenShift.
Communications, and testing them
When microservices need messaging and service discovery to communicate, it is possible to implement those functions with tools like,to make just a few examples, Apache Kafka, RabbitMQ or Amalgam8.
However they happen, communications among all the microservices of a platforms, or between them and (via API Gateways) the outside world are usually harder to test than with monolithic architectures. This testing, however, may be facilitated, and integrated with other phases of development, by software like Tyk, API Fortress or Postman.
API Management
We saw in a previous article how crucial and complex APIs for microservices can be. That is why they should be developed and managed in an integrated way, that makes it easier to load or create APIs to connect microservices not just among themselves, but with external services, from databases to authentication. One example of how to handle these tasks is DreamFactory.
Application Performance Monitoring (APM)
Finally, you want to consider how you will monitor the performance of your applications. Programs for application monitoring are nothing new in software engineering, but when it comes to microservices, traditional solutions have the same problems of those for testing: they were designed, that is, to handle monolithic applications, not continuously changing clusters of small components, scattered all over the Internet.
Proper APM of such platforms, to spot as soon as possible faults, bottlenecks or any atypical behavior, is a different game. As a minimum, there is more data to collect in real time in many more locations, both on the front-end and on the back-ends of the platform. In both cases, the ultimate goal is to improve the user experience, expose performance bottlenecks and minimize the mean time to repair faults (MTTR). More in detail, front-end APM must gather and analyze metrics about what end-users see, from JavaScript errors in web apps or pages to the average time needed for content to load, or to react to user actions.
Back-end APM, instead, must focus on the internal microservices and servers, looking for example at server loads or number of database requests per seconds, or checking that memory usage never exceeds some threshold. In this space, it is worth considering combinations of open source tools like Prometheus, Graphite, Kibana or Grafana, that may be initially harder to or more expensive to configure than proprietary, fully integrated solutions, but at the same time are fully customizable, and free of risk of lock-in.
