When building modern architectures, the hard part isn’t learning Kubernetes or deciding whether or not to use Kafka. The hard part is changing the way (almost) everyone thinks. Many of our mental models and communication patterns have been optimized for feature-driven software delivery. Which means … if we don’t change the mental models and communication patterns, we will deliver the exact same system we already have. Regardless of how performant our microservices are.

In this talk, we’ll explore this Mindshift: thinking in systems, designing for capabilities, drawing system boundaries, Agility at the core of learning teams and most of all, the essential patterns development teams can adopt when they get started.

We have been building microservice architectures for about ten years now. And slowly but surely, the same thing is happening to us that made us sick and tired of our previous architectures. Technical debt is rapidly piling up, development costs are rising, and the architecture is turning into a big unmanageable ball. But, this isn't inevitable! With real-world examples, Carola will discuss how the RIGHT microservice architecture can rescue your organization.

As a software development consultant, Matt gets the opportunity to work with many different clients. Over the past few years, his work with clients has quite often involved some form of Monolith to Microservices transition. During this talk, Matt will share the techniques he has found to make this transition a success. One of the most common things he sees when teams are looking to embark on a Monolith to Microservices journey is they are all too eager to ditch their monolith codebase and jump straight into building new shiny Microservices. From his experience, if the current monolith is not well structured and reflective of the domain it is operating in then it’s quite likely the Microservices journey will be a painful one.

In this talk, Matt will argue why he thinks it is important to have a ‘Modular Monolith’ first with the appropriate domain seams modeled. These seams can then form the boundaries for future Microservices. This talk will touch on techniques such as EventStorming and Bounded Context mapping to identify the domain boundaries, as well as some core engineering practices that need to be in place (notably automation of testing and deployment, observability and general architectural governance). Matt will also discuss how to evolve integrations as your monolith evolves — including the often most complex integration of all — the database.

"One of the big takeaways from this talk I would like people to leave with is that often a well structured ‘Modular Monolith’ can be just as good as a set of MicroServices depending on your needs. Something I have come to learn over the years working with clients is that you really can’t shortcut the core things, most notably — Continuous Delivery practices and Domain Modeling. Without these two things, no Microservices journey will be successful. Getting these things ‘right’ often takes time and can be an iterative process. Doing so with a single Monolithic codebase can make that easier."

In this talk, we are going to take a closer look at why modularity is needed, what it actually can do for us, and how we can increase our chances of getting it right by taking a systems thinking approach. The claim made is that a holistic view of the problem space is critical; one that consider all its parts, including the business and all the people affected. Software development today is a inherently a sociotechnical endeavour and any modularisation effort, be it information hiding, SOA, microservices, DDD, Team Topologies and more, must take this into account in order to be able to create solutions that are sustainable and have the necessary conceptual integrity.

This talk will help you piece together all of the these good modularisation practices and understand the theory behind them, improving your holistic system design skills, and enabling you to create requisite coherence in your designs. Maybe this will guard you against the dreaded distributed big ball of mud, the killer of agility and productive collaboration.

The power of collaborative modeling comes from having a diverse group of people who, together, have a lot of wisdom and knowledge. You would expect that all this knowledge will be put to use, co-creating, and to design a model.

In reality, we don’t actually listen to all the available input and perspectives due to cognitive biases and ranking. Because not everything that needs to be said has been said, we will end up with sub-optimal models and architecture. Even worse, people don’t feel part of the solution and don’t commit to it.

Good architecture and design need all the insights and perception. If we are not aware, cognitive biases and ranking kills those insights and wisdom, and kills the effectiveness of your models! Join us in this talk where we will interactively explore how we can improve our facilitation skills and focus on neuro-inclusiveness with Lewis Deep Democracy (LDD). We will let you leave with the knowledge on how to observe sabotage behaviour, battle oppression, and to create safety in exploring alternative perceptions.

DevOps, Microservices, CI/CD, Pipelines, Test Driven Development all reduce time to production. But the bottleneck in software development has always been coordinating humans.

Contract Driven API Development to the rescue! Contract Driven API’s enable independent teams (humans) to collaborate while maintaining consistency. This approach can also reduce handwritten code and save weeks of time.

In this talk we look at how to put API’s at the center of your development, how to generate boilerplate code and tests, and get everything into a pipeline for continuous delivery.

An event-driven architecture uses events to trigger targets and communicate between decoupled services to achieve massive scale and flexibility.

This architectural pattern can also be applied to security as code. When applying this event-driven security architecture pattern, you can automatically detect security devitations and trigger automated security remediations. This security infrastructure can be defined as code and deployed as part of a continuous delivery pipeline.

In this session, Paul Duvall, a founder and former CTO of an AWS Premier Consulting Provider and an AWS DevTools Hero, will discuss and demonstrate scalable architectures that integrate Amazon EventBridge, AWS Config Rules, AWS Lambda, AWS Systems Manager, and AWS Step Functions to detect and remediate security deviations across an AWS environment. What’s more, you will see how to automate the deployment pipeline that provisions these security resources as code.

In order to explain certain astronomical observations, physicists created the mysterious concepts of dark energy and dark matter. Dark energy is a repulsive force. It’s an anti-gravity that is forcing matter apart and accelerating the expansion of the universe. Dark matter has the opposite attraction effect. Although it’s invisible, dark matter has a gravitational effect on stars and galaxies.

In this presentation, you will learn how these metaphors apply to the microservice architecture. I describe how there are multiple repulsive forces that drive the decomposition of your application into services. You will learn, however, that there are also multiple attractive forces that resist decomposition and bind software elements together. I describe how as an architect you must find a way to balance these opposing forces.

The implementation of micro frontends has, so far, been anything but easy. Since common frameworks and build tools didn't even know this idea, you had to dig into the tricks bag. Module Federation offered by Webpack 5 initiates a crucial change of direction here. It allows you to load separately compiled applications at runtime, and to share libraries between them. As webpack is used together with mainly all frontend frameworks nowadays, Module Federation is going to become widespread. In this session, you will learn how to use this mechanism to create micro frontends with Angular. Besides the default scenarios, we also look into dynamic Module Federation, sharing libraries, and dealing with version mismatches. At the end of the session, you will know how to use Module Federation in your projects and what the consequences are.

NRK TV is a TV streaming service for the Norwegian public, serving hundreds of thousands of users every day. This is the story of how we turned an increasingly complex and stagnating monolithic API into a more rapidly evolving modular API.

Two key elements in the transformation are hypermedia and domain-driven design. We use links to tie together bounded domain contexts that we keep separate to contain complexity. Clients can seamlessly navigate between e.g. editorial content, catalog, playback and personalized recommendations, without noticing or caring that different contexts could be supported by separate backends with varying degrees of criticality and separate failure modes. Since links enable us to support multiple paths through the API and more than one way to reach a goal, they also help us evolve our applications without having to coordinate updates for all our clients at the same time. Rather, clients can opt-in to new or improved functionality when it suits them.

Microservices present their own unique challenges around managing dependencies, continuous delivery, test automation and cost optimization. Oftentimes, these challenges aren't realized until an organization is well on its way to decomposing their monolith into microservces. In this talk, I will share my experiences with the toil associated with these challenges, and approaches we took to work around these challenges.

We will walk through three specific areas of toil:

• Developer Feedback - how to ensure the developers are able to get fast feedback on changes they are trying to make
• Continuous Delivery - how to optimize your delivery process to allow teams to deliver software with minimal dependencies on other teams
• Cost Optimization - how to empower teams to own the costs associated with their services
  
  

While we all want to work on shiny new software with shiny new technology, the reality is that many developers and teams are stuck maintaining legacy systems. While typically these systems continue to work, maintaining them can be painful. Yet the cost of replacing the old systems with new ones is unimaginable and financially untenable for many companies. How do we deal with this situation without abandoning our clients who are not yet candidates for rewrites or even for lift and shift.

In this talk, 30 year software veteran Julie Lerman, will share some of her own experiences and tips for keeping clients' businesses running while slowly helping them evolve to modern times, blending modern software practices into ancient systems.