Microservices are a hot topic in IT circles these days. The idea of a modular approach to system building – where you have numerous, smaller software services that talk to each other instead of monolithic components – has many benefits ...
Development teams love change. They're incented to push boundaries and respond to shifting circumstances. Operations teams not so much. Their job is to control change and mitigate risk so it doesn't undermine the stability and reliability of business.
Nowhere is this divide more painfully apparent than when you're deploying new applications. Development tosses a software release over to Operations, and expects them to maintain it. Operations then tweaks the configuration files to match the production environment. New scripts (and potential bugs) are introduced, and new problems ensue. But when Development is called in to fix the problem, they don't recognize what they see, because production and development environments can be drastically different.
This is the classic Development vs. Operations disconnect. Add the cloud to the mix and things get even muddier. The cloud is a "black box" where organizations lack direct visibility and control over workload performance and service health.
Just imagine an on-premises database connected to cloud hosted application servers, integrated with a data center-housed web front end, all shipping data to and from SaaS-provided components. This isn't an uncommon scenario today. Not to mention, these workloads tend to be smaller, more dynamic and more short lived than traditional IT services, making them even harder to monitor and optimize.
Development and Operations use different tools to monitor and manage their respective infrastructures. Development tools tend to be more technical, invasive and expensive – used in specific situations to debug, tune and tweak – whereas Operations tools need to be more intuitive, adaptable and end-user focused, because they are running all the time, even when no one is looking. With infrastructures that span multi-cloud environments, today's IT organizations need APM solutions that bridge the gap between Dev and Ops, monitoring the entire cloud application stack from server to website to web application.
Neither APM services nor cloud monitoring services have yet to truly bring a unified DevOps toolset together. Newer APM tools are for developers who require deeper code diagnostics, exceptions, and real user monitoring (RUM) delivered simply, efficiently and more cost-effectively than traditional enterprise. On the other hand, cloud monitoring solutions focus on infrastructure operations visibility at production-scale and speed. Each touches the other side – APM offering simple server monitoring, and cloud monitoring providing application component monitoring – but neither fully satisfies the need the way the other does.
A critical question is whether the sheer momentum of developer-led markets such as APM will force DevOps teams to use developer-centric tools for operations purposes. Or, will viable standalone markets emerge that can fuel both sides of Dev and Ops based on the need for specialization? Or perhaps there's another possibility – a solution may emerge that balances the requirements of Dev with the requirements of Ops to fully meet the needs of the DevOps discipline.
App Ops is an emerging discipline in which development, production, operations and business application teams align to drive greater efficiencies in application release processes, and ongoing management. Time will tell if this practice can ultimately bridge the gap with a single view of the world that includes affordable pay-as-you-go pricing, zero admin installation and configuration, and dynamic scaling to meet evolving business needs.
Eric Anderson is CTO and Co-Founder of CopperEgg.