The Evolution of APM and Cloud-Native Applications

And how observability saved the day.

This post was originally published on the Instana blog.

So, your observability tool is monitoring cloud-native environments. Of course, just as it is with any broad industry topic, the definition of cloud-native has been different from vendor to vendor — even analysts couldn’t agree on a definition. The good news is that after years of flux, the definition of cloud-native applications essentially gelled into a de facto standard:

Distributed, orchestrated (using Kubernetes), containerized microservices operating in a wide array of cloud-based architectures. Cloud-native breaks down applications into microservices, small individual parts that still work together, enabling faster deployment and orchestration.

It wasn’t always so simple. Information technology workers have debated what a “cloud-native” application means (or if it means anything) for almost a decade. The basic definition was an application built to leverage cloud-based technologies. But some said it meant leveraging containers or using some level of PaaS infrastructure or running any workload in a cloud.

Meanwhile, the pace of change was accelerating. Public cloud and hybrid cloud environments became commonplace. Virtual servers evolved into containers, and Kubernetes became the orchestration standard. Container adoption exploded, and workloads began moving to serverless environments. Containers evolved into serverless workloads — all held together by a convergence of resource orchestration. Dev teams became more agile, and cloud hosting platforms semi-automated the cloud migration process.

Finally, everyone joined hands and agreed on the definition of cloud-native.

There was just one problem: legacy Application Performance Management tools don’t have visibility into microservices inside containers in cloud environments.

Incomplete definitions of cloud-native are dangerous

Trying to attain observability in cloud-native environments without knowing exactly what cloud-native means is like competing in a high-stakes game without knowing the rules. A universally accepted definition enables DevOps teams to understand the challenges, advantages and tactics for success. As discussed earlier, common definitions included applications that leveraged containers, used PaaS infrastructure or ran in a cloud.

If you defined cloud-native as just applications that leverage containers, you would include containers that isolate applications from one another while not using microservices or containers that run in an on-premises environment.

If you defined it as applications that use some level of PaaS infrastructure, you wouldn’t address private clouds or public clouds. You also would include applications on a PaaS infrastructure that don’t run in containers and don’t use microservices.

If you defined it as just applications that run in a cloud, you wouldn’t include applications that use containers or that use microservices in an on-premises infrastructure.

Resources in a cloud-native environment can be ephemeral. Containers can be dynamically configured, provisioned, deployed and reused, and several components can be hidden, including the following:

• Network topology (physical and virtual)
• Interfaces (network namespaces)
• Data flows
• Metrics, logs, and traces provide what happened, but miss the big picture

In any of these scenarios, your legacy APM tool would give you information from limited application environments, but they couldn’t deliver metrics, logs and traces from a cloud-native application environment. On the plus side, the acceptance of a cloud-native application definition is proving to be the forcing function for observability tools that can.

Why a cloud-native definition is good for observability

Cloud-native applications have a host of benefits for businesses. Multicloud environments are more scalable, more agile and more redundant than bare-metal servers or even a private cloud. Microservices using containers are more scalable, more agile and faster than monoliths or service-oriented architectures (SOAs).

Not only can cloud-native environments provide better functionality, they can be a source for invaluable and actionable information with the right observability tool. Containerization and cloud architectures make it possible to access and use operating system (and kernel) services directly to examine the following:

• State and operation of the underlying infrastructure (nodes/bare metal servers)
• Attendant services
• Operating system
• Applications

How to take advantage of containers, clouds and microservices

Cloud-based architectures require an observability tool that can see across architectures to see private clouds, public clouds, hybrid clouds and PaaS. Your APM system should collect time-series metrics for all the stacks you are using, including infrastructure components like host, container engine (e.g., Docker) and orchestration (Kubernetes). It should collect the highest possible data resolution and retain it for a useful period. Instana collects time series metrics at 1 second resolution which are retained for 24 hours before rolling up.

For applications running on microservices, you’ll want to look for a solution that has proven it can keep up with new technologies as they emerge. Instana has more than a hundred sensors to provide the largest possible coverage of your environment, with new sensors being added continuously.

Installing a monitoring tool should be as simple as possible, requiring minimal manual effort. Ideally, you should also not have to rebuild your existing container images. Instana uses a single agent approach. In fact, you can deploy that single Instana agent to your Kubernetes cluster with one simple command.

What’s next: Enterprise observability

With enterprise observability, provided uniquely by Instana, you can do more than just monitor individual systems; you can contextualize data about those systems and correlate interactions between discrete applications and systems across your entire IT environment. The foundations of enterprise observability are automation, context and intelligent action.

• Automation: When new code is deployed or system changes are made, enterprise observability automatically and continuously discovers changes and provides immediate feedback.
• Context: Enterprise observability explains how every application component and service interrelates with every other component and service to optimize performance and availability of resources.
• Intelligent action: When changes occur, enterprise observability proactively provides deep analysis with context and suggests steps for system optimization.

Instana observability for cloud-native applications

At Instana, we pride ourselves on delivering a product and service that goes beyond your expectations. We’ve been supporting cloud-native applications for years, and you never have to worry about having visibility into clouds, containers and microservices.

Instana collects time series metrics at 1 second resolution that are retained for 24 hours before rolling up. Instana has more than a hundred sensors to provide the largest possible coverage of your environment, with new sensors being added continuously. Instana uses a single agent approach. In fact, you can deploy that single Instana agent to your Kubernetes cluster with one simple command.

See Instana in action by checking out this “play with” demo.