Architecture plans in enterprises tend to resemble late-night infomercials. First, you see a person or system that seems incapable of survival—a situation that can be immediately rectified if you just buy into the product. (One popular infomercial shows incompetent people mangling tomatoes transitioning into Ginsu-wielding sous chefs; the architecture pitch starts with hideous complexity then moves to clean orthogonal box diagrams.) Operators are always standing by.

Real architecture never reaches that blissful end state. Something always interrupts the program: businesses change, technology changes, or funding dries up. What would happen if you did reach the end state, anyway? Is IT in the company done? Of course not.

The truth is that there is no end state. We must all learn to build systems that evolve and grow. We need to stop aiming for the end state and understand that change is continuous. We cannot predict the details, but we can learn the general patterns.

Michael Nygard demonstrates how to design and architect systems that admit change—bending and flexing through time. Using a blend of information architecture, technical architecture, and some process change, Michael walks you through examples of rigid systems to show how to transform them into more maneuverable architecture.

This workshop includes both teaching and hands-on design sessions. Design sessions will be paper and whiteboard work in small groups. You’ll work on real problems drawn from a variety of industries. If you’re a developer or architect working with medium to large architectures and building applications in the context of existing systems or transitioning to new systems, this is the tutorial for you.

"A monad is just a monoid in the category of endofunctors".

That fact holds everything you need to know about functional programming (FP), right!? If that sentence is a jumble of confusing words to you, you're not alone.

FP is one of the most powerful programming concepts ever conceived, but it's mired in mountains of terminology and notation and often taught from the top-down. Think about it: it's much easier to think about climbing the mountain once you're already on the top and can see back down. But right now, you're standing at the base of the mountain, ready and eager to climb but all you have is a collection of fancy climbing gear and no clue how to use it to begin the climb.

This workshop is your primer on how to use this climbing gear to get started up the mountain. Most of the core concepts of FP are actually very intuitive and straightforward, when presented from the ground up without confusing terms or symbolic notations. Functional-light is a look at FP that helps you start the climb, not a lecture on why the climb should be easier than you think it is.

We'll look at: function parameters, side effects/purity, composition, immutability, closure, recursion, list operations, and more!

If you're ready to start using FP concepts intuitively and pragmatically to improve your code, and not just hearing confusing terms, this workshop is for you.

Enterprises need to deliver better software faster. It’s no longer sufficient to release quarterly or even monthly. Instead, organizations must use methods, such as DevOps, to frequently deploy changes into production, perhaps as often as multiple times per day. One obstacle, however, to DevOps-style development is that organizations are often mired in monolithic hell. Key business applications are large, complex, unwieldy monoliths, and so it’s impossible to rapidly and safely deploy changes.

The solution is to adopt the microservice architecture, which is an architectural style that has the testability and deployability necessary for DevOps. In this workshop, you will, through a combination of lectures and discussions, learn how to use the microservice architecture to develop your applications. We will describe how to solve some of the key obstacles you will face including distributed data management. You will learn about strategies for refactoring a monolith to a microservice architecture.

An evolutionary architecture supports incremental, guided change across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on recent book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.

In this full-day workshop, you will learn how to create applications that survive the rigors of life in production. Too often, project teams aim to pass QA instead of aiming for success in production. Testing is not enough to prove that your software is ready for continuous availability in the corrosive environment of the Internet. During this workshop, you will receive an understanding of the architecture and design patterns that can produce high availability in distributed, multithreaded systems. You will also learn about the antipatterns that can sabotage your systems availability and capacity.

Large organizations often struggle to launch innovative products, improve processes or create environments to help their people succeed. A number of factors conspire to obstruct moving fast at scale; competing priorities, siloed thinking, risk averse cultures and an inability to adopt an experimentation mindset all play a part.

Lean Enterprise: How High Performance Organization Innovate At Scale lays out an alternative future vision for organizations with practical principles and patterns to help you move fast at scale—and demonstrate why and how to apply these methodologies throughout your entire organization, rather than with just one department or team.

Smart enterprises constantly evolve their system of work, from governance and financial management to technical architecture and organizational design in the pursuit of radically improved performance. Adopting Lean Enterprise is challenging, will take time and commitment, but is vital to harness the forces that can accelerating the rate of innovation in your organization.

In the global marketplace that transfers knowledge at the speed of light, we have a massive time delay and that is modern transportation methods. The hyperloop is the first new mode of transport to be created in over 100 years. The motivation is to connect people, reduce congestion, and protect our planet by eliminating CO2 emissions from terrestrial transport. The hyperloop can best be described as space travel on the ground - a magnetically levitating, electromagnetically propelled, passenger vehicle in a vacuum tube. With the elimination of aerodynamic drag and surface friction, power consumption plummets, speeds can reach 700 mph, and waste and cost are minimized. With the use of autonomy the service is on demand and delays become a thing of the past. Dr. Sengupta will discuss how space-age tech coupled to the VC funded innovation environment are enabling the revolution in green transportation from suborbital rocket flights, to electric airplanes, to space travel on the ground with the hyperloop.

