SREday 2023

Real-time stream processing is growing exponentially in recent years, businesses need to gather insights from real-time data as soon as it’s generated. To do this, developers and software architects use various pipelines and tools to capture and process data in motion. Real-time stream processing has its own challenges such as testing and life-cycle management, scaling and performance, event time and late events, streaming fault tolerance, and processing guarantees. In this talk, I will address those challenges and demonstrate the best practices for real-time stream processing, from data ingestion to data processing with ultra-low latency at scale and at speed, using the Hazelcast platform. I will discuss how you can optimize your real-time streaming projects in the following areas: scalability, performance, failover, reliability, and data recovery.

Fawaz Ghali is the Principal Data Science Architect and the Head of Developer Relations at Hazelcast with 20+ years of experience in software development, machine learning and real-time intelligent applications. He holds a PhD in Computer Science and has worked in the private sector as well as Academia as a Researcher and Senior Lecturer. He has published over 46 scientific papers in the fields of machine learning and data science. His strengths and skills lie within the fields of low latency applications, IoT & Edge, distributed systems and cloud technologies.

When you arrive at a point in life you have work colleagues whose dads are in the same age bracket than you, it’s time to reflect on your career and think all the learning you have cumulated and all the advice you would have loved to hear on each stage of your professional career

When you arrive at a point in life you have work colleagues whose dads are in the same age bracket than you, it’s time to reflect on your career and think all the learning you have cumulated and all the advice you would have loved to hear on each stage of your professional career For each stage of my career, I will share with you the things I learned the hard way, so you don’t have to follow the same path full of dragons. I will cover my time as Junior Dev, Senior Dev, Team Lead, Project Manager and Agile & Transformation Consultant.

Antonio is an Agile enthusiast with more than 20 years experience in the IT industry and specialises in Agile methodologies. He comes from a technical background, starting his career as a Java Developer in Spain in 2000, moving to different roles within IT in three different countries. Antonio is passionate about creating and implementing the best solution while continually seeking to improve work methodologies. He is convinced that most of the problems in IT are due to lack of communication! Antonio usually speaks about Agile, DevOps, Project Management and Team management at conferences across Europe and US, such as DevOps Days, Agile Tour, JSConf, Codemotion and Voxxed Days.

As Steve Jobs reminded us, technology can be a bicycle for the mind. It can be a force multiplier, helping us achieve what we could otherwise not. However, it is too easy for technology to constrain rather than enable us. Transformations too often fall short, and new technology rarely creates the expected bottom-line benefits. What can Victorian London teach us about avoiding this trap?

Simon Copsey is a change consultant, and is on a mission to help organisations understand and unwind complex, cross-functional obstacles that get in the way of their staff, and reduce the ability to serve their customers. Simon’s career has taken him from being a developer in the trenches to helping various organisations take pragmatic steps from a place of chaos and paralysis, to one where it becomes a little easier to see the wood for the trees.

Distributed system design is hard. How to address the challenge of uncertainty, complexity, and dynamism in the cloud and mitigate 3 risks: value,cost and failure by applying evolutionary system design, continuous optimizations, iterative simulations and empirical learning through use of datascience

An Accenture survey conducted in 2020 found that just 37% of companies had fully achieved their expected full value and outcomes from Cloud. Engineering Cloud applications to specific business-aligned technical capabilities to achieve higher order value is hard. Cloud being distributed, asynchronous, event and message-driven, presents a high degree of uncertainty and variability during design and runtime. Engineering Cloud applications for success involves complex tradeoffs, careful optimizations, making choices against constraints, and resolving conflicts between competing technical specifications. The very characteristics of Cloud that give immense benefits are also likely to give rise to the risk of sub-optimal outcomes if not engineered for expected business outcomes. While commitment to cloud is promising, there is more to do to get to full value. Companies have picked the low hanging fruit. Now they’re moving more complex and business-critical workloads that yield higher order value, while simultaneously learning how to embrace cloud as the operating system of the enterprise. How to address the challenge of ensuring full business value from Cloud implementations? Cloud Fitness Engineering: Cloud Fitness Engineering (CFE) is a new way of architecting for the cloud. The goal of CFE is to ensure that the technical capabilities of the applications match the desired business outcomes. It addresses the challenges of uncertainty, complexity, and dynamism in the cloud environment by applying evolutionary system design, continuous optimizations, iterative simulations, and empirical learning. CFE mitigates the three risks inherent in any Cloud program. 1. Value Risk: risk of not unlocking full value from Cloud. 2. Failure Risk: risk of distributed system failures. 3. Cost Risk: disproportionate consumption of Cloud resources not commensurate with value.

Mahesh leads innovation in the area of application of artificial intelligence, data mining and machine learning in software engineering. He has led successful implementation of natural language processing driven test automation, usage and failure modeling using log analytics, empirical analysis of technical debt and application of knowledge graphs in discovering patterns and relationships for optimizing test suites and improve decision making for system integration projects. His passion is bridging the gap between theory and practice, between academia and industry and creative thinking in software. He is a regular keynote speaker in many conferences. He is currently working on addressing uncertainty in fault prognosis and diagnosis

How do you get developers to actually use your platform? Come hear what groups like Mercedes-Benz, JP Morgan Chase, and more have proven out: product managing the platform, attracting and retaining developers, seeding trust and skills, re-skilling existing ops staff.

This talk covers best and worst practices for Platform engineering. The trick is, we didn’t always use this phrase, so we actually have many years of experience to learn from. Who are you? You’re in a DevOps, wait, I mean SRE…nope, scatch that…“platform engineering” team. People are coming at you to get kubernetes up and running and then build some kind of platform on-top of kubernetes. But you just got a build pipeline in place! Getting kubernetes ready for developers may be a new problem, but building and running developer platforms has been going on for at least ten years. This talk will cover the lessons those organizations have learned such as: product managing the platform, attracting and retaining developers, seeding trust and skills, re-skilling existing ops staff, and more. Examples are drawn from organizations like Mercedes-Benz, the US Airforce, large insurance companies and banks, and more.

Michael Coté studies how large organizations get better at building software to run better and grow their business. His books Changing Mindsets, Monolithic Transformation, and The Business Bottleneck cover these topics. He’s been an industry analyst at RedMonk and 451 Research, done corporate strategy and M&A, and was a programmer. He also co-hosts several podcasts, including Software Defined Talk.

This talk will detail the anti-pattern where traditional operations are rebranded as “SRE” but everything else stays nearly the same. The same tools, processes, and interactions persist. SRE is seen as a mandate without any real change. In practice, the only change is the team’s renaming.

Across the industry, one of the most common, if not the most common, anti-pattern is the renaming X to Y. Considering it generically, it’s when we rebrand something but little else changes. It’s the act of rebranding a team or practice and, in practice, things stay almost the same. Like many other changes in the past that fell into this trap, SRE is not immune to it. As a new way of doing operations, it's easy to fall into this anti-pattern. Essentially, the rebranding anti-pattern is characterized by little to no change. It’s an anti-pattern where companies, at best, gain marginal improvements in the way they do operations and fail to capitalize on them. We’ll explore this in detail and what strategies we can employ to overcome to avoid this anti-pattern.

