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.

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.

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!

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.

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).

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.

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.