DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Five Java Books Beginners and Professionals Should Read
  • Designing a New Framework for Ephemeral Resources
  • What to Pay Attention to as Automation Upends the Developer Experience
  • Reactive Programming

Trending

  • Five Java Books Beginners and Professionals Should Read
  • Designing a New Framework for Ephemeral Resources
  • What to Pay Attention to as Automation Upends the Developer Experience
  • Reactive Programming
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. O11y Guide: Who Are the Cloud-Native Observability Players?

O11y Guide: Who Are the Cloud-Native Observability Players?

Continue on a journey into the world of cloud-native observability: go out onto the playing field to understand who the players are and what teams they form.

Eric D.  Schabell user avatar by
Eric D. Schabell
CORE ·
Updated Oct. 04, 22 · Tutorial
Like (2)
Save
Tweet
Share
6.27K Views

Join the DZone community and get the full member experience.

Join For Free
This is a continuation of the series taking you on my journey into the world of cloud-native observability. It's a world that is altering the way developers work in their daily jobs, creating new teams, and there are roles appearing to attempt to keep control of the cloud-native complexity that these large-scale architectures deliver.

Black and white photo of a person looking through hazy glass ball

The first article in this series covered how developers have to deal with more than just code in a cloud-native world. It shared a look at cloud-native observability (o11y) and touched on what the three pillars are versus the three phases of observability.

This second article takes you out onto the playing field where you need to understand who the players are and what teams they form. It's no longer a world full of developers and operations teams as the cloud-native environments have pushed right on through those traditional walls.

Let's dive right in, shall we?

The basic introduction started from the point that developers are in a world without clouds and then made the transition to a cloud-native development world. What does this mean for them and what are some of the challenges they are having to embrace?

The Playing Field

Over time the traditional developer and operations teams saw a transition to different ways of working in the cloud-native world. The developers transitioned into DevOps teams where the operations activities merge and attempts are made with process agility. Organizations have tried DevOps, moved to platform engineering, and then moved to a more mature structure called CloudOps with a clear focus on cloud infrastructure. Beyond this, we're seeing today a role emerge known as Site Reliability Engineer (SRE), who's part of a team that is focused on a broader spectrum of modern resource reliability and not just for the organization's cloud infrastructure. Finally, at the larger scale of cloud-native operations, there is a new kid on the block, known as the site reliability team. Three large computer monitors with code

Let's look at each one, shall we?

DevOps Teams

DevOps is a first step on the road to cloud-native operations and bridges both development and operations teams. As defined in the article "DevOps vs. CloudOps - What You Need to Know," you see that they have a specific mandate:

"DevOps is primarily the automation and optimization of the application development lifecycle, including post-launch fixes and updates. It uses continuous development, integration, testing, and deployment of cloud, computer, and downloadable applications. It also focuses on IT operations as they relate to application performance and availability."

By bringing operations and development closer to focus on processes and automation, they are making the push for agility, reliability, and speed for business goals within their organization. It remains focused, often due to the existence of more than just the cloud-native infrastructure, on application development and delivery.

Platform Engineering Teams

The next team to appear on the scene is one that takes the lessons learned from the DevOps experience and owns the engineering self-service experience as defined in "What is Platform Engineering?":

"Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era."

The idea is that if the experience is more self-service and pre-defined infrastructure for the deployment of engineering projects, then deploying code will become less time-consuming for developers.

CloudOps Teams

The definition given by Professional DevOps.com puts CloudOps at the center of a business operational focus.

"...CloudOps provides organizations with proper (cloud) resource management. In an organization, CloudOps uses DevOps principles and IT operations applied to a cloud-based architecture to speed up the business processes."

Single cloud over a forest and lakeThis is a shift towards operations focusing on the cloud-native infrastructure more specifically than the other possible infrastructures available in an organization. Once the footprint of dependency on infrastructure choices from the past has been reduced, these teams are scaled up to ensure the improvement of development architecture (infrastructure in the cloud). They focus on simplification of cloud provisioning, application deployment to the cloud, and are big users of observability platforms for both application and infrastructure in the cloud.

Site Reliability Teams

Oscar Wilde once said, "With age comes wisdom, but sometimes age comes alone." As organizations become more active in a cloud-native world and scale up to full CloudOps teams alongside their DevOps teams, there is another role emerging to fill a gap left behind. That role is an SRE and they don't only focus on the cloud-native infrastructure. As noted by Chris Tozzi:

"...an SRE is an all-purpose role that aims to manage reliability for any type of environment."

SREs have to use both IT operations and development strategies to ensure that there is a focus on one thing, and one thing only: reliability. It's a full-time job avoiding downtime, optimizing the performance of all applications, and supporting infrastructure regardless of whether it is in the cloud-native world or not. Together with CloudOps teams, they are a very active player in cloud-native observability and the platforms used to assist them. They have a vested interest in cloud or multi-cloud security, costs, deployment automation, and all things that help observability at scale.

Central Observability Teams

The newest evolution was predicted by Martin Mao back in December 2021:

"This team is responsible for defining observability standards and practices, delivering key data to engineering teams and managing the tooling and storage of observability data, among other things."

This team has become more the norm than the exception over this last year as organizations investing in cloud-native at scale ramp up their observability practices. Their main focus is to define standards and practices that can be used by everyone, thus centralizing observability in their organization.

The following are four functions that the central observability team should own:

  1. Define: Define monitoring standards and practices.
  2. Deliver: Provide monitoring data to eng teams; must be in a format they are familiar with (i.e., Prometheus).
  3. Measure: Ensure reliability and stability of monitoring solutions. 
  4. Manage: Manage tooling and storage of metrics data. Make it simple: if it takes a ninja, people won’t use it.

This has been a quick, down-and-dirty look at the teams on the field. Now let’s move on to the game.

The Observability Game

This takes us from the basic introduction, followed by a tour of the o11y playing field, and finally, you've met the players on the teams involved in cloud-native o11y.

Next up, I want to dive deeper into the pillars of monitoring and why at scale you might want to start thinking about the phases of cloud-native o11y instead.

Observability Cloud

Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Five Java Books Beginners and Professionals Should Read
  • Designing a New Framework for Ephemeral Resources
  • What to Pay Attention to as Automation Upends the Developer Experience
  • Reactive Programming

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: