Christin has been writing software for 19 years and is known for her energetic, engaging and entertaining presentations.

Have you seen those three dimensional modern art installations that look like a complete mess until you see it from the correct angle and a nice picture emerges? Software can be like that. What might look like a mess from one angle, is beautiful from a different one.
“We’ve got too many applications!”, “Just look at this architecture diagram! Lines all over the place”, “It’s a mess!”
These are common complaints from architects and developers alike in large organisations with software that performs all sorts of different tasks. But are we looking at the diagram from the correct angle?

I will present some examples and discuss how to reason about large software portfolios, go through which parts go together and which ones can or should be decoupled, and help identify that angle that gives us the best view of our systems.

Sam Newman is an independent consultant specialising in helping people ship software fast. Sam has worked extensively with the cloud, continuous delivery, and microservices and is especially preoccupied with understanding how to more easily deploy working software into production. For the last few years, he has been focusing in the area of microservice architectures. He has worked with a variety of companies in multiple domains around the world, often with one foot in the developer world and another in the IT operations space. Previously, he spent over a decade at ThoughtWorks and then left to join a startup, before setting up his own company. Sam speaks frequently at conferences and is the author of Building Microservices and Monolith to Microservices (O’Reilly).

<span">An internationally known author and speaker, Mike Amundsen travels the world discussing network architecture, Web development, and the intersection of technology and society. He works with companies large and small to help them capitalize on the opportunities provided by APIs, Microservices, and Digital Transformation. 

Amundsen has authored numerous books and papers. He contributed to the O'Reilly book, "Continuous API Management" (2018).  His "RESTful Web Clients", was published by O'Reilly in February 2017 and he co-authored "Microservice Architecture" (June 2016). His latest book -- "Design and Build Great APIs" -- for Pragmatic Publishing is scheduled for release in early 2020.

To realize the promise of easy self-service integration with APIs, we need to move past the system of bespoke API providers and single-use API consumers to an ecosystem where API-based applications can act as goal-seeking "self-driving" applications. We need an implementation approach that makes it possible for API consumers to solve their own problems at runtime by selecting, connecting to, and interacting with available services -- even when services move and change over time.

This ability to operate autonomously has been a part of the plan for self-driving cars for close to a decade. And we can learn from advances in the automotive field and apply the same principles to the virtual world of the API ecosystem.  

Using existing protocols, formats, and technologies, this talk shows how we can implement autonomous API platforms today and reduce the time it takes to bring solutions to market and increase the re-usability and stability of existing services on the Open Web.

The world of self-driving APIs is closer than we think and the time to take advantage of this opportunity is now.

Independent Tech Consultant & Product Architect at Datawire

Daniel Bryant works as an Independent Technical Consultant and Product Architect at Datawire. His technical expertise focuses on ‘DevOps’ tooling, cloud/container platforms, and microservice implementations. Daniel is also a Java Champion, contributes to several open source projects, writes for InfoQ, O’Reilly, and TheNewStack, and regularly presents at international conferences such as OSCON, QCon and JavaOne.

The introduction of microservices, Kubernetes, and cloud technology has provided many benefits for developers. However, the age-old problem of getting user traffic routed correctly to the API of your backend applications can still be an issue, and may be complicated with the adoption of cloud native approaches: applications are now composed of multiple (micro)services that are built and released by independent teams; the underlying infrastructure is dynamically changing; services support multiple protocols, from HTTP/JSON to WebSockets and gRPC, and more; and many API endpoints require custom configuration of cross-cutting concerns, such as authn/z, rate limiting, and retry policies.

A cloud native API gateway is on the critical path of all requests, and also on the critical path for the workflow of any developer that is releasing functionality. Join this session to learn about the underlying technology and the required changes in engineering workflows. Key takeaways will include:

- A brief overview of the evolution of API gateways over the past ten years, and how the original problems being solved have shifted in relation to cloud native technologies and workflow
- Two important challenges when using an API gateway within Kubernetes: scaling the developer workflow; and supporting multiple architecture styles and protocols
- Strategies for exposing Kubernetes services and APIs at the edge of your system
- Insight into the (potential) future of cloud native API gateways

