You have finally decided that it is time to move to a microservices design and reap all the benefits. Let’s go through the the code and start refactoring…but wait. Before you do that, let’s see what are the tools that you need in place beforehand.
The requirements can be summarized as, infrastructural, environments, monitoring and logging. Let’s review each quickly.
Infrastructural needs
As stated before, running a microservices-base application is not exactly like running a monolith. So you will be working quite differently when developing a microservices application. First thing that can probably be put in place, is a Continuous Integration/Delivery pipeline if your organization does not have one. As this pipeline will be critical to your organization when releasing updates, make sure you have a group responsible for maintaining it.
Environments
Even when running monoliths, a lot of organizations choose to run their applications on virtual machines. That is a good start, if you are running on bare-metal. To take a further step, you can use docker as a virtualization technology and with these pave the way to running your application in the cloud. Once you decompose your monolith, you can decide which parts should be running on the virtual machines, which services should run in a docker container and which services can be run directly in the cloud.
Monitoring and Logging
With microservices you’d have to monitor tens to hundreds of services, machines, virtual machines, docker containers, database, etc and this is not an easy task. The monitoring tool that you choose should not only monitor services being up and running, but that they are actually doing work. Logging is also different as each piece of the system will be running on various services (not to mentioned scaling where you have more than one service running for the same task). A better approach to logging is to use structured logging backed by a structure log server that allows searching. Your logs should also use correlation and context so that you can trace a workflow end-to-end, regardless of where it is run.