Principal Site Reliability Engineer at FanDuel/Blip.pt. MSc in Computer Science by the University of Porto. CK{AD, A, S} by Cloud Native Computing Foundation (CNCF) | Linux Foundation. {Terraform, Consul, Vault} Associate by HashiCorp. Working daily to build high-performance, reliable and scalable systems. DevOps Porto meetup co-organizer and DevOpsDays Portugal co-organizer. A strong believer in culture and teamwork. Open source passionate, martial arts amateur, and metal lover.

Learn why and how every SRE should know what service mesh and what can it do for them: control and management of application networking, automated zero trust security and near-perfect observability of cloud native applications

Platform Engineering is the new black and we posit that service mesh is the perfect complement and an indispensable sharp tool in every SRE’ tool belt. Albeit been around for a few years, service meshes are now blossoming into a de-facto standard for providing much needed features to cloud native platforms, such as zero trust security enforcement, observability, traffic shaping and control over the application networking layer(s). This demo-heavy presentation will walk you thru the rationale behind adopting a service mesh and what can it do in practice to alleviate the pain of running at-scale platforms to deliver cloud native self-service infrastructure to developers. We will focus on Istio (the most popular service mesh) but the learnings extends to any other service mesh implementation; we will provide a workshop-style repository to follow offline.

Community leader and CNCF ambassador, Alessandro has spent the last few years building cloud native infrastructures for Microsoft customers, animating the Dutch community, and training others to pass the CKx exams. He has passion for all things cloud native, he's been around open source for 25 years and recently moved to a new Developer Relations role at Solo.io, where he's on a mission to install a service mesh in every Kubernetes cluster he gets his hands on.

Dive into the chaotic world of GraphQL vulnerabilities with Escape's co-founders. Their exhaustive research unveiled a daunting 46,000+ security issues across more than 1500 GraphQL endpoints. Walk away armed with a resilience strategy to fortify your production GraphQL applications.

Join Tristan Kalos and Antoine Carossio, co-founders of Escape, the preeminent GraphQL Security Testing startup, as they delve into the tumultuous seas of GraphQL vulnerabilities. Derived from extensive research on production GraphQL endpoints, this illuminating talk unearths the complex dynamics of GraphQL's security landscape. Tristan and Antoine draw on their combined expertise—Tristan's mastery in development and machine learning and Antoine's valuable offensive security experience—to offer deep insights and proactive strategies. Dedicated to the relentless pursuit of resilient systems, the team logged over 500 hours of computation, performing chaos engineering on 1500+ GraphQL endpoints. The findings were startling, exposing over 46,000 security issues and sensitive data leaks publicly accessible without authentication, of which 10% were critical. This talk promises a deep dive into the most prevalent GraphQL vulnerabilities, along with their unique testing methodology adapted to the complexity of GraphQL. They'll dissect GraphQL-specific vulnerabilities like complexity issues and schema leaks, while spotlighting traditional API security issues, including injections, internal server errors, and stack trace disclosures. The conversation will also encompass the often underappreciated risk of data leaks—personal information, secrets, and tokens—illustrating the real-world impact of these vulnerabilities through case studies. But amidst the turbulence, there's a safe harbor. Tristan and Antoine will equip you with practical resilience strategies, showcasing tools such as GraphQL Armor, and a comprehensive security checklist. The session underscores GraphQL's remarkable capabilities while cautioning about associated security risks that are often overlooked in SRE/DevSecOps practices. The grand takeaway is a newfound comprehension of GraphQL's security landscape, paving a clear path to robust and reliable GraphQL applications. Immerse in the insights of this essential session and sail confidently into the future, leveraging GraphQL's power while ensuring the stability and security of your applications. Be part of this critical conversation at SRE Day 2023.

Antoine is cofounder & CTO of Escape.Antoine is a former French National Secret Agency and Apple security engineer and penetration tester. He is one of the maintainers of Clairvoyance: https://github.com/nikitastupin/clairvoyance

We will explore the shift from on-premise to the public cloud. The reasons behind it, advantages, and disadvantages. We will discuss what learnings and design choices we can bring back to private clouds. Uncover how to stricture modern private cloud, and discover which technologies can help you.

There has been a significant shift from on-premise data centers to the cloud in the last fifteen years. This process was due to the perceived cost difference between the legacy on-premise data centers and the newer and shinier cloud. Due to a renewed interest in privacy and data sovereignty, many organizations are returning to the on-premise. For the success of such initiatives, it is fundamental to learn from the past and understand how a modern on-premise data center would be structured. I started working in 2004 when almost everything was on-premise, and I had a front-row seat to the migrations that occurred in this period thanks to my roles as a Systems and Solutions Architect. In this talk, we will recap the last twenty years of migrations to learn some key lessons, and then we will analyze what a modern on-premise data center would look like, which technologies might help and which could be risky bets.

Fabio Alessandro Locati - commonly known as Fale - is an EMEA Associate Principal Solutions Architect at Red Hat, public speaker, author, and Open Source contributor. His primary areas of expertise are Linux, automation, security, and cloud technologies. Fale has more than 15 years of working experience in IT, with many of them spent consulting for many companies, including dozens of Fortune 500 companies. He is the author of the books Practical Ansible 2, Learning Anisble 2, Learning Ansible 2.7, and OpenStack Cloud Security. In the spare time he helps in the Kubernetes, Fedora Project, Ansible, Wikimedia, Open Street Map communities as well as in many smaller projects on GitHub and similar platforms.

In this talk, I share my experience & perspective as a SE going into SRE. This is divided into 2 parts - the pre-journey like I'd like to call it focuses on the key skills that you pick up as a SE that preps you for the role and then the actual Journey continues...how you start to get fit into SRE.

This talk is targeted towards software engineers today curious about the role SRE and wondering what to do to prepare for the role and if it is the right role for them, but also targeted at beginning SREs as well still in the journey of discovering what SRE means to them and their company, which areas they need to focus on and how to continuously improve. I have divided the talk into two natural parts which I have called the pre-journey; useful skills and experience, behaviours that you pick up as a software engineer that long prepares you before you start to even think of the SRE role itself and beyond. While the second part focuses on how I have been able to wear and settle into the SRE role, things I found surprising, how to define areas of value, and how to start thinking like an SRE.

Staff SRE Engineer @ Depop. Temitope has spent the last decade and a few working in and as part of all kinds of technology companies and consultancy. I am excited about working with development teams and leaders on how to optimise and embrace agile development alongside good engineering practices that allows us to solve business problems and add value. I am in the business of challenging ourselves to think and do right.

Helm is a package manager for Kubernetes which simplifies deployments to Kubernetes. In this session we'll go over exactly what Helm is, the benefits it brings, and how to deploy applications to Kubernetes.

Helm is a package manager for Kubernetes which simplifies deployments to Kubernetes. With Helm, applications are bundled into Charts which makes it easy to build, install, upgrade, and share complex Kubernetes applications. In this session we'll go over exactly what Helm is, the benefits it brings, and how to deploy applications to Kubernetes. Then we'll look at upgrading applications (with SQL Server as an example) using Helm and then rolling back to a previous version. Once that's covered, we'll look at creating our own Helm Charts and storing them in a Chart Repository. This session is for anyone who has worked with Kubernetes and want to learn about Helm. Each topic covered in this session will be accompanied with live demos.

Andrew Pruski is a SQL Server DBA, Microsoft Data Platform MVP, and Certified Kubernetes Administrator. Originally from Swansea, Wales but now exploring Dublin, Ireland. You can find him on twitter @dbafromthecold and blogging at dbafromthecold.com