Nicky is a principal engineer working at Skyscanner and formerly of the Financial Times and has been leading teams for more than 15 years, across a wide range of industries: travel, banking, media and telecommunications. She passionately drives forward cloud native architectures and approaches that allow engineers to deliver deliver business value quickly whilst also reducing the support overhead needed for complex distributed systems.

Historically when we developed large monolithic applications we had several ‘lower’ environments such as dev, test, staging, pre-prod for verifying different stages of our development life cycle. These were particularly used for manual testing - integration testing, gatekeeping, acceptance testing. However as we are moving to increasingly more distributed, complex and larger systems we have sought tools and processes to enable us to move quicker. We have more automation in our testing, we have more automation in our deployment and we are creating services that are loosely coupled and independently deployable. With this all the tooling and approaches now available to us, should we still be spending our time and money on running all these lower environments?

We thought not - At Skyscanner we don’t have lower environments only production. Well actually it is slightly more complicated than that but we will get to that. 

So in this talk Nicky will talk about:

• Why Skyscanner has chosen to ditch non production environments
• How Skscanner do this - What we have done to make this working practice possible and how do we maintain quality and confidence
• When does this approach not work - There are definitely some unsuitable use cases for this approach

Author of Running Serverless, Impact Mapping, Specification by Example and a few more books… Working on MindMup and Claudia.js.

Serverless architectures are becoming mainstream, significantly reducing time to market and operational costs; but to get the most out of this opportunity, applications have to be designed around the constraints of this deployment architecture. This session is a mix of an experience report and looking at future trends, explaining how domain modelling, distilling the core and serverless architectures overlap.

Principal Consultant & Conference Tourist

Stefan Tilkov takes a look at some of the ways you can determine whether the development efforts you’re undertaking suffer from too much or too little focus on architecture. You’ll examine a number of real-world examples that are intended to inspire either admiration or terror and try to find some recipes of how you can get more of the former and less of the latter in your own projects. You’ll look at examples for both options and hear anecdotes, with names and details changed to protect the sometimes not completely innocent, and try to extract descriptions of some common positive and negative influences. The goal isn’t to come up with a perfect recipe, but rather with some approaches Stefan has seen actually work in practice.

Co-Founder and Chief Technologist

Throughout my 15+ years in software development, I have helped automating highly scalable core workflows at global companies including T-Mobile, Lufthansa and Zalando. I have contributed to various open source workflow engines. I am co-founder and developer advocate of Camunda, an open source software company reinventing workflow automation. I co-authored "Real-Life BPMN," a popular book about workflow modeling and automation, now in its fifth edition and available in English, German and Spanish. I regularly speak at conferences and write for various magazines. I am currently focused on new workflow automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture and reactive systems.

These days, many teams favor loose coupling, isolation and autonomy of services and therefore typically opt for event-driven and reactive architectures, using a communication pattern known as choreography. While choreography is beneficial in some situations, it is far from the holy grail of integration. In some scenarios, it increases coupling, often accidentally and to a dangerous degree. Orchestration is a better choice for some situations, but is often bashed for introducing tight coupling. I will debunk some of these myths and show how orchestration can even reduce coupling in some situations and totally work in an asynchronous, message-driven fashion.

TLDR: Choreography vs. orchestration is NOT about choosing THE right approach. In real life, you need to balance both, so it is about choosing wisely on a case-by-case basis. In order to help you with that, I will walk you through the differences and give you some concrete guidance on decision criteria, backed by examples collected in various real-life projects.

Consultant, author of "Microservices in .NET Core"

Christian Horsdal is an independent consultant with 20 years of experience building many kinds of systems from large scale microservice systems to tiny embedded systems and lots of stuff in between. He is a .NET expert, author of the books "Microservices in .NET Core" and "Instant Nancy Web Development", trainer, and an occasional open source contributor.

