In most disciplines "Engineering" means the stuff that works, an application of scientific reasoning to solving practical problems. In Software, depending on your background, it either means something bureaucratic that doesn't work, or it is just another name for software development.So what are the ideas that we can use as tools to give real, practical advantage in our work in the way that other disciplines achieve? What ideas should we treat as "the tools of our trade" whatever the technology or problem before us? This presentation explores two "tools" that we can use, Testability & Speed.

Flame graphs are a visualization that helps developers easily find performance bottlenecks to cut computing costs and improve end-user experience. They can be used to answer many questions, including how software is consuming resources, especially CPUs, and how that consumption has changed since the last software version. Flame graphs are now a standard for CPU profiling and have been adopted in many programming languages and observability products, and are the basis for multiple startups. They were defined in "The Flame Graph" in the Communications of the ACM, by their creator, Brendan Gregg.

This talk covers the origins of flame graphs, how you can create them using open source software, and how to interpret them. In practice, flame graphs don’t always work completely due to problems walking stack traces, resolving symbols, and other issues; this talk explains the problems and shows you the latest techniques for fixing them.

Flame graphs are a tool for a bigger mission: To understand the performance of everything, all software and hardware. Advanced types of flame graphs that help further this goal will be explained, including differential, off-CPU, memory, disk, and network events. Many of these advanced flame graph types require newer kernel technologies to make practical, especially extended BPF (eBPF), and will see adoption in the years ahead.

Architecture is the decisions and trade-offs that are appropriate for the problem at hand. While a globally distributed fault-tolerant microservices architecture might be an interesting and fun challenge to build, diving in too early will likely result in disaster. This talk tells the story of a team's journey from a monolithic architecture to event driven microservices, including missteps and learning opportunities they discovered along the way.

Message-passing lightweight concurrency is one of the biggest selling point of BEAM languages, such as Erlang or Elixir. However, its usefulness is sometimes not fully grasped, which can lead to overly complicated technical solutions. Instead of choosing a BEAM language, developers may inadvertently end up emulating its concurrency features using a mixture of other technologies.

This talk aims to explain the BEAM approach to concurrent thinking. The talk goes beyond the basic syntax and mechanics, focusing instead on the practical aspect of BEAM concurrency. We'll explore various examples from real-life systems with the goal of demonstrating how BEAM concurrency can bring us many tangible benefits, which are useful in all kinds of systems, regardless of the business domain, scale, or complexity.

Code quality is an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for new features. The resulting technical debt is estimated to waste up to 42% of developers' time, causing stress and uncertainty, as well as making our job less enjoyable than it should be. Without clear and quantifiable benefits, it's hard to build a business case for code quality.In this talk, Adam takes on the challenge by tuning the code analysis microscope towards a business outcome. We do that by combining novel code quality metrics with analyses of how the engineering organization works with the code. We then take those metrics a step further by connecting them to values like time-to-market, customer satisfaction, and road-map risks. This makes it possible to a) prioritize the parts of your system that benefit the most from improvements, b) communicate quality trade-offs in terms of actual costs, and c) identify high-risk parts of the application so that we can focus our efforts on the areas that need them the most. All recommendations are supported by data and brand new real-world research. This is a perspective on software development that will change how you view code. Promise.

There is no such thing as a one-size-fits-all architecture. For example, most large-scale web companies have over time evolved their system architecture from a monolithic application over a monolithic database to a set of loosely-coupled microservices connected by asynchronous events.

This presentation introduces the idea of a "Minimal Viable Architecture". As a company and product evolves, its architecture needs to evolve as well. We talk about the different phases of a product -- from the idea phase, to the starting phase, scaling phase, and optimizing phase. For each phase, we discuss the goals and constraints on the business, and we suggest an appropriate software architecture to match. Throughout the presentation, we use examples from eBay, Google, StitchFix, and others.

You may have heard that Rust eliminates concurrency bugs, and this is largely true. This talk will be a deep-dive into the investigation of a concurrency bug that could not be caught by the Rust type system. We'll walk through the background on the asynchronous messaging systems at OneSignal that process billions of events per day, and discuss how a massive series of unfortunate coincidences caused almost a total stoppage of work.

Setting a Service Level Objective for your service is only the start of your quantified reliability journey. What do you do when you've had a few too many incidents and blown your error budget? Or had a pile of near-misses that burned the team out even though the user-facing SLO wasn't violated? What if the incident trigger was the infrastructure refactoring meant to improve, not harm, reliability & maintainability?In this talk, you'll learn how the team at Honeycomb handles incidents, chaos engineering, and the engineering feedback loop for reliability with social practices and architectural design.

What separates success from mediocrity? How do you turn that brilliant idea into reality? Why is everyone else so successful?

Questions of how to shape your life are never simple to answer and they always present more problems once you try. In this talk Lars provides simple, yet hard answers to many of the questions we want answered to succeed in life. Based on decades of soul searching, failures, wrong decisions and a mountain of hard work, Lars shares all the nuggets of what works and what doesn’t.

Rust is fashionable, but is it right for your team? This talk explains the benefits of the Rust programming language and provides some rationale behind the hype. It’ll then spend some time outlining decision criteria for adopting Rust and provide plan for incremental adoption, if that’s what your team decides to do.

Migrations sound boring and hard. If you do them wrong, migrations can cause outages, data corruption, and slow down your whole engineering team. But how can you do them right? In this talk, I'll share some learnings from working on different migrations over the years and offer some ideas for how to avoid as much pain as possible.

There are many ways a programming language can support effects. For many years, side effects were the only game in town. Today, there are a variety of ways to model effects in a more functional way, with each effect system having its own set of tradeoffs.

This talk introduces a simple, high-performance effect system based on tag unions - which can be implemented in the Roc programming language, as well as in OCaml using polymorphic variants. The system allows for easily mixing I/O operations that can fail in different ways (such as HTTP requests and file I/O), while still offering exhaustiveness checking on all the error cases. It also makes it easy to tell which functions are using which effects (for example, "this part of the code base does HTTP and reads from the filesystem, but is guaranteed not to write to the filesystem"), and to enforce at compile time that certain calls may result in some effects but not others.

If you're interested in a simple, high-performance effect system with these characteristics, come see what it's all about in this talk!

In this talk, you’ll learn about Metaflow, an end-to-end Machine Learning and Data Science framework from Netflix that shortened the time to get ML models in production from months to days. After its 1.0 release, Metaflow quickly became a beloved environment for rapid prototyping all the way to full scale ML. It’s been tested across thousands of ML projects and dozens of companies since its open sourcing in 2019. Currently, Metaflow is the 7th-most popular Netflix open source project of all time.

In the latter portion of the talk, we’ll discuss how Metaflow was made and the engineering mindset of the team that built it. You’ll walk away with practical takeaways that you can apply to your project.

Disclaimer: I do not represent Netflix and the views expressed in this talk are solely my own.

With technology, business models and business needs changing so rapidly, an adaptable architecture is critical to allow systems to cope with change. Historically, adaptability has been sought through anticipating the places where a system must be adaptable and through various architectural approaches. However, recent experiences have shown these approaches to be inadequate, at least as currently practiced. This talk presents some principles of evolutionary architecture that allow systems to respond to change without needing to predict the future. We then briefly describe approaches that realize these principles and discuss how these approaches support adaptability of systems in an evolutionary way.

Why do organizations change? What is the stimulus that inspires buzzword change initiatives like “digital transformation” or “modernization”? The needs of customers are always changing and evolving, and that necessitates organizational change. If we are transforming in order to better meet customer needs, doesn’t it make sense to re-contextualize the transformation of organizations in terms of the evolution of the value chains that fulfill those needs?

During this session, you will learn to use Wardley Maps to inform socio-technical transitions i.e. the guided evolution of the people, processes, and technologies that make up the organizations where we work. Wardley Maps use the concept of value chains (rather than streams) to consider the networks of technologies, teams, and functions that must interact in order to provide value to a customer. Wardley Maps are dynamic and encourage context-informed transition rather than light switch transformation.

Airbnb has a highly social and collaborative engineering culture so when the pandemic closed our in-person offices, there was a big shift in our ways of working. Now with our “live and work anywhere” work policy, Airbnb has embraced remote-first collaboration and culture. Through trial and error stories, learn how we effectively manage distributed engineering teams. Topic highlights include:

• Designing effective meetings
• Facilitating technical design discussions and knowledge sharing
• Collaborating as a team across time zones
• Creating a strong and intentional engineering culture

When we want to learn something new, we often observe how other people do it. We read about earlier, successful, like experiences. But we are often deceived. We hear only the good things, the things people did right. Join me for an adventure that did not always go well, where mistakes were made, people were hurt, and yet, the project was a success.

Learn together with me from Lord of the Rings, how to create a team, how to work together and how to finish a project against all odds.

As we transition to a zero carbon energy system, the grid is set to play a critical role. Transitioning from a centrally managed and planned grid to one in which millions of customer assets play a critical role requires new technology - for monitoring, orchestration, load balancing, and automation. How do we change everything all at once, while keeping the lights on? What can we leverage from distributed systems experience in big tech?

"Diagrams as code", as featured on the ThoughtWorks Tech Radar, is becoming a popular way to create software architecture diagrams for inclusion in long-lived documentation. The benefits of creating diagrams from text are well understood - text is version controllable, easy to diff, easy to integrate into build pipelines, and automatic layout facilities allow authors to focus on content. The majority of these tools (e.g. PlantUML and Mermaid) are focussed on diagramming though, and require you to create one text file per diagram, with only a limited ability to reuse diagram elements across multiple diagrams. At scale, this causes maintenance problems, and leads to inconsistencies between diagrams.

This talk will introduce and demonstrate the open source Structurizr DSL - a way to create a model of your software architecture using a textual DSL that's specifically targeted towards the C4 model. We'll also see how the DSL separates content from presentation, allowing you to render your diagrams with a number of tools, which in turn offers some answers for the tricky question of how to use the C4 model at scale.

At the time of writing this, Wikipedia’s “Cognitive bias codex” has more than 200 entries, and it feels like Daniel Kahneman’s “Thinking Fast and Slow” is referenced in every other software conference talk. It’s official: Human beings are just not the rational thinkers we like to think we are.

When we approach software architecture in an agile way, we are trying to embrace the uncertainty that comes with all software delivery, but at the same time we want to be diligent about the decisions that are harder to change later. This talk will go through just a few of the cognitive biases that can trip us up as architects and developers when we are making these decisions, and how to soften their potentially negative impact.

The serverless approach to development of cloud-native applications has grown steadily over the past 6 years. The company I worked for was an early adopter of serverless technologies and became an Australian and global success story - a true unicorn - whilst staying true to its serverless roots. During this time, my experience of serverless technologies and cloud-native architectures evolved and changed the way I build software. Join me in this to talk to hear how we built our original serverless platform, how our approach evolved, and how I think about and build my applications now. This talk is 100% free of containers.

In this talk we will cover: * How A Cloud Guru built its serverless architecture and the way it changed over time. * How I build serverless applications today and what is different. * Common challenges to the serverless approach of software development and how I deal with them. * What are the current serverless challenges and what cloud providers could do to help us.

As developers, we live under a constant barrage of helpful advice, often in the form of rules with cute names. We're told how to design, how to code, how to deploy, how to monitor: there are systems and rules for everything. How can we keep up? How can we know what's good advice, and what's bad?

Over time I've come to realize that just about every good piece of advice is actually a special case of something both more general and simpler. So, let me introduce you to the "one rule to rule them all."

Unless you sit at the very top of an organisation hierarchy, you have a manager. Your manager may be someone you enjoy working with, or not. You may respect their skills and experience, or not. You may rely on them for guidance and advice, or not. Whether you think you have a good manager or a bad manager, there are opportunities for you to leverage your manager to help build your own career. If you want a promotion or a pay rise, your manager is the first person who you need to get onside. This talk is not about "managing up". This talk is about how to turn your manager into your advocate and sponsor.

The Kingdom of the bright blue cloud is in trouble. They are in desperate need of your help for their brave knights to keep the dragon out of their databases and save their fairies and princesses from abandoned virtual machines and desolate networks.

In this talk you are in charge of the story, as you help Lars fight your way through the kingdom by making real time choices on which direction to go next, and which Azure services might solve the imminent danger in the kingdom.

Learn about a variety of cloud technologies, cloud services, and cloud approaches in a talk that is highly interactive. Which services and technologies is up to you though. The kingdom depends on you.

Research summarised in the book Accelerate points to a set of practices that lead to high software development organisation performance. Simultaneously, research from the Santa Fe institute on Complex Adaptive Systems over the last 20 years seems to point to a grand unified theory of organisational design. So have we cracked it? Do we now have the answer to the question: how do we create and scale high performing software and organisations? In this talk, James explores the relationships between team structure, software architecture and the emergent phenomenon of complexity science.

