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.

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

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.

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.

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.

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.

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.

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.

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.

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 than 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, Synopsys, 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.

In Switzerland, people will be surprised at a bus that's 2min late. In Sydney, people will only consider it noteworthy if a bus is more than 20min late, and this varies greatly between routes and providers. So, how do Sydney bus routes stack up? And if we're talking about privatisation, how do the private bus providers stack up against the state busses?

To answer these questions we need data… lots of data. Hooray for open government data! Transport for NSW publishes real-time information on the location and lateness of all public transport. Unfortunately it's ephemeral – there is no public log of historical lateness for us to analyse. To gather the data I needed I had to fetch, log and aggregate ephemeral real-time data that was never intended to be used this way. There are random gaps and spontaneous route or timetable changes for special events, roadworks or holidays. Even with noisy data, the patterns start to emerge across months and we can start to answer some questions. The 370 bus route is one of the most complained about routes in Sydney, it even has it's own Facebook group of ironic fans... but is it really the worst bus? Let's look at the data.

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!

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!

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.

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.

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.

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.

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.

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.

Today companies are expected to be flexible and both rapidly responsive and resilient to change, to both survive but also to thrive on disruptions. These challenges call for company-wide agility. Yet, doing Agile (the mechanics) is different from being Agile (the mindset). For example, substituting management meetings with daily Scrums or using a backlog for the board of directors doesn’t make a company agile.

In order to become truly agile (meaning flexible, responsive, adaptive, fast, and nimble), you need to think outside the (agile) box. Company-wide agility requires a holistic approach, a combination of different principles: First and foremost the principles of

• Beyond Budgeting (flexible budgeting & relative targets),
• Open Space (leveraging the innovative power of all employees),
• Sociocracy (flexible organizational structures and decentralized decision making), and –of course–
• Agile (inspecting & adapting).

We synthesized these proven principles into a wider perspective dubbed BOSSA nova: B = Beyond Budgeting, OS = Open Space, S = Sociocracy, A = Agile. Jutta will reveal a path toward company-wide Agility by showing the synthesis of BOSSA nova.

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.

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.

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.

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.