Microservices sound appealing, but what can we do with those ten-million-line code bases? Shared domain objects, horizontal coupling, and years of boundary erosion have left us with enormous complexity and spiderwebs of coupling. Michael will share techniques at various levels of abstraction, from implementation details to API design and responsibility allocation. There’s no silver bullet that will make it easy to decompose a monolith, but you’ll learn some techniques that have helped and some pitfalls to avoid, all based on Michael's experience with both successful and failed transformations.

PayPal processes more than $1B in payments every day, is an accepted method of payment in over 200 countries, and covers everything in the online payments ecosystem from issuing credit and debit cards, to supporting credit card & POS processing, facilitating checkout at online merchants, and making it easy for friends to split a dinner bill or resolve shared expenses. All of this convenience comes with the added security of some of the most advanced fraud prevention algorithms powered by huge repositories of data. Given the vast ecosystem that PayPal has been playing in over the past 20 years, PayPal has collected large amounts of payment transaction and contextual data relating to consumers, merchants, and products -- over 150PB of data to be precise. How does PayPal manage this massive amount of data while all the while extracting useful insights that can propel the business ever forward? Come to this talk to find out!

An evolutionary architecture supports guided, incremental change across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This talk illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.

In this talk I'll discuss my experiences building Kubernetes controllers using as a case study Contour, a new Kubernetes Ingress controller, that I've been working on since joining Heptio.

This presentation will cover:

• What an ingress controller is and what role it plays in a Kubernetes cluster.
• Why Heptio chose Lyft's Envoy proxy as the data plane for our ingress controller.
• How Contour works as a translator from Kubernetes to Envoy. The parts that were a good match, the parts that weren’t, and how we dealt with it.
• How to develop a component of an interactive system like Kubernetes while avoiding the dreaded compile/push/deploy time sink.

The best way to understand neural networks is to get your hands dirty and write one.

In this session, we'll start from scratch and invent a neural net that can recognize handwritten digits with over 98% accuracy. Without leaning on any libraries! From the bottom up, we'll discover gradient descent, activation functions and backpropagation, as well as the mathematics behind this fascinating machine learning technology.

We'll code entirely in C# in a lightweight IDE (LINQPad). And you'll get to keep the code!

We used to build software like bridges. There was time for careful collection of requirements and the analysis of design options. But we don't do that anymore, in part because the time we spent did not ensure we hit our targets or avoided risks. Today, most companies use some form of continuous design where the software changes in small steps, often weekly or even daily, which makes those companies responsive to environmental changes. The problem is that in just a few years the software becomes over-complicated and usually needs to be rewritten, even when the team refactors. The longer you let the team code, the worse the code gets. That's a shame because other kinds of engineering don't have this problem. Car engines, for example, improve every year. I'll primarily discuss some ideas about why things work out this way and also some promising ideas for how we can practice continuous design longer, if not forever.

Data integration is a really difficult problem. We know this because 80% of the time in every project is spent getting the data you want the way you want it. We know this because this problem remains challenging despite 40 years of attempts to solve it. All we want is a service that will be reliable, handle all kinds of data and integrate with all kinds of systems, be easy to manage and scale as our systems grow. Oh, and it should be super low latency too. Is it too much to ask?

In this presentation, we’ll discuss the basic challenges of data integration and introduce a few design and architecture patterns that are used to tackle these challenges. We will then explore how these patterns can be implemented using Kafka producers, consumers, Kafka Stream, and KSQL

Difficult problems are difficult and we offer no silver bullets, but we will share pragmatic solutions that helped many organizations build fast, scalable and manageable data pipelines.

Programming is a series of frustrations. Everything we do, we could do better or faster if we only had our tools set up just so. If our error messages were a little better, our code a little cleaner, our tests a lot wider. When we spend time on this, it's known as "yak shaving," and it can get messy.

How do you balance the work you’re supposed to be doing with the work that makes your work, work? Dive into the yak stack with me. We'll see five different species of yak, and discuss how and when to tackle each one. At the bottom of the yak stack, we might find the Golden Yak, with secret wisdom engraved on its skin.

This session will give you reasons to spend time smoothing your development experience, and clues for where to spend that time in ways that help your whole team.

When we think of modern data processing, we often think of batch-oriented ecosystems like Hadoop, including processing engines like Spark. However, the sooner we can extract useful information from our data, the better, which is driving an evolution towards stream processing or “fast data”. Many of the legacy tools, including Spark, provide various levels of support for stream processing, but deeper architectural changes are emerging.

