Microservices Without Observability Is Madness

As I said before, Speed is King. Business requirements for applications and architecture change all the time, driven by changes in customer needs, competition, and innovation and this only seems to be accelerating. Application developers must not be the blocker to business. We need business changes at the speed of life, not at the speed of software development.

Thirteen years ago much of my time was spent helping customers rearchitect their monolithic applications into service-oriented architectures (SOA). We broke the applications into self-contained, reusable, stateless business functions which could be managed, modified, tested, reused, or replaced individually without impacting the rest of the application. This enabled business agility, reducing cost and improving time to market.

Over the last ten years or so, companies have been exploring the benefits of the cloud. Initially, this was also quite monolithic i.e. lifting and shifting large applications onto outsourced virtual servers or outsourcing email or CRM to web-hosted providers. However, more recently we’ve started to see newer applications being developed with finer-grained components stored in the most appropriate place. Confidential data may be stored on-premise, open APIs can enable public lookup services, the CRM can be integrated with the marketing functions and the internal cloud-hosted product warehouse. A single business application is typically spread across a hybrid cloud of different cloud providers, and on-premise services.

They are at risk of sprawling so much that no one knows how they work or how to maintain them and they will be a blocker to innovation again. The drivers behind SOA are here again. Applications need to be designed as combinations of smaller self-contained, loosely coupled, stateless business functions or microservices.

Management of these microservices is even more powerful than it was with SOA. They can be quickly pushed out by DevOps, moved between clouds, they can be ephemeral and serverless and containerized using container services such as Docker and Red Hat OpenShift.

So, a single business transaction can flow across many different services, hosted on different servers in different countries, sometimes managed by different companies. The microservices are being constantly updated, augmented, migrated in real-time. The topology of the application can change significantly on a daily basis.

It’s amazing that we’ve had so many software development innovations to enable this rapid innovation for our lives. But what happens if something goes wrong? What happens when a transaction doesn’t reach its target? Who knows what the topology is supposed to look like? How can it be visualized when it’s constantly morphing? Who knows where to go to find the transaction? How can you search for it and fix it when it could be anywhere on any technology?

Nastel XRay addresses this. XRay dynamically builds a topology view based on the real data that flows through the distributed application. It gives end-to-end observability of the true behavior of your application in a constantly changing agile world. It highlights problem transactions based on anomalies and enables you to drill down to those transactions, carry out root cause analytics and perform remediation. It would be madness to have access to all the benefits that microservices can give you and not use them to the fullest extent just because your monitoring and management software and processes can’t keep up.