Building a microservice application is not an easy task in terms of tools you should know. We need different tools in each phase of the life cycle of a microservice application. Development, tests, build and even deployment of our microservice application to the production is not the end of the story. We need to monitor it and react to malfunctions. Let’s see what kind of tools are needed on each phase.
The microservice application’s architecture structures the application as a set of loosely coupled, collaborating services. Each service implements functions related to each other. Services can communicate using synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. There are many definitions saying how big the microservice should be. I like the definition mentioned in the “Building Microservices” book written by Sam Newman:
“Jon Eaves at RealEstate.com.au in Australia characterizes a microservice as something that could be rewritten in two weeks, a rule of thumb that makes sense for his particular context.”
According to the wikipedia, high availability is a characteristic of a system, which aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period. This becoming more important in the microservice architecture. We may achieve high availability by redundancy of our microservices and by balancing the load between many instances of our services. There is a free tool called HAProxy which can help us in this topic. HAProxy is a software load balancer which can be used with TCP and HTTP protocols.
There are many templates we may use for describing our architecture. I recently use free and open source template called arc42. The template defines twelve main sections:
|1. Requirements and Goals||7. Deployment View|
|2. Constraints||8. Crosscutting Concepts|
|3. Scope & Context||9. Architecture Decisions|
|4. Solution Strategy||10. Quality Scenarios|
|5. Building Block View||11. Risks & Technical Debt|
|6. Runtime View||12. Glossary|
It allows for describing things which are essential to understand the system and architecture decisions. In the “Building Block View” we may use the top-down approach for describing the architecture and not going to deeply if it is not necessary. The architecture documented using arc42 is very clean and understandable for all stakeholders.
The development itself does not vary much from any other application development. However, many other tools are becoming essential. The version control system is a must like for example Git. To be able to build our application automatically and to execute unit tests during the build we may use Maven which is a software project management tool. Adding repository managers for storing our artifacts, we are half way to create Continuous Integration and Continuous Delivery practices. There are open source repository managers available like Sonatype Nexus or JFrog Artifactory. In order to automate our builds and testing we may use another tool like Jenkins which is an open source automation server. It also helps implementing and integrating continuous delivery pipelines.
For the implementation of services we have to be familiar with REST in order to be able to build API of our services. Jersey framework may be helpful in implementation communication based on REST. If we use asynchronous communication we will need a messaging server like ActiveMQ or RabbitMQ. At this point it is also worth mentioning the Enterprise Integration Patterns (EIP). They are helpful when we are dealing with messages. The Apache Camel supports EIPs very well. You may check my post describing how to build a web service using Spring Framework and Apache Camel.
During the development we will be using many dependencies together with our service. We would like to deploy the service which is already configured and contains all needed tools and dependencies ready to run. To achieve it we may use Docker container which is an “executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings”. Docker container contains an operating system which our services will be run on. We may use official Docker images based on many operating systems like different Linux distributions. For example there is minimal Docker image with Alpine Linux in size of 5MB only.
Deployment and Configuration Management
Many services talking to each other require configuration like for example proper hosts and ports settings. Deploying all services into many hosts will also take some effort. When we are deploying a new version of a service it is important not to influence its uptime. Therefore deployment should be done automatically using scripts. Ansible is an example of the automation tool which we may use for deploying both the services and its configuration. It can deploy our services to many operating systems and run them there.
Beside unit tests we should also perform other types of tests like integration tests or load and performance tests. For this we also require a tool. Good example of such a tool is combination of Jenkins and Apache JMeter. Using JMeter we may create many test cases and combine them into test scenarios. Each kind of tests scenarios can be run automatically by triggering them from Jenkins. Very nice quick test scenario is for example execution of health checks of our services.
If our services are deployed, we will have to monitor them. We would like to know whether particular microservice is responding or not. It is also worth knowing if other parts of the system are working correctly like message brokers or databases. The very basic way of monitoring is implementation of the health checks of our services. Requesting a health check, the service can respond with HTTP status code 200 which means “healthy” or other status code indicating an error.
In case of any error we would like to check the logs. In case of many running services checking all log files can be difficult. Here comes another open source tool called Logstash. It collects all logs from all services with particular log pattern and sends it to the centralized server like for example Graylog. Graylog provides a GUI interface which helps with analyzing the logs collected by logstash in one place.
Another important information which we would like to get from our working system are various metrics like the amount of processed requests, throughput, load, the number of errors, etc. The Dropwizard Java framework has support for application metrics. After collecting metrics we are interested in, we may expose them via MBeans and monitor them using for example Prometheus or Grafana. They both provide GUIs for analytics and monitoring using the metrics of our services.
Team building tools
Introducing mircorservices often leads to the changes in development teams. Teams are becoming agile and responsible for their products on all phases of applications life cycles, sometimes even deploying to the production. Increasing team autonomy requires good cooperation between teams including very good communication. Tools like chats, video, wikis becoming quite important. Teams are becoming more innovative. They are able to implement new ideas and testing them more quickly comparing to the company wide processes. Communication, teams and innovation are three pillars of microservice culture.
There are many tools which can be used for building microservices. In this post I introduced only some examples. The more important thing is that there are many areas we need to know while dealing with microservices. Starting from the architecture through development, testing, monitoring and even team cooperation changes require a set of different tools. I think that even the best tool will not help if the team will not work. Communication is crucial both inside the team and between the teams.