Chris Ford shows how to make music starting with the basic building block of sound, the sine wave, and gradually accumulating abstractions culminating in a canon by Johann Sebastian Bach. Examples live-coded in Clojure.

Effective leadership comes with a large learning curve. In today’s rapidly-evolving business climate, this is more true than ever for seasoned leaders and entrepreneurs alike.

Many leaders rely too heavily on past achievements, practices, and ways of thinking to drive positive business results today, but they often need to unlearn those behaviors before they can take a step forward.

Join executive coach Barry O’Reilly as he breaks down a transformative framework that shows leaders how to rethink their strategies, retool their capabilities, and revitalize their businesses for stronger, longer-lasting success.

Software security defects come in two categories: bugs in the implementation and flaws in the design. In the commercial marketplace, much more attention has been paid to finding and fixing bugs that has been paid to finding and fixing flaws. That is because automatically identifying bugs is a much easier problem than identifying design flaws. The IEEE Center for Secure Design was founded to address this issue head-on. My presentation will cover the IEEE CSD’s first deliverable by introducing and discussing how to avoid the top ten software security flaws. The content was developed in concert with Twitter, Google, Cigital, HP, Sadosky Foundation of Argentina, George Washington University, Intel/McAfee, RSA, University of Washington, EMC, Harvard University, and Athens University of Economics and Business. During the talk, I will introduce and discuss how to avoid the top ten software security design flaws. It's important, of course, to know that these flaws account for half of the defects commonly encountered in software security. But more important still is learning how to avoid these problems when designing a new system or revisiting an existing system.

Live Coding systems encourage us to think extremely differently about programming languages. In addition to considering standard requirements such as reliability, efficiency and correctness we are also forced to deal with issues such as liveness, coordination and synchronization all whilst working in real time.

Live Coders not only run and modify code live — they often perform with it on stage in front of large crowds of people who really don't want the code to miss a beat. In this code and demo-heavy talk, Sam will introduce the motivation for Sonic Pi - a system designed specifically for live coding music - before taking a deep technical dive into the internal ideas and innovations. The audience will explore Sonic Pi's novel temporal semantics which allow multiple concurrent threads to execute in synchronization along with live hot-swapping of code.

Ultimately, everyone will discover an exciting area of programming language research in an approachable and instructive manner all whilst making some sick beats and drops.

At Netflix, improving the performance of our cloud means happier customers and lower costs, and involves root cause analysis of applications, runtimes, operating systems, and hypervisors, in an environment of 150k cloud instances that undergo numerous production changes each week. Apart from the developers who regularly optimize their own code, we also have a dedicated performance team to help with any issue across the cloud, and to build tooling to aid in this analysis. In this session we will summarize the Netflix environment, procedures, and tools we use and build to do root cause analysis on cloud performance issues. The analysis performed may be cloud-wide, using self-service GUIs such as our open source Atlas tool, or focused on individual instances, and use our open source Vector tool, flame graphs, Java debuggers, and tooling that uses Linux perf, ftrace, and bcc/eBPF. You can use these open source tools in the same way to find performance wins in your own environment.

There’s a story to tell, about musicians, artists, philosophers, scientists, and then programmers.

There’s a truth inside it that leads to a new view of work, that sees beauty in the painful complexity that is software development.

Starting from The Journal of the History of Ideas, Jessica traces the concept of an “invisible college” through music and art and science to programming. She finds the dark truth behind the 10x developer, a real definition of “Senior Developer” and a new name for our work and our teams.

Microsoft issued me a Mac when they hired me to help people use Linux on Azure. If this sounds like the beginning of a nerdy joke, it’s because we need to question long-held opinions, let go of deeply-cherished stereotypes, and welcome this new era of open collaboration.

Let’s take the 10,000 foot tour of today’s cloud, containers, and orchestration landscape before diving into specifics we can use when making calls on microservices, backing data stores, and app decomposition. We’ll talk public cloud, containers, and k8s from the “Open at Microsoft” perspective!

When engineering teams take on a new project, they often optimize for performance, availability, or fault tolerance. More experienced teams can optimize for these properties simultaneously. Now add an additional property: feature velocity. Mental models of architecture can help you understand the tension between these engineering properties. For example, understanding the distinction between accidental complexity and essential complexity can help you decide whether to invest engineering effort into simplifying your stack or expanding the surface area of functional output. Chaos Engineering was born within this conflict between feature velocity and increasing complexity. Rather than simplify, Chaos Engineering provides a mechanism for you to embrace the complexity and ride it like a familiar wave, maintaining our business priorities while dialing up feature velocity.

The most complicated state in an application is time. Like cooking a bag of microwave popcorn, modern web applications desperately try to keep up with their state through an orchestrated chaos of asynchronous operations popping off in indeterminate cadence. No question, coordinating all this concurrency is hard.

