So, the firefighters are in your data center, this is not a drill. There is no electricity, and the pager is more like a DDoS attack on your phone. You look at your watch, multiple thoughts running through your head. Why me? Why now? How do you pull the team out and through this catastrophe?

In this session we will look at managing a crisis of significant magnitude, where all the organization is impacted and there is no clear path through to resolution. We will review the following: - The culture of a learning organization going into the crisis. - Crisis management “in action” - Running a blameless post mortem - Creating tools for high engagement to support the crisis manager. During the presentation we will share real life events, such as a data center going dark with real firefighters coming to the rescue, and production services in the cloud that stop responding.

BIO - ARIEL: Ariel joined Taboola as Vice President of Information Technology in February 2014. With over 20 years of experience in Information Security and IT systems, Ariel leads a team of IT professionals that work to implement state-of-the-art solutions, from Open Source to home grown to traditional enterprise software, across the company’s global infrastructure. Ariel has held multiple positions as CISO and CIO for web-facing companies from startups to publicly traded firms including programmatic ad solution provider myThings and casino, poker and gaming provider 888 Holdings.

BIO - BARAK:“Trying is the first step towards failure”, said the great Homer Simpson and I would add that “Failing is the first step towards success”.
I’ve been around software since 2006, in various companies and positions, from C4 system for intercepting rockets through E-commerce and Ad-Tech.
I'm always keen to learn new technologies and test them to see how far to the edge I can take them. I practice this passion by day at Taboola with our team of rockstars, while by night I spend time on my second passion - brewing my own beer.

Github Copilot and tools that help us code better are cool. But I’m lucky if I spend 90 minutes a day writing code. We really need to optimize the hours we spend reviewing code, updating tickets and tracing where our code is deployed. Learn how I save an hour a day streamlining non-coding tasks.

This talk is unique because 99% of developer productivity tools and hacks are about coding faster, better, smarter. And yet the vast majority of our time is spent doing all of this other stuff. After I started focusing on optimizing the 10 hours I spend every day on non-coding tasks, I found I my productivity went up and my frustration at annoying stuff went way down. I cover how to save time by reducing cognitive load and by cutting menial, non-coding tasks that we have to perform 10-50 times every day. For example:

• Bug or hotfix comes through and you want to start working on it right away so you create a branch and start fixing. What you don’t do is create a Jira ticket but then later your boss/PM/CSM yells at your due to lack of visibility. I share how I automated ticket creation in Slack by correlating Github to Jira.
• You have 20 minutes until your next meeting and you open a pull request and start a review. But you get pulled away half way through and when you come back the next day you forgot everything and have to start over. Huge waste of time. I share an ML job I wrote that tells me how long the review will take so I can pick PRs that fit the amount of time I have.
• You build. You ship it. You own it. Great. But after I merge my code I never know where it actually is. Did the CI job fail? Is it release under feature flag? Did it just go GA to everyone? I share a bot I wrote that personally tells me where my code is in the pipeline after it leaves my hands so I can actually take full ownership without spending tons of time figuring out what code is in what release.

BIO: Hello! I’m Ori Keren, CEO and Co-founder at LinearB. I got my first coding job in 1999 and eventually became VP of Engineering for multiple start-ups before starting my own company. Before all that, my first experience programming was in Basic. In 1987 I was in 5th grade. My parents bought me a Sinclair Spectrum ZX with 48k RAM. I vividly remember the day I got that machine. A fire lit inside me and it never went away :-) That’s why I do this job.

When it comes to data solutions, one-size doesn’t fit all. Choosing the right best-matching database, or data tools, can be a game changer for your system. How can you take such decision effectively? The system, the company, the product, and probably your team - all are evolving, and the best solution for today may not fit tomorrow’s needs. In order to pick a data solution for longer term, you should evaluate the optional data tools according to several factors. These factors will reflect the requirements looking forward.

At this session, we will share such use case, of evaluating data solution, when we redesigned one of Oribi features from scratch. Our goal was to avoid a data explosion crisis, while the system kept scaling up. Having so many solutions out there - we needed to make sure that we are choosing the one that will support the increasing load farthest.

Eventually we picked up ten criteria factors, which we used to compare and choose the best solution effectively. Join the session to hear what were these factors, and get prepared for choosing the next data solution for your system.

