As the technology infrastructure world moves to embrace cloud-native with wider and open (as in source, as in hugging) arms, the legacy monitoring tools traditionally applied to this new IT substrate do not necessarily always enjoy an easy fit.
From obsolete pricing and delivery models to the undeniable impact of automation and beyond, cloud-native needs a new approach to monitoring, migration and management. So where do we start?
Today we know that IT teams have to build, deploy and manage a sophisticated mix of infrastructure built on scalable cloud services.
A modern enterprise might use a wide range of cloud infrastructure elements such as virtual machines, containers, auto-scaling instances, high-performance storage, content delivery networks, edge computing, various databases and machine learning services to deliver what they hope will be compelling customer experiences.
But as straightforward as that reality is to state out loud, running that kind of mix in live operations is clearly not going to be a simple task. This is the reality tabled by Ciaran Byrne, VP of product management at OpsRamp, a digital IT operations management platform company.
1990s retro-style tech
Byrne’s team explain that they work with customers who are sometimes using monitoring tools that date back to the mid-1990s. Cloud operations managers will know products like Micro Focus Operations Bridge (aka HP OpenView Operations), which was brought to market back in 1993.
It’s not hard to see why organisations would have worries over trusting any technology that is a quarter-century old, let alone think about building new modern cloud-native deployments with highly dynamic workloads on that kind of infrastructure.
While there certainly is a lot of old software out there (Java and Linux have certainly been around for that long), some of which is still used to run modern applications and services, legacy IT operations tools were never designed for the distributed nature of modern cloud infrastructure.
“Legacy tools can shackle organisational innovation, worsen technical debt and divert precious company resources for their daily maintenance. Most of the flagship ‘big four’ monitoring tools were introduced several decades ago and have simply not kept up with the demands of modern cloud operations,” said OpsRamp’s Byrne.
Behind Byrne’s burning beef
Why has Byrne got so much beef with the likes of BMC Software, CA/Broadcom, Micro Focus and IBM here? Because, in his view, these firms have spent a lot of time working to drive shareholder value through mergers. For his money, there has been too much spend focused on selling, general, and administrative (SG&A) expenses, rather than research and development (R&D).
On a perhaps less personal level, Byrne points to the fact that many of the legacy monitoring tools already deployed across the global installed base of cloud are designed to act as on-premises installations i.e. they fail to embrace the now more connected world of SaaS. Alongside and in line with SaaS flexibility, those older ‘solutions’ are far more unlikely to offer modernised consumption-based usage pricing models.
“One of the biggest developments over the last decade has been the proliferation of open source projects such as Prometheus, Sensu, Elastic, OpenTelemetry and Grafana for monitoring cloud and cloud-native environments. The Cloud Native Computing Foundation (CNCF) has been instrumental in incubating projects, curating contributions from different organisations and driving adoption through industry standards,” explained Byrne.
If legacy IT Operations Management (ITOM) vendors have sometimes been comparatively slower to embrace, invest and participate in open source platforms (and we’re being quite kind with that statement), then the pageant of truly open projects above referenced does surely suggest that time has moved on.
Rise of the RPA-bots
Another fundamental reason there could be a disconnect between the old and the new in cloud-native monitoring is the rise of algorithmic intelligence and Robotic Process Automation (RPA) software bots.
Byrne says that the last few years have seen a marked shift from using single-purpose tools to adopting increasingly RPA-boosted digital operations management platforms for handling the volume, variety, and velocity of modern IT environments. He insists that legacy event management tools that require manual rules to pinpoint incident root causes are not appropriate for a world of hybrid infrastructure where the conditions are constantly changing.
“Given the diversity of data sources (metrics, logs and traces) as well as events, notifications and alerts that modern infrastructure generates, there has been widespread adoption of machine learning and data science techniques to consolidate and extract real-time insights for effective cloud operations. But, we have also seen the emergence of RPA that can help reduce repetitive manual work for IT teams as well as drive autonomic responses at scale for incident troubleshooting,” concluded OpsRamp’s Byrne.
Five steps to cloud-native monitoring
Moving onwards then and looking for some practical direction, we can say that migrating to cloud-native monitoring is a five-step process. This is the argument put forward by Andrew Leigh in his role as CMO of Copado, a specialist in end-to-end cloud-native DevOps solutions for admins, architects and developers.
“The first stage is project conception. This must identify the pain points that the cloud migration addresses i.e. the shortcomings of the legacy tech. This is followed by planning and inception as teams are built out, funding put into place and requirements finalised,” explained Leigh.
Stage three is the development and testing stage when teams actually start implementing the migration. The emphasis here should be automated monitoring and the creation of documentation to train users on any changes. Leigh points out that these first three stages are all pre-production i.e. before any go-live deployment actually occurs. The next two stages are in post-production.
“The next stage is supporting users in production. Feedback should be gathered to ensure their needs are continually being met. Every cloud migration and subsequent monitoring layer stays at the production stage until it is ready to be retired. The last stage involves all the end-of-life activities for a cloud service, including migration to a new service,” concluded Copado’s Leigh.
We’ll get there, slowly
The bottom line in this whole discussion appears to hinge around the reality that - as fast and performant as the new breed of cloud tools are - there are still many of the older monolithic monitoring products left in place across many mid-sized and large organisations.
Compound this inconvenient truth with the patchwork of legacy ITOM product suites our there with all their complex licensing agreements (and interwoven application and service dependencies) and you can see that there are few quick-fix routes out of the immediate problem.
The cloud-native horizon is within sight, but, essentially, this is cloud, so expect a few areas of mist and smog. Tread carefully and keep your facemask on.