But there's a pitfall at the heart of asynchrony that stays mostly unaddressed.

When an operation doesn't finish right away, synchronously, it's possible the operation may never finish. Or, it may be destined to finish eventually, but a second operation may be raised which means we no longer care about the first. Whatever the case, we need to be able to cancel it. This critical check ultimately protects users from the vagaries of unpredictable systems.

Cancellation should be core to our async programming; no asynchrony should run without it. Too often, such handling is just a corner case exception. Without a cancellation strategy, your applications are incomplete at best.

We'll discuss use-cases for async cancellation and various approaches to managing them.

Pre-aggregated metrics and time series form the backbone of many monitoring setups and have many redeeming qualities, but simply aren't sufficient for capturing the many ways things can go wrong in modern or complex systems. Problems inherent in the concepts behind and implementation of pre-aggregated metrics prevent them from being effective for any sort of debugging or diagnostics; we'll talk about why that is, and what techniques we should be leaning on instead.

As we construct larger or more complex systems, failure and change are ever-present. We need to accept and even embrace these tensions to build software that works and keeps working.

This is a talk on building and operating reliable systems. We will look at how systems fail, particularly in the face of complexity or scale, and build up a set of principles and practices that will help us implement, understand and verify reliable systems.

Have you ever wondered what _this_ actually is, and how it relates to other JavaScript black magic, like prototypes or the _new_ keyword? Many frameworks have been designed to hide you from needing to fully understanding this and many related concepts.

In this session, Jake will dive into all of the above and will also cover how the new ES2015 language features like arrow functions, keywords like let, const and classes with constructor functions which make dealing with _this_ much easier to understand.

The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging. In this presentation, you will learn how to solve these distributed data management challenges using asynchronous messaging. I describe how to implement transactions using sagas, which are sequences of local transactions, coordinated using messages. You will learn how to implement queries using Command Query Responsibility Segregation (CQRS), which uses events to maintain replicas. I describe how to use event sourcing, which is an event-centric approach to business logic and persistence, in a microservice architecture.

Have you ever had a gut feeling a project is about to go off course but no way to validate (or invalidate) that feeling? Has your team ever been burned by an inaccurate estimate or unreasonable expectation? Have you ever wished you could peer a bit into the future?

Navigating the uncertainty of knowledge work is often difficult and uncomfortable. During this session, you’ll learn new ways to visualize your team’s reliability and variability of delivery using the data you already collect. Instead of relying entirely on your gut or laboring over estimates, you’ll learn to predict outcomes and describe their likelihood. While this session won’t teach you to eliminate uncertainty or allow you to see the future, it will provide you with tools to explore and chart a reasonable course through the inherent ambiguity of knowledge work.

There's more to a Natural Language Processing (NLP) application than an ensemble of models. Much more! Like any traditional application, there is an entire ecosystem of supporting tools that enables core ML functionality. How do you choose the best ones? Which ones can you do without? How do you maintain context when the complexity of such a system gets out of hand?

In this session, you will learn how to deploy the full scope of an NLP application on Kubernetes with Kubeflow. The guiding principles of a robust and resilient system are explained and used as the foundation for defining a specific architecture. Techniques for modifying and maintaining it over time are described. Find out what Kubeflow currently supports and the long-term vision for the project, presented by a project contributor.

Container technologies such as Docker are rapidly becoming the de-facto way to deploy cloud applications, and Java is committed to being a good container citizen. This talk will cover some of the new tools and techniques for reducing container size (jlink, Alpine/musl support), for improving startup time and sharing of data between JVMs (AppCDS and ahead-of-time compilation), and the recent work that has gone into interacting with container resource limitations.

A Cloud Guru built one of the largest platforms using serverless technologies like AWS Lambda and API Gateway (we don’t run a single server, anywhere). It has been an incredible journey and we learnt a lot of lessons scaling our platform to 650,000+ users.

In this session we’ll share notes from our experience including:

• What our serverless system looks like 2 years in (inc. key metrics, architecture, and cost)
• Our serverless security posture
• Important design patterns and architectures
• Common serverless mistakes and how to avoid them

We will dive in to the design of our platform and share interesting data, go through key patterns and architectures, and discuss what it actually takes to build a scalable, reliable and high-performing cloud-native serverless systems today. This talk will focus on AWS but many of the principles and concepts can be carried across to Microsoft Azure and Google
Cloud Platform.

We're a generation of programmers who grew up with object orientation and imperative programming. When we transition to languages such as Elixir (and even some modern idioms in JavaScript), some of our old reflexes are no longer appropriate. Others are deeply useful, but in different and surprising ways. So, as we work towards the ideal of "programming by transforming", we mustn't forget to transform our thinking, too.

(ps: reducers are objects...)