BIO: Eynav is a fan of the combination of technology and people - bringing technical visions into implementation. For the past 2 years she has been leading the R&D group at Oribi, a big-data based product, that handles billions of events a day, while scaling both the system and the engineering group. Her main focus is to create processes that support high scale & high standards; striving to maintain scalable R&D groups and infrastructure environments, while investing in personal growth and deployments quality.

The word observable entered the English language roughly 400 years ago, but the concepts of what it means to see, comprehend, and understand something have been debated since time immemorial. Starting in the 19th century, a series of postulates and criteria coalesced into control theory, and it is from this body of knowledge that we gained the word “observability”. Today, with the advent of complex, interconnected computer systems, that word has taken on new meanings and connotations—some useful, some detrimental, and some just plain confusing.

In this talk, we’ll mix a little history, a touch of philosophy, and a healthy dose of reality, to demystify what observability means to us as professional computer people. We’ll tear through the marketing material and unearth foundational principles that will help us to build better infrastructure, write better software, and promote healthier business practices. Finally, we’ll explore some potential new avenues for discussion and understanding.

If operations is a classic big data problem, cloud Operations is a *huge* data problem. We all understand the volume of logs, alerts and metrics generated by SaaS applications, and the increasing complexity of hybrid infrastructure, requires you to step up your monitoring strategy and just like any other big data problem – it only makes sense to leverage AI to achieve the observability imperative.

Taking into consideration the sheer volume of IT monitoring data that you have to deal with each and every day as DevOps, IT or SRE- leveraging traditional, reactive monitoring tools and approaches wont cut it much longer. Infusing AI is not about magically identifying and automatically solving all your problems, but given the criticality of delivering a phenomenal user experience for SaaS- you can leverage machine learning models to provide you with insights-rather than data- to not only effectively detect abnormal behaviors but also to predict potential issues, map them to associated services and help you intelligently prioritize preventive, troubleshooting and remediation efforts.

Building and operating a global cloud infrastructure at a large scale is a complex task with hundreds of ever-evolving service components. I am happy to share with you some real-world examples of how AI is leveraged at Azure Marketplace and Linkedin scale to monitor wisely, predict capacity and save costs so you can think how you can take it home, and apply it in your production environments.

“Being oncall sucks. But it doesn’t have to!” We all heard this one before. Why is it though, that oncall still remains the biggest scar for many? What can a modern Engineering org do to rein the oncall dragons, and actually help people grow as professionals as they go oncall?

In this talk, I will present the main reasons why oncall is difficult in modern orgs, and describe ways to mitigate these hardships. The idea is that oncall is often the ‘backroom’ of an org, where all the technical and organizational debt take their toll. Be it unwieldy systems or broken processes between teams, oncall checks all the ‘weak boxes’. Therefore, the only way to win at oncall is to sort out your debts, starting with the organizational ones.

I will dive into the detail of the oncall rotation at Snyk as the org scaled from 1 to 220 people, what worked well about it, and what was less than perfect. I will discuss the decisions made to turn oncall into a building block of the org, and show a path to rein oncall in your organization as well.

Everyone wants observability into their system, but find themselves with too many vendors and tools, each with its own API, SDK, agent and collectors.

In this talk I will present OpenTelemetry, an ambitious open source project with the promise of a unified framework for collecting observability data. With OpenTelemetry you could instrument your application in a vendor-agnostic way, and then analyze the telemetry data in your backend tool of choice, whether Prometheus, Jaeger, Zipkin, or others.

I will cover the current state of the various projects of OpenTelemetry (across programming languages, exporters, receivers, protocols), some of which not even GA yet, and provide useful guidance on how to get started with it.

Everyone wants observability into their system, but find themselves with too many vendors and tools, each with its own API, SDK, agent and collectors.

With the increasing complexity of modern applications, continuous profiling methods and tools are gaining popularity among the Developer and Engineering communities. In this session, we cover what continuous profiling entails and why you should implement a profiler into your tech stack (if you haven’t done so already). We’ll then bring theory to practice and demonstrate a real-life scenario using gProfiler, a free open-source continuous profiling tool, covering Linux servers on multiple architectures (such as Graviton).

Do you know what it feels like to navigate as someone who can’t distinguish between green and red - looking at those badges that tell you whether something is broken or a-okay? I’ll give you a quick look into what it feels like with some examples from the monitoring tool Icinga Web 2.

We all tend to forget, that not everyone sees the world like we do. In this talk I’ll be walking you through different views in Icinga Web 2 with side-by-side comparisons for the default views and how different kinds of vision impairments affect those. The talks also features a few suggestions on how to improve colour schemes and making websites and webapps better to navigate with screen readers!

CI/CD pipelines are quickly becoming the path of least resistance for would-be attackers into sensitive internal systems, gaining access to critical data, with minimal effort.

In the InfoSec world when we talk about CI/CD security often times this focuses on specific aspects of securing your pipeline - scanning the code, protecting secrets, securely managing code deployments, or even authentication and authorization mechanisms, but we rarely talk about all of these together.

After years of being in the trenches and realizing that the attack surface is growing and the threat landscape becoming more and more complex, it has become increasingly apparent that security teams need to adapt and modify strategies to keep up with the new reality of CI/CD protection, without compromising developer velocity.

In this talk I would like to propose a new way of thinking about CI/CD security - that encompasses the three disciplines that comprise CI/CD security - security in the pipeline, of the pipeline, and around the pipeline. Partial coverage of any or all of these disciplines simply will not cut it with the continuously evolving risk landscape. Security engineers need to address each of these aspects in their entirety to provide the full scope of coverage that modern organizations need, and I will take a deep dive on the challenges each introduce, and the approaches and techniques for mitigating them based on adversarial sec research.

In your ever-changing Infrastructure, some changes are intentional while others are not.

Drift is what happens whenever the real-world state of your infrastructure differs from the state defined in your configuration. This can happen for many reasons, sometimes it happens when adding or removing resources, other times when changing resource definitions upon resource termination or failure, and even when changes have been made manually or via other automation tools.

While Terraform itself can detect drifts, in most cases, you will be informed about it too late: just before you are about to deploy new changes to your infrastructure. What’s interesting about Terraform though, is that you can apply changes in two separate and distinct steps of “Planning” and “Applying”. This means that you have full visibility of what Terraform is planning on doing beforehand, and if you are satisfied with the changes, you can choose to apply them.

So how does this work? When something is changed intentionally, it will appear in the source code, and the Terraform plan will not do anything. However, if any part of the infrastructure has been changed manually, Terraform’s plan will identify this, and alert you to the change. In other words, if your IaC drifted from its expected state, then Terraform’s plan will, in fact, detect it.

Applying this simple solution can empower DevOps and developer velocity, with the reassurance and context for unexpected changes in your IaC, in near real-time. This talk will showcase real-world examples, and practical ways to apply this in your production environments while doing so safely and at the pace of your engineering cycles.

In every development process there is the question, do we invest enough on quality? Do we need to invest more? Every team knows about the dilemma of how many tests is the right amount of tests we should write. Is 80% test coverage is good enough? Maybe 90%? 100%? Should we invest more time in unit testing? Are we wasting too much time on unit-testing? Should we invest time on a faster rollback mechanism?

WIIFM

“Without data, you’re just another person with an opinion” - W. Edwards Deming

SLO Driven Development is a framework that helps the developers focus on impact and balance of every aspect of the dev process. When working currently with SLI, SLA, SLO and error budget you can learn where to invest in the development process.

Let’s talk about the importance of good SLOs and how they can help us improve our day2day

In this talk, I will share do's and don'ts on how to onboard successfully in a remote or hybrid setup including moving to a leadership role, speaking from my own journey onboarding remotely in the midst of a global pandemic.

I will share the tips that worked for me for successful onboarding, how I was able to be productive, impactful, and make a good impression on others. The key issues as an “onbordee” that I will talk about are how to create relationships, make yourself visible in the company, time management, and more.

Since I started working in Augury over 100 new employees have joined the company. Each month I give a session that is part of their general onboarding process. This became a crucial step due to the fact that we are now a hybrid company and a lot of people are onboarding remotely or in a hybrid setup for the first time in their lives.

