Understanding what it takes to monitor and support applications using Microservices Architecture.
Microservice Architecture is an architectural practice and a way of life in which each service is self-contained and implements a single business capability around an application for small independent services. Below is the comparison how a Microservice Architecture is built by bees and human’s.
What throttles Microservices based Infrastructure and application Architecture.
Microservices were invented for the new generation market. Businesses wanted to analyze their knowledge and business data, innovate, and launch new products and services quicker than their competitors. They knew they must be versatile to fulfill the dynamic desires of their customers. Development and Migration to microservice design allow them to try this exponentially.
Throttling Factors
- Business growth: web-based business and web content consumption have exponentially scaled the customers to new heights causing more transactions and companies responded with Microservices Design
- Traffic peaks: Scaling monolithic applications can often be a bottleneck. Microservices architecture helped in scaling IN and OUT
- Time-to-market: When businesses wants to add or modifying any features, it takes days or weeks instead of months and doesn’t require excessive regression testing
- Operational Agility: It’s challenging to achieve operational agility in the repeated deployment of monolithic application artifacts. DevOps and CI/CD are part of the modern Microservices Agility Development
- Development Agility: Monolithic applications are implemented using a single development stack, which can limit availability. The complexity of adding new functionalities on top of the existing monolith application
Monitoring Challenges
- Application topology visualization challenge
- Capturing metrics which are distributed across many services and instances
- Heterogeneous microservices makes things more complex. A single monitoring tool may fail to support it
- Monitoring continuous deployment pipeline to ensure that new code is performant is a challenge
- End-user experience monitoring
- Managing and Monitoring custom application performance metric APIs
Support Challenges
- Each service may have different SLA and Business Impact
- SLA classification for New Service must be predefined and informed
- Microservices deployment topologies are dynamic, making it impossible to preconfigure servers, instances, and monitoring parameters
- End-to-end transaction tracing
- Managing a ITIL Processes for Microservices
- Identification of acceptable QoS levels to cope with existing or future SLAs
How to approach microservices monitoring challenges
Apply the modern monitoring methodology along with granular metrics collection to overcover come the challenges. In the microservices world, the sources of truth are many.
Monitoring Methodology: Collect Application and Platform Metrics
Monitoring microservices effectively is a challenge, as many of the traditional monitoring techniques are not suited to provide the required metrics for performance and availability. So, the IT industry adapted and evolved the below-monitoring methodology, which could help solve the challenges.
Collect metrics that report the entire schema of your infrastructure. These metrics relate specifically to your application behavior and problems. Instrument a service to gather statistics about individual operations. Aggregate metrics in centralized metrics service, which provides reporting and alerting.
Methodology’s
- Google SRE – 4 Golden rules: Latency, Traffic, Errors, Duration
- RED – Requests, Errors, Duration
- USE – utilization, Saturation, Errors
Below are five telemetry signals which need to be emitted for effective monitoring:
- Latency — Response time, including queue/wait time, in milliseconds
- Saturation — System overloading, which is related to utilization and queue depth measurement
- Utilization — The percentage of time a resource is in use
- Rate — Request rate, in requests/sec
- Errors — Error rate, in errors/sec
How to approach microservices Support Challenges
SLA’s and error budget will define the support challenges, tie them to your business objectives, as an end goal is to provide value to customers.
- Each service should have its own Service Level Agreement
- Create an SLA basket and dashboard for Services Supported
- Which team should resolve — Identify services, platform and ownership
- Collect data to re-define: SLAs – Service Level Agreements, SLOs – Service Level Objectives and SLI: Service Level Indicators over a period
- Visualize performance and availability with SLO-focused dashboards
- Cognitive load – Training helps to decouple the number of services you can support from the team size. Improves SLA Response time
- Strong On-Call Support Process – Since the first line of defense is the architecture itself, auto-healing and redundant Services. However, one oncall person with developer skills would require for support
- Integration with the ticketing system for event co-relation.
How Microservices Architecture Feature affect monitoring and support
Micro Services Architecture Features | Monitoring | Support |
Decoupling | There is no hard count on servers. only min and max count.
Autoscaled and Metrics based. |
No Definitive Infrastructure.
Hosts, all Flyby. |
Componentization | TOne Component One Service. | Each service needs different monitoring parameters. Indicative that each service can have different SLA and Business Impact. |
Continuous Delivery | Frequent deployment, New Services Monitoring Parameters. | Mapping Services to SLA and Monitoring. |
Decentralized Governance | TEach service and can have its technology stack.
Monitoring varies from Langangues and libs. |
It could become a case where the new service cannot be monitored and support with existing tools. No monitoring No Support. |
Agility | Monitoring also need to scope as part of agile development (New requirement). | SLA classification for New Service. |
Conclusion
Microservice architectures are even more distributed than a typical monolithic application. Building a monitoring and support system for Microservice architectures is complex and attention to detail must be curved out from the very beginning of a Product or Application lifecycle. Monitoring requires contributions from both the development and operations teams. They need more real-time attention and proactive monitoring. It’s just as important to collect relevant data as it is to analyze the data that is collected. Operations teams must gather data not only from applications, but from the supporting platforms and deployment systems. Open source and paid solutions are available for monitoring and support to operational delivery excellence to the customer.
For further understanding of what it takes to monitor and support applications using Microservices Architecture get in touch with an Altran expert today.