Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CNCF montreal - OpenSLO by Simon Boyer @Arctiq

CNCF montreal - OpenSLO by Simon Boyer @Arctiq

cncf-canada-meetups

October 18, 2023
Tweet

More Decks by cncf-canada-meetups

Other Decks in Technology

Transcript

  1. 1 Simon Boyer Delivery Consultant Arctiq Observability as code with

    OpenSLO CNCF Montreal Community Group 2023-10-18
  2. 2 2 Who is Arctiq? Arctiq’s approach to App/Cloud modernization

    framework is focussed on 5 key pillars: People Process Technology Security Experience Arctiq is a leading DevOps, cloud, and automation solution integrator. We empower our clients to achieve high-velocity innovation with the latest emerging technologies that cater to their unique needs and challenges. Our value is to enable our client’s talent bench and ease the pressure of adopting new practices and tools by training and upskilling their resources; It is a critical component of our framework that assists in sustaining the change - technologically and culturally
  3. 3 Agenda 01 Challenges of Implementing SLOs at Scale 02

    A story about SLO as code 03 What is OpenSLO 04 Shifting left with OpenSLO 05 Collaboration with OpenSLO 06 Closing thoughts
  4. 4 Challenges of Implementing SLOs at Scale • With a

    lot of services, you get a lot of SLOs. How to define and track them? • How do you manage that? Centrally from the SRE team? From the dev team? • The difficult balance between standardisation and empowering developers • Usually outside of development pipeline, how to bring it as early as possible?
  5. 5 The project Our post-project findings • Requirements ◦ Enablement

    of observability practices for developers ◦ Abstract Monitoring-As-Code complexity from developers • Enabled developers to configure their APM objects from a simple yaml file ◦ Particularly SLIs/SLOs • Defining SLOs as code early also helps with automate testing and other tooling outside of the observability tool • But integration with each tool can be complex • SLIs are often the same across projects, but leaving it to developers completely creates discrepancies • A lot of moving pieces: endpoints, tooling, SLIs, SLOs, owners, notifications etc. A story about SLO as code Customer project: observability adoption
  6. 6 What is OpenSLO? • Open standard for SLIs, SLOs,

    alerting and more • Released in May 2022 • Objects can be composited in a single file, or they can be referenced with an id • Vendor-Agnostic • Uses the kubernetes manifest format: easy to extend and/or to interpret • Can define alerting policies with different notification targets • It is only a standard: implementation is up to tools and users
  7. 7

  8. 8 Shifting left with OpenSLO • We can enable developers

    to configure SLIs, SLOs and alerting with OpenSLO • But we’re again pushing complexity towards the developers • OpenSLO enables us to do even better with an adequate separation of concerns • Let SRE manage most SLIs, alert conditions, alert targets (slack, call, email…) • Developers only have to worry about their SLO, and sometimes define a few custom SLIs
  9. 9 Collaboration with OpenSLO • Promoting transparency: every SLOs lives

    with the code, easy to track changes • Teams can build tooling around a common standard for all observability needs • If a team creates an SLI query that could be useful to others, they can open a PR towards a central repository with all SLIs
  10. 10 Closing thoughts • Great solution to simplify and democratize

    SLO • Shifting left observability, but keeping it easy and standard, is key to adoption • Call to action: still a new standard, needs more adoption - consider using it!
  11. 12