KEMBAR78
Gaining Observability in Cloud | PDF | Cloud Computing | Computer Science
0% found this document useful (0 votes)
14 views15 pages

Gaining Observability in Cloud

The document discusses the importance of observability in cloud-native applications, highlighting the challenges traditional monitoring tools face in modern environments. It emphasizes the need for comprehensive observability solutions like IBM Instana, which provide actionable insights and support for dynamic, distributed architectures. The benefits of adopting observability include faster incident resolution, improved system health, and enhanced customer satisfaction.

Uploaded by

kishor bhole
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views15 pages

Gaining Observability in Cloud

The document discusses the importance of observability in cloud-native applications, highlighting the challenges traditional monitoring tools face in modern environments. It emphasizes the need for comprehensive observability solutions like IBM Instana, which provide actionable insights and support for dynamic, distributed architectures. The benefits of adopting observability include faster incident resolution, improved system health, and enhanced customer satisfaction.

Uploaded by

kishor bhole
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

IBM Instana

Gaining
observability
in cloud-native
applications
Contents 01 → 06 →
Introduction The risks in not adopting
observability in cloud-native
02 → environments
Cloud-based versus
cloud-native technologies 07 →
Benefits of observability for
03 → cloud-native applications
Observability in
cloud-native environments 08 →
Introducing enterprise
04 → observability
Observability challenges
09 →
05 → About IBM Instana
Critical characteristics
of observability for
cloud-native environments
01

Introduction

The widespread adoption of diverse The changes to the application tech stack Thus, the concept of observability—in many
cloud-native technologies has resulted were swift. Cloud environments, public forms—emerged as organizations battled
in significant changes in application and private, expanded, virtual servers with the need to accelerate development
development, delivery and operations, evolved into containers, and Kubernetes and delivery while maintaining the visibility
leading to a new competitive landscape. became the orchestration standard. IT operations teams expected from APM
Faster organizations are capitalizing on Container adoption exploded and evolved tools. But observability has its challenges,
this shift to outmaneuver their larger, into serverless workloads in serverless including many of the same faced by
slower counterparts. environments while Dev teams became traditional monitoring tools. Speedy,
more agile. As software and infrastructure flexible application delivery organizations
blurred, two competing constants emerged: such as Dev, Ops, DevOps, and SREs,
want to use the entire set of cloud-native
– Application performance monitoring technologies. To do that, they need a
(APM) became an important contributor comprehensive approach to observability
to business success. that takes advantage of the best practices
– It was difficult to gain visibility into of developer-driven visibility and modern
modern applications using traditional APM solutions.
APM methodologies.

Previous chapter Next chapter 3


02

Cloud-based
versus cloud-native ↓
technologies Cloud technology has been a real add a layer of on-premises hosting to the Cloud-based applications have been
watershed in terms of application mix, modern technology stacks can exert retrofitted for operation in the cloud.
development. Cloud and multicloud additional pressure on development teams,


environments provide more power and making it challenging to ensure timely
redundancy, but this necessitates the delivery of applications.
modernization of applications. While
cloud-based applications have been Monitoring the performance of cloud- Cloud-native applications were
retrofitted for operation in the cloud, native applications can also prove developed specifically for cloud.
cloud-native applications were developed challenging because it can be difficult for
specifically for cloud deployment. traditional APM and observability tools to
However, whose cloud are we referring see inside cloud-native elements such as
to? As companies opt for multicloud containers as easily as they see into other
environments, the complexity increases. application stacks. In contrast, cloud-native
Hybrid clouds, which comprise a mixture observability platforms tend to track all the
of private and public clouds, further metrics, event traces and logs across the
compound this complexity. When we full stack to provide broader visibility.

Previous chapter Next chapter 4


03

Observability in cloud-native
environments
The technologies that make up modern Lack of backward compatibility Orchestration information correlation
cloud-native technology stacks present Containers are purposely built to Kubernetes blurs the lines between
some specific obstacles for traditional contain only required services to keep software and infrastructure to the
monitoring tools: them lightweight, which means older point that existing tools may have
instrumentation engines may not to use multiple agents just to extract
have access to required services basic data, which would eliminate the
needed to work. ability to directly correlate information.

Serverless elimination Accelerating development


Serverless architectures take the service and deployment rates
elimination ideal to an even greater level by As changes occur in the application
taking the servers from local control to the environment due to the ephemeral
cloud platform, leading to the same service nature of containers, it can be difficult for
availability issues. traditional monitoring tools to reach their
accustomed level of visibility.

Previous chapter Next chapter 5


Observability in
cloud-native environments

As traditional APM tools struggled to meet


requirements in cloud-native environments,
alternatives for application observability
emerged thanks to other factors:

– Developers became more involved in