This talk is about how we built Quivr- the open-source virtual brain. In just over 2 months we are at 14k stars and 6.5k active users. This is a story of the crazy highs, some broken production and how we created a community behind this project. I would love to be able to share the journey with you.

Hey, I'm Matt. AWS Community Builder, developer at Aleios, and organizer for the Serverless London meetup. Outside the day job, I am a core builder of Quivr: the open-source virtual brain. I enjoy building in public and driving for continuous learning to help people make cool stuff. In my former life, I was a professional windsurfer competing on the world tour. Nowadays I just get out on the water on the weekends and occasionally teach some kitesurfing.

Until now, dapps have never been able to incorporate machine learning models. It is hard for a dapp such as DTube to compete against centralized apps such as Youtube that can offer better content recommendations to their users. We'll explain how anyone can easily deploy a ML model to the blockchain.

Until now, dapps have never been able to incorporate machine learning models. Therefore, it is hard for a dapp such as DTube to compete against centralized apps such as Youtube that can offer better content recommendations to their users. Now, you can finally upload your machine learning model to the blockchain, to use in dapps, protocols, or cryptocurrencies. We will explain this technology in detail and how anyone can easily deploy a very simple machine learning model to the blockchain. Our talk addresses the challenge of integrating machine learning models into decentralized applications (dapps). This has historically been a barrier, limiting the competitiveness of dapps against their centralized counterparts. Our session will provide insights on how to deploy and leverage ML models on the blockchain, thus empowering dapps to deliver more personalized and advanced services. It aims to facilitate the convergence of AI and blockchain for enhanced application development. We hope attendees leave with a clear understanding of how to deploy machine learning models on blockchain, and the advantages this provides for dapp development. We aim to inspire them with the possibilities of blockchain and AI convergence. The goal is for attendees to see the potential in creating more personalized, secure, and efficient dapps, thus bridging the gap between decentralized and centralized applications. We also want to foster innovation and collaboration in the blockchain space.

Lucas Roitman is an entrepreneur and researcher in the fields of Artificial Intelligence, Robotics, and Augmented Reality. Roitman's success began when he created his first viral video game and when he sold his first augmented reality software to a multinational company. After graduating with honors from Stanford University, he created Lighthouse, an advanced technology camera for home security that was eventually sold to Apple. He developed his own smart drone company called Adia Robotics, and he is currently working on various confidential projects within Apple, as well as creating a startup to enable Artificial Intelligence to run on the blockchain.

In today's fast-paced development landscape, meeting SLAs is crucial for any SaaS organisation to maintain a competitive edge. Join us to learn how to build & manage SLOs to prevent customer SLAs from being breached. As a SRE, it's crucial to break down those barriers & communicate effectively.

The ability to handle Service Level Agreements (SLAs) is critical in today's fast-paced business world. For our organisation, the challenge lies in managing millions of conversations between employees and banks, each with their own unique ID. We have an internal process that takes these IDs through a sequence of steps, with each step having its own processing state, until the final state is achieved. Once this happens, the ID is marked as complete and made visible to customers through our user interface. Each of the step has a respective individual team working on the functionalities such as the Capture team, Indexing team, Archive Insights team, Ingestion team, etc. Our SLA with customers mandates that IDs must reach the final state within 3 days of being received. While 99% of the IDs move through the process smoothly, about 1% of them encounter various issues such as indexing, fatal errors, or XML parsing errors, which prevent them from reaching the final state. Our SRE team has developed an internal app based on Python FastAPI, Celery & mongo db that automates the verification of ID states and ensures that they are moved to the final state within the SLA timeframe. This app is bundled with the following scripts which are executed in the celery worker threads as cronjobs: Script that runs daily, verifies the states of the IDs received for t-3 days. It then moves the IDs which are not in the final state into a static collection into Mongo DB. Another script periodically verifies and updates the latest states of these IDs, and removes them if they have reached the final state. This script also takes care of updating the latest states of the id’s which were moved into the collection the previous days. An auto-remediation script that kicks in at regular intervals, which retries the failed IDs by invoking the respective team's internal API. Finally, another script that runs daily which creates an incident with the remaining failed ids using the Atlassian Jira API. As soon as the incidents are created alerts are sent to the respective teams informing the status of the failed IDs. The teams are notified about the incident via slack teams, emails enabling them to act promptly and address the issues before the SLAs are broken. Furthermore, all of these scripts have been designed to ensure there is no manual toil involved, which automatically triggers the respective application functionality through internal APIs and creates JIRA incidents to inform the teams about the actual failures left over after the retry functionality. This efficient process ensures that the teams can act upon the failed IDs promptly, way before the SLOs are broken, thereby delivering a seamless experience to our customers. Additionally, visibility to the customer as we navigate through reconciling every ID is crucial for transparency, customer confidence, and progress tracking. By leveraging the technology, the SRE team has developed an efficient and reliable system for managing the processing of millions of IDs, thereby ensuring that customer SLAs are met consistently. The system's ability to automatically detect and alert teams of any failed IDs has helped the teams to proactively address issues and prevent potential SLA breaches, ultimately leading to improved customer satisfaction and retention. This method not only allows us to meet our customer expectations, but also enables us to continuously improve our processes to ensure that we consistently deliver quality service. Join us at "Slaying the SLAs: Mastering Effective Communication for Seamless Customer Experience" to learn more about how to handle SLAs and achieve operational excellence in your organisation.

As an experienced Lead SRE Engineer with 15+ years of industry experience, I've utilised my skills and expertise in designing, building, and maintaining robust CI/CD pipelines, implementing DevOps principles, and leading SRE teams. With a strong background in containerisation technologies like Docker and Kubernetes, as well as expertise in CI/CD tools like Azure DevOps and Jenkins, I am well-equipped to lead and mentor teams on SRE best practices. At my current role at Smarsh, I designed and developed a new framework for SRE apps using Python's FastAPI, Celery, and Jinja2 modules, Redis, JavaScript, HTML, bundling all SRE scripts into a single web app. This resulted in reduction of manual toil and kept the SLA's in tact, and I was awarded with 'Lead by Example Award' for spearheading in designing & building this app. It's the same app that was discussed in the CFP. In my previous role at Siemens, I played a major role in designing and building CI/CD pipelines, collaborating with architects and stakeholders, and majorly contributed in bringing the infrastructure cost down. One such instance is that I've optimised cloud infrastructure costs by $5000 per month, brought down third-party vendor licenses for cross browser & cross platform testing by automating the setup required using Selenium Grid & PowerShell scripts. Another achievement that I am proud of is that I've developed a fully auto scale Test Infrastructure using Jenkins & PowerShell scripts which seamlessly simulates the hospital environment, installs software’s using DSC, executes test automation suite of 2000 tests, captures test results into Jenkins and leaves no footprints. Presented a paper on this topic in Software Testing Conference, 2016 and it was one among top 250 white papers. My objective is to continue coaching, mentoring, and empowering team members and people across teams on SRE best practices while delivering high-quality results that exceed expectations.

In this session, we compiled 10 horror Dockerfiles don'ts, a.k.a “Dockerfails”. To end on an optimistic note, we will showcase the maximum good practices in some popular CI/CD tools (github/gitlab/jenkins) with a touch of GitOps.