MFA (Multi-factor authentication) is a vital security pillar for any application, but sometimes it fails us as users and developers. How you use and implement MFA can significantly impact how secure it will be and the protection it ultimately provides. Finding best practices for implementing MFA can be difficult, so learn from a real-world implementation and know how to protect yourself and not let down your users.

Geeta will share some of the thinking behind choices that were made in Humio’s journey around early product design, team and company culture, trade-offs in product market fit, customer feedback loops and development needs in a high growth environment. This session will go into depth around why certain choices were made along the way, the impact of these choices and how Humio grew from a small Danish startup in 2016 to a key product technology at one of the world’s leading security companies, CrowdStrike.

Building software is the easy part. Evolving and maintaining it is the hard part.

Preferred approaches change, team members leave, tech debt accumulates, dependencies date, ownership changes, and everyone has a lot of other work on their plate. Software decay is a very real and endemic problem for us all. So how can you break from the cycle of build, atrophy, replatform, repeat?

Join us to hear about how REA Group are fighting software entropy - including measurement, process, company wide objectives, and ultimately lowering total cost of ownership and cognitive load through our platform product strategy.

Analog computing platforms, implemented on a range of electrical and optical substrates, are becoming pervasive and crucial for satisfying the computational needs of different domains. Delivering the potential of such hardware platforms to domain specialists is a challenge as these devices exhibit a host of analog behaviors that must be considered when mapping computation to the target hardware. This talk will discuss how software techniques can be leveraged to map programs to analog computing substrates at high fidelity.

Many engineers promoted to leadership take time to build skills in people management and are given little in the way of guidelines. There is no tech best-practice for how to hire, review performance, grow careers or promote. We do the best with what we have, but this inexperience can quickly lead to reinforcing old biases and low belonging for those in underrepresented groups, halting their career progress.

In this talk, Michelle recounts her journey and challenges of building a successful tech career from the “out-group” and what she has learned about creating a space where everyone can thrive. Take home practical advice to meaningfully kick start your team's journey toward excellence and inclusion.

Building distributed systems that work is quite challenging. But systems that provide customer value will grow and evolve, and scaling those systems by multiple orders of magnitude is even harder. Citing specific failures and successes from internet-scale consumer properties like Google and eBay, and measuring customer value through the architecturalilities, this session deep-dives into the often counterintuitive architectural principles of simplicity, orthogonality, asynchrony, and feedback.

Simplicity helps us turn seemingly intractable problems into discrete and solvable ones. We will discuss component responsibilities, single-threaded straight-line processing, and making changes in small steps.

Orthogonality allows us to compose separate concerns and bound the complexity of each dimension of the problem. We will discuss processing abstractions like mixins and addons, as well as communication abstractions like channels and pipes.

Asynchrony and eventual consistency further reduce complexity and lead us to drive the system design directly from what really matters – what is actually changing in our core business domain. We will explore events, caching, and dataflow.

Finally, fast and consistent feedback help us continually maintain and improve a complex system. We will discuss quality feedback in the small, as well as systems feedback in the large.

You will take away some interesting anecdotes, as well as actionable insights you can put into practice in scaling your own systems.

Adrian retired from Amazon in June 2022, and like a classic rock band on a farewell tour, Adrian will rerun and comment on excerpts of talks he's given in the past, including some of the original Netflix Architecture content from Qcon SF 2010, Microservices from MicroXchg Berlin, the GigaOM Cloud Trends talk from 2015, Communicating Sequential Goroutines from 2016, and AWS talks featuring animated kitchen sinks and lego spaceships. It will rock! Headbanging optional.

Transformation efforts must overcome a myriad of challenges to achieve success. Some of the inhibitors we will discuss include:

• Executives unaware of the transformation
• Failure to engage all the necessary parties
• Individuals losing power with the transformation
• New roles and disappearing roles
• Lack of an effective Change Agent
• Success conservatism
• Lazy buyers
• Blame-oriented cultures

For each of these inhibitors, we will cite a) situations where this occurred, b) mitigation actions to overcome the inhibitor, and c) the effectiveness of these efforts.

We will conclude by suggesting some best practices we are currently employing in anticipation of likely inhibitors, including our newest proposal process of only selling complete solutions to our clients (not just body-shopping people).