I joined the company as a backend developer and a few months into my role, the squad leader position in my squad was up for grabs and I was fortunate enough to grab it :) This is my first official leadership role, which I also needed to onboard into in a hybrid setup. I will share the process that I built for myself on “How to lead”. Also, a word or two on the process we built as a squad on how we work in a hybrid setup, what are we optimizing for when we do meet and how to include new members of the team.

This is a story about taking the cloud infrastructure of a successful company, that is still managed as infrastructure of a startup company, and rebuilding it to support the growing business requirements, especially around disaster recovery and business continuity. In the session I will share Next Insurance’s journey - where we started, where we are now and what we learned on the way so far. I will talk about how we managed to build our proven DR plans, and actually execute them in our DR drills. I will also talk about why we decided that the only way to prove your DR plan works is to continue running your business in the DR account and make it your production account, and go on to build your next DR account. If you are a part of a company that is about to embark on a similar journey, this session might equip you with some very useful insights on how to think about such a challenge, and some very useful and practical tips on how to execute it.

Configuration Management is at the core of Ops. It’s the biggest enabler of any compute operation, small and big. In the past decade, we have switched from thinking about the machines we are configuring, to think about the software and services we are controlling. With that change of mindset, so did the tools we are using. Traditional tools like Puppet, chef, salt and Ansible are slowly declining while new tools such as Terraform, Pulumi, Helm and Kustomize are on the rise. In this talk I will try to describe the pain-points and the opportunities of this transformation as well as suggesting a future direction based on tools developed at the big-tech companies (Mainly facebook and google)

In the world of microservices today, how can DevOps teams empower developers to troubleshoot K8s issues independently? We’ll discuss the current gaps/challenges today in the process, and 6 best practices DevOps need to ensure in order to enable developers to troubleshoot K8s issues efficiently.

In this talk we will discuss the 5 main best practices DevOps need to ensure to enable developers to troubleshoot K8s issues easily. This will be a technical talk elaborating the 5 best practices, including: 1. YAML best practices 2. Stateful vs stateless apps 3. Separated environment best practices 4. Logging best practices 5. Monitoring best practices 6. Training & enablement best practices

Learning about container security by breaking in to a live running container!

So you built your Next.js or other Node.js apps and containerized them, great job! But what does it take to secure a container? Are you sure you’re following all the best practices to build container images correctly? What are the threats you are not mitigating in a running container? There’s no better way to understand container security than seeing some live hacking! Join me to learn and adopt best practices of running secure containerized applications in production.

From idea to execution, the challenges of publishing an open source project are very similar to initializing a startup when it comes to creating a successful product that people will love and use.

Most open source projects are not “taking-off”, although they are really good! This is because developers (which are usually the creators of open source projects) think that writing the code is the hard part and “neglect” the other parts of publishing a good open source project.

In this talk, I will use my experience as a contributor to open source and product head of a startup, to go beyond writing the code itself and cover the other central aspects of creating an open source project, like MVP, product/market fit, marketing and more.

If you have never used GraphQL before, you probably think that it is just another buzzword that will be forgotten in a few years. You might think: “Why do I need to learn a new way to write APIs when REST already answers all my needs?”. Or, you are excited to learn something new but don’t believe GraphQL is mature enough for production.

In this talk, I will remind you of some of the pain points you have probably experienced when using REST. I will then explain what GraphQL is and demonstrate how it solves these pain points. Next, I will discuss the disadvantages of GraphQL. Finally, I will provide some guidelines for choosing between REST and GraphQL. By the end of this talk, you will understand what GraphQL is and when to use it.

“The International Space Station has been orbiting the Earth for over 20 years. It was not launched fully formed, as a monolith in space. Instead, it is built out of dozens of individual modules, each with a dedicated role - life support, engineering, science, commercial applications and more. Each module (or container) functions as a microservice, adding additional capabilities to the whole. Not only do the modules need to function together, delivering both functional and non-functional capabilities, they were designed, developed and built by different countries on Earth and once launched into space (deployed in multiple different ways), had to work together - perfectly.

Despite the many (minor) reliability issues which have occurred over the decades, the ISS remains a highly reliable platform for cutting edge scientific and engineering research.

In this session I will describe the way the space station was developed and the lessons Site Reliability and DevOps Engineers can learn from it.