This talk will cover, From our experiences, the worst 9 “fails” that developers from all languages could benefit from and put those “Dockerfails” in 3 main areas: 1 — “Code” Area Dockerfail #1 — throw everything in it and mix. (good practice: use linter, syntaxt checker) Dockerfail #2 — rebuild it and then test the app by hand (good practice: write container unit tests) Dockerfail #3 — the production-like misunderstanding (good practice: leverage multi stage including debug tooling) 2 — “Build” Area Dockerfail #4 — ignore cache and download internet at your own risk (aggressively optimize for caching) Dockerfail #5 — blindly include secrets and vulnerabilities (good practice: scan and sign) Dockerfail #6 — tags are mutable, changes get lost (good practice: push diffs in git) 3 — “Run” Area Dockerfail #7 — health checks can kill your production (good practice: take time to design a real world healthcheck) Dockerfail #8 — multiple processes in same contanier/pod do not scale (good practice: split services) Dockerfail #9 — security as a second thought (good practice: collect and track SBOM on each deploy) A bonus 10th tip will highlight that there are other options on building container images (Buildpack, JIB, ...) Demo : a sample pipeline fixing all previous “fails” using a gitops approach

Mohammed is a community catalyst, a true open source believer, Google developer expert and has contributed to various open-source projects. He currently works at Spotify as a Backend engineer

Have you ever wondered what it takes to build a highly resilient distributed caching platform for critical real-time payment systems? Join us as we share our journey of building a highly available and fault-tolerant caching solution while leveraging automation to achieve a faster MTTR.

Payment systems that support real-time transaction processing are expected to be available and highly responsive 24/7/365. These systems must be fault-tolerant and highly resilient to any failures that might happen during payment transaction processing. Building a low-latency payment system that spans multiple geographic locations requires a distributed caching solution for low latency and high-throughput data access. While building a real-time transaction processing system at Discover - one that is continuously available and can process thousands of transactions per second with a sub-second response time - we decided to introduce distributed caching technology into our architecture to minimize the latency and to replicate the data across multiple data centers. This presented numerous challenges: • How to run Active-Active cache clusters in multiple deployment regions with high-availability • How to auto-heal cache cluster failures due to network partitioning or disaster • How to automatically failover client applications in response to failures • How to automatically recover failed clusters to reduce MTTR • How to ensure data consistency after the cluster is recovered • How to implement a real-time monitoring and alerting solution for client and cluster connectivity In this talk, we will take you through our journey of how we built a distributed caching solution to solve the challenges we faced. • Configuration-driven and thread-safe smart client solution that can intelligently detect failures • Ability for the client application to failover if the error rate is above a certain threshold • Automation to recover failed cluster and failback client connections after the cluster is recovered • Workflow automation for data consistency after the cluster is recovered • Real-time streaming of client connectivity metrics • Observability solution to simplify operational support

I am a technology professional working in the financial services and payments domain. I’m a hands-on technologist, enabling business capabilities by implementing cutting-edge, modernized technology solutions. I am skilled in designing, developing, and implementing innovative financial technology solutions that drive business results and establish best-in-class operations. I did my Masters in Information Technology from Northwestern University which is a unique program that straddles the business and technical side of information technology focusing on data mining, information security, enterprise architecture, statistics, innovation, marketing, and finance to name a few.

Struggling with limited observability data for HPA? Tired of provisioning resources that lead to unnecessary costs? The Keptn's Metric Server solves this by exposing new metrics in K8s. Join me to see how to scale workloads with efficient HPA rules.

Have you ever faced the challenge of limited accessibility to observability data for Horizontal Pod Autoscaler (HPA) or are you tired of provisioning resources that lead to unnecessary costs? As you likely know, HPA leverages metrics exposed by the Kubernetes Metrics API for scaling decisions. Consequently, many organizations typically construct their autoscaling rules based on fundamental metrics like CPU and memory usage. In Kubernetes, creating an autoscaling rule that guarantees both the reliability of applications and the cost efficiency only based on CPU usage can be challenging. As organizations expand their Kubernetes footprint, they often utilize more than one observability tool or switch tools altogether. How can we effectively utilize our observability data in autoscaling rules? The Keptn project offers the Metric Server, which addresses this challenge by seamlessly consolidating all observability data within Kubernetes. Join us for an informative presentation where we will demonstrate how the Keptn Metrics Server effortlessly scrapes metrics, facilitating the autoscaling of Kubernetes workloads in conjunction with the HorizontalPodAutoscaler. Through a real example showcasing inefficient HPA rules, we will explain how the Keptn Metric Server can enhance and optimize the autoscaling process utilizing metrics from Istio/Envoy, but also the cost of your workload. Discover the value of the Keptn Metrics Operator, which serves as a unified entry point for metrics data, regardless of its source. This operator streamlines the autoscaling process for your workloads. Come and learn the best practices to define the right Autoscaling policies

Henrik is a Cloud Native Advocate at Dynatrace. Prior to Dynatrace, Henrik has worked more than 15 years as Performance engineer .. Henrik Rexed Is Also one of the Organizer of the KCD Austria, the Conference named WOPR and the owner of the Youtube Channel IsitObservable.

It’s hard to imagine ever going back on the process & quality improvements brought by CI/CD. But it only got us so far. It's time we enter the next phase of the DevOps evolution, to continue streamlining our engineering operations, we need to rethink our processes & eliminate the amounting friction.

When DevOps first started to manifest over a decade ago, a lot of the focus was on streamlining engineering, much in the same way as assembly lines. Starting with the most repetitive and automatable processes, we created pipelines for continuous operations––testing, integration and deployment (AKA CI/CD). Concepts were borrowed from Kaizen (Japanese assembly lines) to ensure these processes flowed and worked, and it’s hard to imagine ever going back on the process and quality improvements brought on by CI/CD. But it only got us so far. After solving for automation of programs - tests, integrations, builds and deploys are all basically scripts - our attention can turn to much heavier sources of friction, which are also harder to automate. These are the touch points between humans: pickup time for code reviews, who do I even assign this review to?!, what do I need to line up to get this PR merged? And between humans and programs: flaky builds and tests, builds + tests that take too long, post-deployment ownership during outages, synchronizing access to dev environments, and much more. Enter the next phase of the DevOps evolution. To continue streamlining our engineering operations, we need to rethink our processes and eliminate the amounting friction. In this talk we’ll bring data and research from millions of PRs and developers, and share how simple tweaks have unlocked velocity that is faster by orders of magnitude. Everything from automating trivial code fixes, better understanding of ownership and stakeholders in the process, improved communication (the backbone of DevOps!) all map to greater velocity and developer happiness–and you can too! Join us to learn how.

Yishai Beeri likes to solve problems, and that’s why he was so fascinated with programming when first encountered Logo back in the 80s, where the possibilities seemed endless. He has made it a focus of his career to solve complex programming problems, both as a consultant and entrepreneur. In 2014 he joined the CTO office of a fast-moving cloud security startup, which later was acquired by a networking giant. At this startup he also met Ori Keren and Dan Lines, now co-founders of LinearB. He joined them shortly after the company was established, in order to get back to what he loves most about engineering, solving big challenges, and this time he is focusing on the world of dev team metrics and software delivery management. He is also the host of the very successful Hebrew Podcast - Dev Interrupted.

As a developer who loves SRE, I want to collaborate with SREs and support engineers to build amazing software. With traditional support teams' adoption of SRE, we automate similar workflows with different tools. Let's use Synthetic Monitoring as E2E tests to validate the user experience together!

Despite the emergency of DevOps to unite development, support and SRE factions together using common processes, we still face cultural and tooling challenges that create the Dev and Ops silos. Specifically, we often use different tools to achieve similar testing: case in point validating the user experience in production using Synthetic Monitoring and in development using e2e testing. By joining forces around common tooling, we can use the same tool for both production monitoring and testing within CI. In this talk, I will discuss how Synthetic Monitoring and e2e Testing are two sides of the same coin. Furthermore, I shall show how production monitoring and development testing can be achieved using Playwright, GitHub Actions and Elastic Synthetics.

Carly is a Developer Advocate at Elastic, based in London, UK. Before joining Elastic in 2022, she spent over 10 years working as a technologist at a large investment bank, specialising in Frontend Web development and agility. She is an agile evangelist, UI enthusiast, and regular blogger. In her spare time, she enjoys cooking, photography, drinking tea and chasing after her young son.

Unlock the power of game theory principles in chaos engineering! Our AI model, Chaos Synergy, predicts system behavior under different failure conditions, providing insights for better system hardening. Join me at SREday 2023 and learn how to enhance your system's resiliency with this novel approach

Chaos Synergy is an AI model that utilizes game theory principles in chaos engineering to predict the interactions between system components under various failure conditions. By adopting a game theory approach to chaos engineering, Chaos Synergy enhances system resiliency and improves the reliability of complex systems. In this presentation, attendees will learn how Chaos Synergy uses machine learning techniques to identify potential system failures and minimize their impact on critical infrastructure. By analyzing and modeling the behavior of system components and their interactions, Chaos Synergy provides insights into the system's resilience and enables proactive measures to be taken to prevent future failures. Attendees will also gain an understanding of how game theory principles can be applied to chaos engineering to develop more efficient and effective resilient strategies. With practical examples and real-world use cases, this talk will demonstrate the power of game theory in enhancing system resilience and mitigating risks. Chaos Synergy is an innovative solution to the challenges faced by system architects and engineers. With its cutting-edge technology and game theory-based approach, it offers a new paradigm for achieving enhanced system resiliency in the face of an increasingly complex technological landscape. Attendees of this presentation will leave with a deeper understanding of how to apply game theory principles to chaos engineering, and how to build more robust and reliable systems.

I'm Madhu Kumar Reddy an Architect at Delta airlines and a former employee of Intel. With Over 18 years of experience in IT. I've gained a wide range of expertise in areas such as cloud computing (AWS, Azure, GCP) , AI, Machine Learning and block chain. Currently, I'm pursuing a PhD in cloud computing and a doctorate degree from SSBM University, building upon my previous education with an engineering degree and a master's in computer science. My passion for technology and innovation has driven me to constantly learn and improve my skills, and I'm excited to continue doing so in my current pursuits. As an architect at Delta Airlines, I work to create solutions that optimize our systems and provide the best possible experience for our customers. I want people to know about me because I believe in the power of collaboration and sharing knowledge to drive progress in the tech industry. Through my work, I hope to inspire others to pursue their passions and push the boundaries of what's possible. Now, to answer the important question - my favorite member of One Direction is Niall Horan. Thanks for taking the time to learn a bit about me!

Infrastructure as Code is a best practice, but we are writing configuration files, not real code. Is there another way? Yes! In this session, we’ll dive into the open-source Cloud Development Kit that lets us define cloud infrastructure in languages like Python and TypeScript.

Infrastructure as Code (IaC) is a best practice, but with most infrastructure automation frameworks out there, we are writing configuration files, not real code. Is there another way? Yes! In this session, we’ll dive into the open-source Cloud Development Kit (CDK) that lets us define cloud infrastructure and Kubernetes apps in familiar programming languages like Python, Java, C#, TypeScript, and JavaScript. After this session, you know how CDK works, what infrastructure you can automate with it, and how you could use it in your next project.

Martin Sakowski is a Solutions Architect at Amazon Web Services. He supports German enterprise customers on their journey to the cloud. He has a strong background in building digital platforms and serverless stacks. With this experience he loves to dive deep into architectures and development processes to drive performance, operational efficiency, and increase the speed of innovation.

Quick, what's the difference between mean, mode and median? Review how statistical behavior impacts alerting. Learn why a median is best for historical anomaly. Jump into distributions, data alignment challenges and the trouble with sampling. Walk out with a deeper understanding of your metrics.

Quick, what's the difference between the mean, the mode and the median? Which mean do you mean? Do you need a Gaussian or a normal distribution? How do you measure trends? Does "p" mean percentage? (Hint: No.) And does your choice impact the alerts and observations you get from your observability tools? Come get refreshed on the impact some basic choices in statistical behavior can have on what gets triggered. Learn why a median might be the choice for historical anomaly or sudden change. Jump into Gaussian distributions, data alignment challenges and the trouble with sampling. Walk out with a deeper understanding of your metrics and what they might tell you.

Currently providing technical evangelism for NGINX, Dave works with DevOps, developers and architects to understand the advantages of modern microservice architectures and orchestration to solve large-scale distributed systems challenges, especially with open source and its innovation. Dave has been a champion for open systems and open source from the early days of Linux, through open distributed file systems like XFS, GFS, and GlusterFS to today's world of clouds and containers. He often speaks on topics such as the real-world issues associated with emerging software architectures and practices, on open source software and on creating new technology companies. Dave has spoken on technical topics like distributed request tracing, modern monitoring practices, open sources projects from both corporations and foundation views, and on how open source innovations powers todays world. Dave was named as one of the top ten pioneers in open source by Computer Business Review, having cut his teeth on Linux and compilers before the phrase "open source" was coined. Well versed in trivia, he won a Golden Penguin in 2002. When he's not talking, you can find him hiking with his trusty camera, trying to keep up with his wife.

Have you ever thought about using Feature flags to reduce the risk every time you release? Why not get started with OpenFeatuere, an opensource option to dive into progressive delivery

Feature flags and open source software are both powerful tools for managing and controlling software features and functionality. With feature flags, developers can deploy new code changes without immediately exposing them to all users, enabling faster and more controlled release cycles. OpenFeature, an open source project for feature development and testing, enables teams to collaborate on feature development and testing in real-time. In this talk, we will explore the benefits of using feature flags and OpenFeature in software development, as well as strategies for successful implementation and use. We'll discuss how to set up feature flags and OpenFeature in your codebase, how to manage them over time, and how to use them to support continuous delivery and experimentation. We'll also cover best practices for using feature flags and OpenFeature, including how to collaborate effectively with cross-functional teams, how to measure the impact of different feature flag strategies on user engagement and adoption, and how to integrate OpenFeature with your existing feature flagging practices. By the end of this talk, you'll have a solid understanding of the benefits of feature flags with OpenFeature, as well as practical strategies for using them effectively in your software development process. Whether you're a developer, manager, or technical leader, you'll walk away with actionable insights and best practices to help you streamline your release cycle, improve your overall software quality, and foster more collaborative and innovative development practices within your team.

David works as a Program manager at Dynatrace's Open Source Program Office. He is driving process, compliance, and security efforts around Open source within the company, as well as contribution and the creation of new projects. He also supports projects in their early stages, helping drive adoption and community development for Keptn, OpenFeature, and OpenTelemetry, working closely with the engineering teams. David is a member of the InnerSource Commons and TODO Group, furthermore, he fosters collaboration with foundations and participation in the community and conferences.

From Systems Engineering to Platforms Team, a journey through DevOps and SRE adoptions, progressing from losing one team member per year to “The happiest team in Netquest". A tale of building trust and reliability while adopting anti-fragility; with best practices, anti-patterns and teaming tips.

Last 10 years, systems’ engineering team at Netquest changed various names and passed through different transformations: born Agile, it embraced DevOps, Site Reliability Engineering and matured into Platforms Engineering. During the journey we got close to the five-nines goal where needed, and we also progressed from losing one team member per year to “The happiest team in Netquest Tech and Data” and we’d like to share our journey and “recipe”.

Ruggero is a systems engineer focused on performance, automation and security with a broader experience in architecting and running large-scale, resilient, distributed systems. Currently he’s leading the Platforms|SRE team @Netquest. Continuous improvement advocate, Agile practitioner and Chaos Engineering aficionado, in his free time Ruggero enjoys riding mountain bikes and good food.

Moving from external alerting tools to in-house built solutions can be an exciting challenge. Learn how Observability at Elastic has put in place Synthetic monitoring to fire up Kibana alerting solution for a better SRE experience.

Diana is an SRE and Devops Engineer at Elastic with over 10 years of IT experience. She enjoys cloud computing, k8s projects and developing her programming skills. Off work, Diana is a bnw photographer, sports enthusiast and mother of two young children.

Meet Data Radar Maps : actionable data tools that help product and engineering teams grow with data science. It allows you to measure and track the maturity and progress of the data framework in your organization. All this and a bit of knowledge sharing!

Data Scientist with over 10 years of experience in design, development and implementation of data-driven solutions for cross-functional teams in organizations. Over the span of this decade, I have had the pleasure of working with high performance innovation-driven teams, from startups in Silicon Valley, Berlin, Cluj to global organizations such as Mercedes, Fedex and many more. Specializes in advanced statistical modeling, supervised and unsupervised machine learning, deep learning algorithms and generative AI models. SUPERPOWER is Communication. Illustrates complex technical concepts to non-technical stakeholders effectively, with a bit of joy. The Joy of Data is my attempt to continue learning in this community and share the knowledge with organizations that wish to leverage the power of data, with a bit of joy.

During this talk I will show how continuous profiling can help aid the investigators during an active incident, to reduce the time to recovery. Continuous profiling data can also give you some more clues to finding the root cause in the aftermath. I will share our experiences with real word outages/performance degradations of our observability cloud platform, and how continuous profiling helped to restore the service quicker. And how we use the profiling data during the Post Incident Review to spot the root cause and/or find more improvements to our systems.

Christian can rely on a broad set of experiences around the Linux ecosystem. Starting as early as Kernel version 2.2, he managed to convert his hobby into a career: working as a Kubernetes engineer (some might remember the kube-lego project) showed me the value a modern observability stack can provide. I am now working as a Software Engineer on Grafana Lab's Pyroscope team.

Tired of "just use JWT!" tutorials? Learn how you could move your existing legacy authn/authz to a centralised service working together with your ingress gateway. Convert basic, bearer or other authentication mechanisms into a common format, even handling multiple auth types for all your endpoints.

Most platforms built over time will have a variety of API endpoints, either in a large monolithic codebase or spread across a few services. Ideally these will have a centralised way to handle authentication and authorization, but often they are built at different times for different needs, and can end up with their own separate auth. This then becomes tricky to manage cohesively when either breaking up a monolith, or handling identities consistently across a service-oriented architecture. Whilst there are many approaches (all valid) to centralising auth, this talk looks at how existing legacy auth code can be abstracted out to a new service that can work in combination with an ingress gateway to provide a central place to enforce authentication and determine authorization. Content will include showing how allow/deny logic works, how auth information can be sent to downstream services, and how multiple auth mechanisms can be handled by a single auth service.

Developer and DevOps enthusiast from the middle of England. Built infrastructure for web applications from pre-VMs through VMWare/Xen/Hyper-V through to AWS and GCP, albeit often haphazardly amidst a variety of automation. Bedroom DJ, slow cyclist and mechanical keyboard junkie.

The edge is the new cloud! Kairos is an open-source project that acts as a factory to produce immutable operating systems with any Linux distribution from container images and build Kubernetes clusters in small-footprint environments at the edge. All of this in a flash with a few manual actions!

Nicolas is an experienced hands-on technologist, evangelist and product owner who has been working in the fields of Cloud-Native technologies, Open Source Software, Virtualization and Datacenter networking for the past 18 years. Passionate about enabling users and building cool tech solving real-life problems, you'll often see him speaking at global tech conferences and online events, spreading the word and walking the walk with customers and users.

In a galaxy not so far away, where data is as vast as the cosmos, our team was troubled with observability data chaos. Seeking some clarity, we sought salvation with Thanos and Fluentbit – fabled titans against our metric storage and logging issues. Thanos empowered us with a Prometheus setup with high availability and virtually infinite historical data storage. Prometheus ascended to new heights, flawlessly scaling horizontally and the Thanos Compactor's downsampling abilities promised faster results for querying older data. Fluentbit made collecting, filtering, and outputting logs across multiple sources and destinations effortless. But, little did we know that even the most powerful tools, when not wielded correctly could be double-edged Infinity Stones. Join us on a thrilling tale of blunders as we recount some missteps in configuring these tools, easily missed caveats in data downsampling and log storage, and how the pursuit of seamless data handling almost cost us over $100,000.

Incident resolution is stressful, but competing demands, cultural misfires and lack of automation are tipping SRE stress over to SRE burnout, impacting the health of SREs, and SRE success. But, it can be addressed. Come to this talk for actionable insights into preventing burnout and reducing toil!

Ludo is VP of Operations at Cloudsoft. Starting out as a software engineer at General Electric, Ludo moved into technical project management roles at GE and Natwest before joining Cloudsoft in 2019. As VP of Operations, Ludo sits at the crossroads of software delivery and company culture and so he has a deep understanding of the technical issues facing SREs, as well as the cultural changes teams can make to address these challenges before burnout rears its head.

Data products break the software rules. Schemas shift, data acts up, systems revolt. Yet demand skyrockets. We built solutions. You'll master our playbook—data contracts, testing, monitoring—forcing order upon data chaos. Tame the wild west; lead the data age.

While applying software engineering principles to build reliable software products is well established, data products pose unique challenges. Schemas and formats constantly evolve. Unexpected data issues arise. Multiple complex systems, including legacy platforms, must be integrated. This talk shares hard-won lessons from building an enterprise data product that serves a major publishing company with massive data needs. You’ll learn how to tailor software practices specifically for data, employing: * Data contracts: Align teams, systems and uses. * Validation: Ensure correctness of your schemas and data, test automation in CI and at runtime. * Monitoring: Data freshness, completeness, and anomaly detection to address data product challenges. Discover how to craft highly resilient, scalable data solutions. Tame fluctuating data and unreliable systems. Tackle the data wild west. You’ll leave armed with a blueprint for leadership in the data age.

Carmen: Data professional with broad experience in the Data space spanning technical, analytical and strategy having held roles from pure BI and Analytics through to Senior Data Engineering and Head of Data. I have deep expertise (and most fun) in data engineering and data modelling. Akshay: Software Engineer. Quick Learner. Team Leader. Specializing in data, cloud infrastructure and security. 11+ years in Agile and distributed teams, implementing and coaching teams on Continuous Delivery, DevOps and Data Engineering while developing large scale enterprise webapps.