Microservices are great. Or at least that is what all the buzz says. And they are. If you get them right. That is, if you get boundaries between them and the scope of each one right. If not, microservices are just a distributed mess - which is worse than a monolithic mess. In this talk I will outline how you identifying good candidates for microservices and how you define the scope for each one in a way that optimizes for maintainability in the long run, resilience in production and efficiency of work.

Site Reliability Engineer at Glitch

Mads works as a Site Reliability Engineer at Glitch. He loves diving head first into production issues, especially the weird ones. When he isn’t rummaging around in production he spends his energy making it easier to understand, and eventually more reliable.

Glitch is a platform that allows anyone to instantly create a web app right from their browser. Each is a full-stack app in its own container.

As Glitch was getting an ever-increasing amount of traffic we were sometimes struggling to keep up; what was previously considered performance edge-cases were now commonplace. A lot of Unknown-Unknowns became Known-Unknowns. About a year ago we started investing in observability tools in the hopes that it would help us maintain a high level of reliability so we could continue to provide a great experience for our users, even as more and more people started to run their apps on Glitch.

In this session, I'll go through Glitch's journey into Observability. I'll cover both the victories as well as the bumps in the road. As we go I’ll share what we might have done differently if we had to do it over, so you can be off to a good start if you want to make a journey into observability.

The attendees should walk away with a clear understanding of what observability is, why they might want to invest in it, and a reasonable plan on how to get there.

Principal Engineer, Financial Times

Monitoring all of a team's systems can be tricky when you have a microservice architecture. But what happens when you have many teams, each building systems using totally different technology stacks? Add in decades of legacy systems and a sprinkling of third-party tools and you’ve got plenty of fun in store. Discover how to approach monitoring an estate of many technologies and find out what the Financial Times did to improve visibility across systems built by all its teams.

Web Architect at IKEA Digital

Gustaf Nilsson Kotte is the lead of the Web Architecture Group at IKEA Digital and works as a lead engineer in the Frontend Framework team. He has over 10 years professional experience of building web sites, but he wrote his first web page 23 years ago and has been interested in creating things for the web ever since.

Gustaf has a MSc in Computer Engineering from Chalmers University of Technology, with double specialisation in Software Engineering and Computer Languages.

Four years ago, we started to build the new ikea.com e-commerce website. Today it serves over 2.5 billion visits per year. The website is currently developed by 15-20 frontend teams and built using a Micro Frontends architecture.

We started small, while thinking big. The journey was not a straight line and we have faced a lot of friction along the way. However, this friction can often be a good thing as it guides us in what our next steps should be.

You’ll learn about the basic building blocks of our web architecture such as static files, transclusion and reusable components. I’ll also talk about what I think the future direction could be.

Engineer particularly interested in software

Szymon works an engineer at Particular Software, the makers of NServiceBus. His main areas of expertise are Domain-Driven Design and asynchronous messaging. He is especially interested in the intersection of these two topics -- in the patterns and tools for ensuring all messages are processed exactly once and in the correct order.

In his free time Szymon plays with Lego, building models of real-life off-road vehicles.

No matter what technology vendors claim, the laws of the universe make exactly-once message delivery impossible. The only options we have are either losing messages (at-most-once) or getting duplicates (at-least-once). Let me suggest which one you should prefer: you don't want to miss that one million dollar order and only figure it out when reading the logs two weeks later.

Join me in a journey to explore various ways of ensuring duplicates are properly detected and handled. In the end, losing and order is surely bad but you don't want to fulfil that million dollar order twice either, do you?

Along the way we'll look at natural idempotence of certain data structures, immutable data and identity-based de-duplication.

Coding architect at Edlund A/S

Proglang researcher turned full-time software developer. Currently architecting at Edlund A/S. I like microservices, DSLs, distributed systems, writing and building stuff.

In this talk, I will discuss our learnings, positive and negative, in introducing Kafka into our large, mostly monolithic, .NET based software architecture.

Underway, I'll share details on our initial plans and designs. I'll quickly, however, curve into airing our dirty laundry and tell about false starts and setbacks.

I'll end on a positive note, and share our current state of affairs, and give some pointers for what you should look out for - both technical and less technical.