operating production workloads and
assuring application performance.
– Cloud-native tech stacks enabled
accelerated development and
application pipelines, meaning more
pieces could be operating with visibility
gaps from existing tools.

Observability provides external indicators of


the health and status of applications inside
cloud-native elements such as containers,
microservices, orchestration tools such as
Kubernetes, and serverless environments
from a performance perspective.

Previous chapter Next chapter 6


04

Observability challenges

From “black boxes”—the hidden internal Traditional monitoring tools can’t handle Containers host a wide variety
workings of a product or program—to distributed microservice environments of workloads
massively short-lived deployments, the Environments for container-based Containers can host various types of
cloud-native stack creates numerous applications tend to be dynamic, workloads, ranging from monolithic
challenges for observability and APM tools: distributed microservices, deployed applications like Apache HTTP servers
across clusters of servers that are also to Java virtual machines and databases,
dynamic. One complete application could creating complex monitoring challenges.
cross different kinds of infrastructures, The outsourced persistent data storage on
platforms, languages and technologies. permanent servers in a hybrid environment
further complicates matters. With such
Traditional infrastructure and workload variability in containerized
application monitoring tools were environments, monitoring tools must
designed for monolithic applications support a diverse range of technologies,
mapped to static individual servers, and architectures, and configurations, making
they tend to focus on providing visibility it a daunting task.
at the language level. These traditional
monitoring approaches can break down Traditional monitoring tools can be
in the face of microservices distributed challenging to configure for containers,
across a large cluster of servers composed as every container is different, and it's
of multiple languages, middleware difficult to determine the thresholds to
components and database systems. set in advance for each one. Additionally,
monitoring tools must be automated to
handle unpredictable workload types as
manual configuration and enforcement of
monitoring policies are not feasible.

Previous chapter Next chapter 7


Observability challenges

Containers require elevated monitoring Kubernetes is not a performance


Container platforms typically include only monitoring tool
basic monitoring functionality, but the Container orchestrators such as
stats tool is insufficient for monitoring Kubernetes are great for organizing,
large-scale production environments. This provisioning and managing the
separates containers from other application deployment of their production
infrastructure technologies. container environments and applications.

Similarly, operating systems provide But orchestrators are not designed for
significant data about system performance, monitoring, and although they have
but they don’t include application-level tremendous focus on container and host
data. Even advanced virtual machine resources, orchestration management
platforms such as VMware, which include includes no aspect of user experience or
relatively sophisticated monitoring tools, application performance.
fail to provide application layer data or
distributed tracing. Furthermore, container orchestrators can
only manage things that they are aware
of—which mean the infrastructure and
services running in containers. In a hybrid
environment, container orchestrators, by
definition, don’t monitor resource usage
of any other resources. That can leave a
large part of your environment at risk for
performance problems.

Previous chapter Next chapter 8


05

Critical characteristics
of observability
for cloud-native Visibility is the heartbeat of cloud-native Other critical characteristics include: Cloud-native deployment
environments observability platforms. The ability to
monitor containers from within is a critical All the data
Cloud-native observability tooling
integrates seamlessly into cloud-
feature for dynamic microservices- DevOps must have access to complete native application environments,
based architectures in which tracing and analysis to understand exactly how, when fully automated deployments and
dependency maps can be a challenge. and where problems exist. The only way to instrumentation processes.
achieve this is to capture a distributed trace
Even with the ephemeral and sometimes of every request—no gaps, no sampling Root cause analysis
incomplete nature of containers, cloud- and no proxies. Additionally, every piece Regardless of how complex your
native observability provides actionable of the infrastructure, platform and line environment is, DevOps teams must
insights to turn your teams from passive of code deployed into the containerized identify and resolve performance issues
observers into active participants who environment must support tracing. as quickly as possible. An observability
can resolve and even prevent issues. solution must be able to automatically
Agents knowledgeable in containerized point you to where and why distributed
microservices can map the resources in an applications break down.
IT architecture, even when those resources
are barely related and constantly changing.

Previous chapter Next chapter 9


06

The risks in not adopting


observability for cloud-native
environments For some organizations, deploying – An undetected error could result in
observability for cloud-native customer-facing service degradation
applications may not be a priority, or an outage.
perhaps because their APM solution – Delays from time of incident detection
isn’t presenting an alarming number to the time of discovery by a human
of errors or because their teams would could be the difference between
need to learn a new platform. incident prevention and major incident
management.
But if your traditional monitoring solution – Your monitoring tool could find an issue
is missing errors, transaction latency and but not provide enough contextual
opportunities for optimization, you might information for you to react.
not be aware that you need an enterprise
observability platform. Delay comes All these scenarios represent potential
with risk: damage to your reputation, loss of
revenue due to downtime, and affect
your customer experience.

Previous chapter Next chapter 10


07

Benefits of
observability
for cloud-native Of course, the primary benefit of a more Reduce mean time to repair (MTTR) Healthier systems
applications comprehensive monitoring solution is to
discover issues and prevent incidents. With
Event correlation can be the difference
between triaging an incident for hours and
The natural output of an observability
tool in a cloud-native environment with
observability, transparent and observable resolving an impending issue before it can DevOps means systems with fewer errors
systems allow engineers and SREs to even happen. and more efficient processes.
free up the time–previously required for
continuous monitoring–and focus on higher Shift left Happier customers
value-added tasks like producing new The earlier your engineers and developers As a customer, how long would you
product features for customers. can become aware of an issue, the more continue to pay for an application
proactive and less reactive they can be, or service that has errors, responds
Faster continuous integration/continuous and the less impact every issue will have. slowly, experiences downtime and
deployment (CI/CD) processes, less wasted threatens your business?
work, fewer errors and happy customers Reduce CI/CD impact
save time and money. But IBM Instana™ Observability makes it easier to track
offers much more: the success of a canary release or a
blue/green deployment in progress.
Once unsuccessful code is released
into production, damage is done.

Previous chapter Next chapter 11


08

Introducing enterprise
observability
Although observability can deliver the – Systematic optimization
signals you need to track application Enterprise observability focuses not on
performance, getting to a truly comprehensive managing the health and performance
understanding of your entire system is of individual applications or systems but
better served by enterprise observability. on optimizing the entire IT environment.
That means mapping and contextualizing
With enterprise observability, you can do all resources within the architecture,
more than just monitor individual systems. even if they are constantly changing or
You can contextualize data about those loosely coupled.
systems and correlate interactions
between applications and systems – Complete contextualization
across your entire IT environment. The Every unit of observability data must be
foundations of enterprise observability delivered with complete context. Teams
are automation, context, intelligent action, cannot rely on sampling and guessing;
remediation and ease of use. they need end-to-end tracing and
contextualization.
More specifically, enterprise observability
is founded on several key practices
and principles:

Previous chapter Next chapter 12


Introducing enterprise
observability

– Cloud-native deployment – Observability across the pipeline Automation Intelligent action


Enterprise observability tooling Teams must be able to monitor and When new code is deployed or system When changes occur, enterprise
must be able to integrate seamlessly contextualize application behavior changes are made, enterprise observability observability proactively provides deep
into the cloud-native application starting at the beginning of the CI/ automatically and continuously discovers analysis with context and suggests steps
environments that it supports. CD pipeline and continuing through changes and provides immediate feedback. for system optimizations.
The deployment and instrumentation to deployment. You shouldn’t have to
processes are fully automated. wait until a new application release is
in production to be able to understand
– Comprehensive support how it interacts with other systems and
for data ingestion optimize its behavior.
Modern enterprise application
environments expose data in various Context Ease of use
ways: as standard output or conventional Enterprise observability explains how As organizations roll out agile development
logs or through open-source monitoring every application component and service processes, increase the frequency of
APIs. Enterprise observability tools must interrelates with every other component their application updates and fill their CI/
support all data formats to ingest and and service to optimize performance and CD pipelines, more stakeholders require
contextualize every data source. availability of resources. actionable information.

Previous chapter Next chapter 13


09

About IBM Instana

IBM Instana, provides an enterprise These capabilities provide actionable


observability platform with automated feedback needed for customers as they
application performance monitoring optimize application performance, enable
capabilities to businesses operating innovation and mitigate risk, helping
complex, modern, cloud-native applications DevOps increase efficiency and add
no matter where they reside—on premises value to software delivery pipelines while
or in public and private clouds, including meeting their service-level and business-
mobile devices or IBM zSystems™. level objectives.

Control modern hybrid applications with


IBM Instana’s AI-powered discovery of Explore IBM Instana
deep contextual dependencies inside
hybrid applications. IBM Instana also
provides visibility into development IBM Instana free trial
pipelines to help enable closed-loop
DevOps automation.

Previous chapter Next chapter 14


© Copyright IBM Corporation 2023

IBM Corporation
New Orchard Road
Armonk, NY 10504

Produced in the United States of America


May 2023

IBM, the IBM logo, IBM Instana, and zSystems are


trademarks or registered trademarks of International
Business Machines Corporation, in the United
States and/or other countries. Other product and
service names might be trademarks of IBM or other
companies. A current list of IBM trademarks is
available on ibm.com/trademark.

This document is current as of the initial date of


publication and may be changed by IBM at any time.
Not all offerings are available in every country in which
IBM operates.

It is the user’s responsibility to evaluate and verify


the operation of any other products or programs with
IBM products and programs. THE INFORMATION IN
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT
ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING
WITHOUT ANY WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND ANY
WARRANTY OR CONDITION OF NON-INFRINGEMENT.
IBM products are warranted according to the terms
and conditions of the agreements under which they
are provided.

15

You might also like