Revitalize your DevEx! Unleash innovation & efficiency in engineering teams by mastering Infrastructure as Code, CI/CD, & more. Streamline onboarding, create dynamic developer hubs, & cultivate a thriving team culture. Witness a real-life transformation and revolutionize software development today

In this talk, we will explore the importance of Developer Experience (DevEx) in driving innovation, efficiency, and retention within engineering teams, with a particular focus on building on top of the public cloud platforms. We'll delve into how Infrastructure as Code, tooling, CI/CD, and standardization are transforming the software development lifecycle and enabling teams to ship code faster with minimal friction. Discover how a streamlined onboarding process can expedite new developer integration and how tailor-made developer portals can become central hubs for tools, resources, and documentation. Additionally, we will showcase a real-world use case from a UK-based client that demonstrates the transformative impact of these strategies on their development process. Finally, learn how cultivating a healthy and supportive development team culture can foster experimentation and innovation while maximizing business value. Join us in redefining the Developer Experience and revolutionizing the way we create and evolve software in the modern era.

Pavlos Kleanthous is the founder of Parsectix, a U.K.-based software consultancy specializing in cloud-native, serverless and event-driven architectures. With over 15 years of experience and a strong focus on distributed and cloud-based systems, Pavlos has earned a reputation as a respected Technical Leader and problem-solver in the industry. Currently he oversees a team of highly talented, intelligent and thought-provoking technical engineers from a range of disciplines and backgrounds. Additionally, he plays a vital role in steering the growth of Parsectix, working collaboratively with the team. Pavlos' unwavering commitment to client success has contributed to the successful completion of numerous transformative projects and the establishment of long-standing partnerships in both the United Kingdom and Germany.

When building a workflow automation product, I noted different types of teams and organizations faced different issues with the automation they envisioned. Hence In this talk, I aim to outline best practices that can be distilled from all the ways seen that different teams were building automation.

SRE and Security teams face challenges in managing complex systems. Automation is an effective mechanism for response to disruptions and threats. However, when building a workflow automation product, I observed enterprise organizations set up unnecessary roadblocks, and smaller teams cutting corners to get immediate results. Hence in this session, I want to share my experience and interactions with customers across industries and growth stages and outline the best practices of automation that can be distilled from all these interactions. The best practices covered will include real-life examples of what some organizations are trying to do and how following the best practice helped their automation goal. Best practices covered: *Understand your processes (Inspired by an American E-medical startup) * Does it require human decisions * Does the process touch critical parts of the application * What context is needed to confidently automate. * Enable smart automation and not more automation. (Inspired by the processes set up by a multi-national Brewery) * Break down processes into reusable automation modules * Distribute automation templates across teams * Leverage context from applications as much as possible * Automate directly from where you want to kick off automation (Inspired by an English kitchen hardware retailer) * Integrate automation with your monitoring and alerting * Perform decisions where the team works * Leverage automation to gather more context than the average responder is aware of at the time of kicking off the automation. * Secure your automation (Inspired by an American airline company) * Perform strict access controls * Audit the actions taken by your workflow * Review permission escalations and leaks of sensitive information. * Manage your automation as you would any other service (Inspired by a large Canadian consultancy group): * Track the performance of all your automated workflows * Make changes in an automated workflow configuration go through a review process * Perform tests of each segment of the automation. * 5 example workflows illustrating the 5 best practices listed.

An engineer turned product manager and AWS Community Builder, exploring the next-gen DevOps Cloud Computing solutions to help facilitate advancements in how we build software. Sarjeel is passionate about all things Serverless and DevOps and often writes and speaks about how we can solve some of the crucial problems around increasing velocity and maintaining resiliency in cloud-based systems. Can be often found in cafes talking about the comedies of life while torturing his non-tech friends by relentlessly talking about the Cloud.

Over my last few jobs, I have been brought on as a senior SRE. Instead of wrangling CI/CD or messaging queues, I found my time was better spent introducing, or reintroducing the concepts of observability, incident & change management and other core SRE topics. SRE is a positive lever for culture.

In this presentation, I will describe life as a Staff SRE, and how it turned out to be different than what I was expecting. I will describe how I got started, how I made my initial impact and the scope of it. I will then describe how I make my current impact. Over time, I have learned that my most impactful moments weren't putting out fires or scaling one more service. My impact has been most positively felt by restructuring aging processes, educating engineers and driving consistency in attitude and sometimes tooling. All of this was driven by my SRE mindset, and my ability to win over the most ardent and stubborn engineers via data and in-house champions. I will describe real situations and how I overcame them. I will also describe where I fell short, and the best ways to avoid some of these pitfalls. In this talk, I will demonstrate to other SREs and engineers how they can make similar impacts, not by becoming a 10x engineer, but rather by channeling efforts that enable others to become 10x engineers.

Brian Murphy is a Staff SRE working for Dell Technologies, Inc. He has spent the last 7 years on his SRE journey, doing every job from solo SRE to building and managing SRE teams to architecting and delivering cross company SRE focused projects. Brian is passionate about SRE culture and sharing his knowledge with others. He focuses his attitude and energy into positive cultural change. He will happily discuss all of this with you over an oat milk flatwhite.

Clear comms are critical when moments matter. Translating engineering terms to customer-friendly comms is harder than you think. Come to this talk to learn how to work with your customer-facing teams to translate your systems to customer symptoms, allowing you to get back to focusing on a fix.

When launching new products or dealing with an outage, customer-facing teams see terms thrown around internally that customers might not identify with immediately. Good communication practices, including good translation of engineering terminology to customer-friendly communication, can save time and increase customer satisfaction when moments matter. Customer Support's unique ability to understand both what is happening internally as well as what customers need to hear positions your team as the experts to steer communications during major incidents. Come to this talk to learn how to partner with your customer-facing teams during major incidents.

Kat is a developer advocate at PagerDuty. She enjoys talking and thinking about incident response, customer support, and automating the creation of a delightful end-user and employee experience. She previously ran Global Customer Support at PagerDuty, and as a result, it’s hard to get her to stop talking about the potential career paths for tech support professionals. In her spare time, Kat is a mediocre plant parent and a slightly less mediocre pet parent to two rabbits, Lupin and Ginny.

Top7 decisions a DevOps Architect will need to face when running kubernetes in high scale.

So you decided to take the red pill and run your containerised applications on Kubernetes. Day 0 looks fantastic. You deploy, scale, and monitor. Then Day 1 and Day 2 arrive. Day 3 is around the corner. You suddenly notice that Kubernetes is a Microcosmos. You are challenged to take architectural decisions. How many clusters should I create, how big? Which tenancy model should I use, SILO? multi? How do I connect services across clusters? Join me in this session where I will present a few of those key decisions that I discuss daily with my strategic customers.

Kobi has been working for 9 Years at AWS, spending most of the time as a solution architect working with myriad of customers, consulting and leading technology partners. Now-days he is practicing his passion for container technologies and works as a container specialist solution architect helping customers and partners to modernize, migrate and design large scale containerised environments. I focus on container networking, multi-cluster & service discovery. In my line of work I mainly interact with strategic customers. Been in the cloud since 2013.

