For many, this is when it gets really interesting. Based on our experiences and challenges with Microservices, we have put together a number of components and areas that you will need in order to support your initiative.
Microservices initiatives that end up in ”Death Star” type architectures or ”maintenance manias” are simply put not very successful and potential benefits and gains will not be achieved. But how do you end up there? Implementing Microservices when they are not properly controlled and monitored or failing to adhere to guidelines, could very well give you these end results. The right tooling however can help you and your organisation to avoid these mistakes or at least give you prior notice when you risk ending up with these types of problems.
With this blog post and the corresponding step in our Microservices model, we introduce areas where you need some tooling or supportive software to stay in control of your initiative and avoid later maintenance problems.
Service Discovery
Allows Microservices to register themselves at runtime when they appear in the system landscape. When registered in the Service Discovery, Microservices become callable by name rather than by address.
Load balancing
Load balancing is required to allow you to balance the load between different instances of the same Microservice. For your Microservices to support this, you need load balancing capabilities built into all your Microservices.
Circuit breaker
When a chain of requests through several Microservices is broken, you need functionality to avoid your Microiservices to keep requesting a response from a broken or malfunctioning Microservice. A solid circuit breaker approach also means good error handling and being notified automatically when a chained request is not performing as expected.
Monitoring
Monitoring tools can be used for various purposes such as monitoring the hardware usage and performance. This makes it possible for your DevOps organisation to tune the capacity required to run the environment. With modern cloud based payment models, it might even be possible to optimize the usage of your computing capacity over the day based on spikes in usage. Monitoring tools can also be designed to send your DevOps team messages or alarms when unexpected or unwanted things occur. From a software architecture perspective, monitoring tools can also provide valuable metrics and diagnostics from Microservice usage (such as which Microservices are called often and may be not performing as expected). Metrics can also show which Microservices are running and which are not. Information can be used to fine tune the architecture and identify potential issues at an early stage.
Dynamic routing/Edge server
When the landscape is modified, either by adding or removing Microservices, you need dynamic routing capabilities to allow your requests to dynamically find their way through the varying Microservices landscape. To achieve this you have the possibility to add routing rules that will be handled by an Edge server.
Central configuration server
Each Microservice should be able to fetch their configuration from a central location, so that when started (boot strapped) they will have access to the latest configuration. This allows you to update and control your configuration from one central place and not have to manage configuration in each of your deployed Microservices.
API security
In the digitized world in general and in a Microservices architecture in particular, Microservices, applications and IT systems exchange information with each other continuously without human interaction. How do we ensure that a Microservices or application that wants to communicate with us really is the one we think it is or that it claims to be? With an Identity Management provider included in your architecture, you let it handle this authentication for you. Example products are WSO2 Identity Server, Keycloak and Curity.
Centralized log analysis
With log forwarding tools it will be possible to monitor your Microservices architecture implementation from one place. Examples on log forwarding tools that you should evaluate are Splunk, Graylog and the ELK stack.
Tracing
Over time you will have a number of Microservices communicating with each other. A message will often be routed through several different Microservices before it ends at the intended location with its message. Tracing tools allows you to track messages through call chains of Microservices.
API Management
An API manager should be used to stay in control of API life cycles, versioning, access to APIs and other things related to the maintenance of the many APIs that will allow your Microservices to communicate with each other. Choose the API Manager of your choice to achieve this. A few examples of API Management products are WSO2 API Manager, 3scale, Kong, Tyk and MuleSoft API Manager.
Learn more about our Microservices Ready model here
