Thomas Stringer - Zero to Secure: Using Open Service Mesh to Easily Reduce Your Kubernetes Attack Surface As applications are being built on modern platforms like the cloud and Kubernetes, we need to continue to answer these important security questions: Who can access what? What happens when (not if) an intruder gets into my Kubernetes cluster? What can they do? What data can they see and steal? Service meshes can answer these questions and bring important benefits to the software ecosystem. Let’s get hands on with Open Service Mesh to demonstrate how this can be done in a quick, easy, and effortless way. You shouldn’t have to be a service mesh expert to harden your Kubernetes cluster. Follow along as Thomas Stringer, a project maintainer, introduces Open Service Mesh, an Envoy-based Cloud Native Computing Foundation (CNCF) service mesh. You will walk away from this session knowing how to effectively and effortlessly implement defense in depth in your Kubernetes cluster: All with no application or code changes. After entering a few commands and understanding a few basic topics, you will be able to answer all those intimidating security questions with confidence!

Andreas Grabner - DevSecOps by Default: What have, can and must we learn from Log4Shell? It’s been a couple of months since Log4Shell ruined many Christmas holidays for developers, architects, ITOps and especially Dev(Sec)Ops teams. How did this incident help us strengthen our software supply chain? How have DevSecOps adopted their delivery and operations orchestration to prevent using vulnerable code or react faster once a new breach is detected? In this session we cover stories from DevSecOps teams that were on the frontlines when Log4Shell hit. We look into application security approaches and tools to detect vulnerabilities during delivery as well as in production and see how open source projects such as Falco, Keptn and others help DevSecOps teams to enforce a “Secure by Default” policy!

Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) in a descriptive model, using version control to store the files. There are many tools available for IaC. This talk would focus on the comparison of the popular tools - Arm, Bicep, Terraform and Pulumi. We will dive deep into what are the pros and cons of each tool with a simple demo.

Learn about the challenges of adopting site reliability engineering (SRE) in enterprises, and how we recommend cloud customers go about this journey: Influence adoption of SRE best practices by Cloud customers through evaluating their existing environment and architecture Identify how SRE guiding principles fit into a cloud customers existing organization (e.g. how to embrace risk) Adapt SRE practices for a cloud customers existing team structure and knowledge Nurture a successful SRE initiative outside of Google Stepping through the report: Getting Started with Enterprise SRE Why the SRE Approach to Reliability? SRE Principles SRE Practices Actively Nurturing Success Not Just Google Audience Takeaways: How to improve the odds that SRE will be successful in your Enterprise Hear some examples of teams who have tried in the past and what problems they encountered, and what they did to overcome them! Understand the level of reliability and investment is not the same for every organization, know before you go!

We can’t all be Shaq: why it’s time for the SRE hero to pass the ball and how to make it happen by Malcolm Preston Shaquille O’Neal is one of the most celebrated NBA players of all time. He played for six teams over his 19-year career and won countless awards — and for good reason. When the team needed two points, they knew they could throw the ball to Shaq, and let him go to work. He’d inevitably push someone around (hard not to do at 7’1” and 300+ pounds), dunk the ball, and the crowd would go wild. The skills (and probably the size) are different, but there are a lot of engineers playing the Shaq role at their company. When the 2 a.m. outage page goes out, they’re the first to respond. These nebulous heroes find the problem, determine the affected areas, fix the issue (or know who to call to fix the issue), wake up the VP, draft messages to send to customers and stakeholders, create tickets to address why things went bad. Then at 9 a.m., they go back to the job they were hired to do. Backs are patted, and life goes back to normal until the next 2 a.m. page. So what’s the problem here? Games are getting won, incidents are getting solved, it’s true. But are you truly setting your organization or team up for success by just “doing it for them” every time? A win doesn’t always have to come from a backboard-shattering slam dunk, and relying on the most dominant player to save the day isn’t a scalable solution for an organization’s continued success. Attend this talk to understand why it’s time to pass the ball and learn three ways you can take fast action to get there today.

THE most common question I get asked by people familiar with my recent journey is: ״how the hell did you go from a team of 1 to a 25 person engineering group in a year?״ We weren’t short on challenges this past year: lockdowns, remote onboarding for new employees, and hyper-growth struggles. Each of these can break a team on their own. But when you create and instill fundamental habits that grow individual capabilities, expanding the team isn’t just possible, it’s actually quite a natural progression. Without a solid game plan wouldn’t have made it very far. And moving forward, we’ve laid a roadmap that gradually empowers those 25 engineers to grow and take ownership, paving the way for the next 50. This is the story behind one of our engineering groups, and how we’re building a kickass, world-class team, which among other things, is changing the conversation around payments. In this talk, I’ll take a deep dive into our new strategy step-by-step, from planning to execution: my structured game plan for empowering engineers to drive your team’s rapid growth in size, responsibility, and impact.

The standard for a reliable system is 99.99% uptime, which requires teams to have full visibility into their systems to quickly find and fix issues. With the rise of distributed applications spanning the cloud, on-prem deployments, and SaaS solutions, it becomes increasingly complex to pinpoint and find the root cause of performance issues. In this session, we will discuss the complexities that come alongside getting visibility into your distributed systems running in the cloud as they scale. Then learn how OpenTelemetry collects, processes, and forwards telemetry data from your applications to your observability solution, enabling end-to-end visibility to quickly identify and fix issues.

When coaching my three daughters and their soccer teams for over 15 years, I started each season with a discussion about my philosophy about feedback. My mantra is that you don’t need to be bad to get better. I am coaching you not because I think you’re terrible but because I see true potential in you and I want you to be better. I carry that into my professional life and the relationships with my coworkers and my teams. We are not good at feedback, both giving and receiving. It can be uncomfortable to hear that you could have done better. It is awkward to give direct and honest feedback when the message is “you did not meet my expectations.” Usually the receiver is left feeling inadequate. The truth is that we need to change our culture such that feedback becomes a gift. A gift that is given to someone that we care about. A gift that is received from someone that we respect. Whether the feedback is verbal or written, from a person 1:1, from your teammates during a retrospective or information from your tools or pipelines, it should be embraced for your journey of continuous improvement. It is mandatory for a learning organization. It is imperative for Agile and DevOps! There are some important guidelines that should be followed for this to be successful and I will go into them in depth.