Observability relies on metrics as a crucial aspect, providing a cost-effective and speedy way to address SDLC and Software health queries. From combating Noisy Neighbors to battling in the Streaming Wars and dealing with the pulse of High Cardinality, what are the best workflows to deal with it?

Observability relies on metrics as a crucial aspect, providing a cost-effective and speedy way to address queries regarding SDLC and Software health, which can otherwise be challenging. With metrics, inevitably, you hit High cardinality problems. While searching for profound insights from their systems, we often face restrictions due to the cardinality limitations of the observability tools. But what makes high cardinality significant, and why is it an inevitable challenge when monitoring systems on a vast scale? We will delve into the anatomy of a metric and issues that high cardinality can help resolve, from combating Noisy Neighbors to battling in the Streaming Wars and dealing with the pulse of High Cardinality. However, modern systems' limitations make cardinality an unsolved problem. To find the best solution for cardinality, it is crucial to understand the Metric Lifecycle. Lastly, we will define workflows that enable scaling cardinality to millions, not just thousands. When software is in production, it's crucial to have telemetry and instrumentation to troubleshoot issues. Unfortunately, this can be a time-consuming and costly process. Often, we resort to using generic solutions that may not address all the unique needs of our specific system. This can lead to missed opportunities for improvement and wasted time looking for answers elsewhere. I've spent a decade working in this field and can help the audience explore new questions and simplify their workflows. Most importantly, it will allow architects and engineering leaders to keep things SIMPLE and reach that 9 with much less pain.

Piyush Verma is co-founder and CTO at Last9.io, an SRE platform that aims to minimize the toil that SREs and decision-makers need to go through to reduce the time to make a decision. Earlier, he led SRE @ TrustingSocial.com to produce 600 million credit scores a day across 4 countries. In his past life, he built oogway.in (exit to TrustingSocial.com), datascale.io (exit to Datastax), and siminars.com.

OpenTelemetry isn't just a step forward; it's a leap into a new era of observability. Born from the complex needs of K8s, it has unlocked a world of possibilities that extend beyond the conventional realm. We can now visualize data like never before, illuminating insights that were once hidden.

OpenTelemetry isn't just a step forward; it's a leap into a new era of observability. Born from the complex needs of cloud and Kubernetes environments, it has unlocked a world of possibilities that extend beyond the conventional realm. From system modeling to application cataloging, process mining to testing, it has reshaped our traditional approaches to observability. But one transformation stands out - visualization. With OpenTelemetry, we can now visualize data like never before, illuminating insights that were once hidden. In this talk, we will explore the new dimensions of data visualization that these open-source observability tools have unlocked and embark on a captivating journey into what the future holds for data visualization in observability. Embark with me on a voyage through the world of observability visualization. As we delve into numerous examples and prototypes, both existing and potential, my hope is that they will ignite your own creative sparks. When it comes to understanding our complex systems, remember, visuals truly do matter! - A Brief and Personal History of Visualization in Understanding Complex Systems - Open Source Community , Opentelemetry and Innovation - Emerging Techniques - Serving the truth: Service catalog , process mining, etc - The Future of Visualization - A Personal Journey of Visual Prototyping - Sequence Diagrams from Traces - Converting Metrics to Topology and Encountering Boundaries - Exploring Tomorrow: Conclusive Insights

As an Observant Engineer, although I consider myself a newbie in data visualization, I have a clear vision of what I want to see in observability visualization. Instead of waiting for others to take the lead, I have taken it upon myself to prototype possibilities and unlock the full potential of OpenTelemetry. I see myself as an OpenTelemetry explorer, charting new territories, a modern Cartographer. With a passion for sharing knowledge and helping others navigate the complexities of technology, I strive to contribute to a more connected and empowered future, harness collective intelligence, embrace environmental responsibility, and democratize the evolution of the dialect between observation and understanding, where the sense of meaning might exist somewhere within this relationship. Young in Heart, Child in Time. 👀 bio

Responding to incidents is work. It’s unplanned, sometimes chaotic, and often stressful. It should be getting better, but many organizations find improving difficult and often backslide into bad practices. Teams tackling too many incidents see more burnout and have less time to work on work that impacts the bottom line. Getting better at handling incidents takes practice and resources, changes to culture as well as improvements to tooling. We want to prioritize the most important issues, the problems that impact users, while delegating lower priority issues to automation. In the long term, reducing the number of incidents that responders have to deal with will improve team engagement, reduce burnout, and recapture time to spend on more important tasks. In this talk, we’ll cover a number of methods that will have a positive impact on incident response, from crafting alerts, to writing automation, to setting good practices to prevent frustration among your team

Feature flags allow you to enable and disable code without changing or deploying any source code, as well as letting you selectively route traffic to certain users or a percentage of certain users, along with other great tricks. It’s powerful stuff … but when you combine it with observability (the ability to understand the inner workings of your complex systems and other unknown-unknowns), what you get is a supercharged, superpowered version of both. With observability and feature flags, you and your teams get deep technical and business insights in real time about how your code is working, what changed with your last deploy, and how changes are impacting different users, apps, or groups.

The worst time to discover your processes are totally broken? During a live incident. Avoid incident management flops by running regular simulations that actually reflect a realistic incident environment. I'll teach you how.

Palms are sweaty, knees weak, arms are heavy...sound like your first on call shift? One of the biggest challenges in incident response work, especially for newer SREs, is the lack of safe spaces to fail. Incident simulations can be an effective way to take the terror out of that first on-call shift, but they take careful planning. In this talk, I’ll explore different types of simulations (from tabletops to full-on realistic mock incidents), how and when to utilize them, and how to make sure you get the most out of them.

Ashley Sawatsky is an expert in incident management and communication, with a focus on the SaaS world. In her 6+ years of experience building and scaling Shopify's incident response program, she developed the ability to fluently translate the technical aspects of SRE incident response to Legal, PR, Customer Support, and Executive stakeholders. Now, she works at Rootly as Senior Developer Relations Advocate, where she engages with the SRE and incident response communities, and consults with customers from the world's largest tech companies—like Canva, Figma, NVIDIA, and more—on their incident response strategies.

Come and explore the landscape of SRE as it is in 2023, with the new trends, techniques and tools on the horizon.

On March 8th, Datadog had a massive global outage. It took more than 500 engineers split amongst many teams over two days to coordinate the incident response. In this talk, I will go over the trigger of the incident and why it took such large-scale efforts to resolve, and some of the technical and social lessons learned from the event.

Resource inefficiency with K8S autoscaling often begins with improper vertical scaling. Then horizontal scaling compounds these issues, which manifest as high cloud costs as the cluster autoscaler adds instances. In this talk, I will inform people how they can use ML to enable effective autoscaling.

Without autoscaling, most companies recognise they’re either wasting a lot of resources or risking performance/reliability issues. There’s no way to effectively set resource requests unless your actual usage is completely flat. A way to solve this is by having knowledgeable people look at it all day to make adjustments, or you can just take the financial hit or the risk of instability. Alternatively one can use technology like machine learning to solve the issue with high accuracy and little to no effort. In this talk, I will inform people how they can use machine learning to enable effective autoscaling.

Erwin Daria is Director – Alliances and Partnerships at StormForge. After serving in roles building and leading infrastructure teams, Erwin has transitioned to the vendor side, serving and finding success in sales, marketing and product roles for companies like Tintri and Juniper Networks.