TDD Revisited
In this talk we will look at the key Fallacies of Test-Driven Development, such as 'Developers write Unit Tests', or 'Test After is as effective as Test First' and explore a set of Principles that let us write good unit tests instead. Attendees should be able to take away a clear set of guidelines as to how they should be approaching TDD to be successful. The session is intended to be pragmatic advice on how to follow the ideas outlined in my 2013 talk "TDD Where Did it All Go Wrong"
Succeeding at Reactive Architecture
In 2013 the Reactive Manifesto was published, establishing a set of properties for modern systems: responsive, resilient, elastic and message driven. In 2020, the Reactive Foundation published a set of principles and patterns for Reactive systems.
In this session we will look what reactive architectures are and what have we established about how to succeed at building reactive systems.
Our focus will be on how the properties we desire for reactive systems push us towards certain principles of software design. We will dig into how to achieve the properties of reactive architecture and learn how message passing is the key that unlocks isolation and with it resilience and elasticity. We will understand what it takes for message passing to achieve this, the key principles and design patterns that you need to know and apply. Along the way we will draw from the works of folks spanning the history of actor models, autonomous and reactive computing from Carl Hewitt to to Pat Helland and Jason Boner.
By the end of the session you should have an overview of the current best practice ideas you need to succeed at reactive programming.
Microservices, Where Did It All Go Wrong
Since James Lewis and Martin Fowler wrote their paper on the microservice architectural style in 2013, a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of the properties of the architectural style. Mis-associations with the Cloud Native style, and misapprehensions on how to move from monolith to microservices, meant that the architectures that emerged often bear little resemblance to the original idea; most are just distributed monoliths. Unsurprisingly these architectures are painful and costly to own. Ten years later, the resulting failure to realise the benefits promised by microservices, or a misunderstanding of what they were, has led to a backlash against microservices; now the prevalent wisdom calls for a "return to the monolith," and posters on Reddit have begun to speak of "Death by a Thousand Microservices."
This talk looks at the key misunderstandings around microservices: the problems that microservices were intended to solve; "what does micro mean?"; how to achieve independent deployability; how to avoid anti-patterns like a distributed monolith. It will also explain the problems that a monolith can't solve that cause us to choose microservices.
Managing Event Driven Architectures
You should be careful what you wish for. Once you have succeeded in persuading your team to adopt an event-driven architecture for communication between your microservices, you hit the problem of how to manage that event-driven architecture.
- How do you surface a definition that describes your event driven API
- How do you know who is talking to who?
- What declares your topics and queues, consumer of CD pipeline?
- What if you don't want someone to use your events?
- How do you avoid breaking downstream consumers?
- How many consumers do you need?
In this talk we will look at solutions to these problems. We will review emerging standards such as CloudEvents, and AsyncAPI and understand how we might use them. We will look at the role of CDC in helping us with versioning, and the tooling around we can use for that. We will look at the concept of a message registry and how it can help you understand the interactions in your estate. We will look at ways that we can use Logging and Monitoring tools to understand what is happening to your messages. Finally, we will look at how you determine the number of consumers that you need.
Kafka for .NET Developers
Kafka is a low-latency streaming solution with a rich ecosystem of tools such as Kafka Connect and Flink, but is less well-known to .NET developers. In this session we will introduce Kafka, explaining the mysteries of records, offsets, SerDes and schema registries, in-sync replicas, partitions and tools like Connect and Flink. There will be code, as we work with examples in .NET of using as a messaging solution in your applications. By the end of this session you should feel comfortable with the concepts required to use Kafka as a .NET developer.
Hustle and Flow
When trying to use events for interop between our microservices, engineers often run into the challenge of how to model interactions so as to enable asynchronous communication between their services.
We can look to the past for guidance.
Paper based offices used to be how every business ran. Looking at how they worked can give us a view of how work was done pre-automation, when asynchronous flows of paper were common. Mature business processes were event-driven with in-tray, out-tray and post room driving the flow of work in a business.
In the early 1970s J Paul Morrison invented Flow-Based Programming, a model in which a system was comprised of a number of applications communicating asynchronously through flows of discrete information packets.
By looking to these models from the past we can find valuable insights that will show you how you can model a system that uses events to communicate asynchronously today. Along the way we will learn how this can help us understand how modelling techniques like Event Storming echo these older aproaches.
By the end we hope to give you another tool to understand when your system needs to hustle, and when it needs to flow.
Conversation Patterns
Works such as Gregor Hohpe's Enterprise Integration Patterns describe the building blocks that allow us to send a message between two components. But components often exchange more than just a single message with their collaborators - that is they hold a conversation. Understanding how to build components that can hold successful conversations is the key to unlocking the power of event driven architectures - but too often we focus on just the single exchange.
Drawing on the works of Hohpe, Helland and others we talk about building blocks such as correlation ids, conversation ids and activities (including a discussion of outboxes and inboxes). With those we will talk about the basic conversational patterns: monolog patterns such as fire and forget and publish and subscribe and dialog patterns such as request-response and request-response. We will identify how ideas like Event Carried State Transfer are an important part of how we have conversations. We will cover how we deal with errors, such as tentative operations, retry or compensating actions. Finally we will look into macro scale conversational patterns such as choreography and orchestration.
During this session we will also talk about messages vs events and related issues such as causality.
Capability Mapping
In their description of microservices James Lewis and Martin Fowler noted that: “The microservice approach to division is different, splitting up into services organized around business capability” But what is a business capability? How do you find them? And why does orienting a microservice around them make a difference.
In this session we will try to shed some light onto the black art of building a business capability map, and how you can use that to define the boundaries of your microservices. We will also look at ideas such as the Inverse Conway Manoeuvre and Products not Projects that enable greater agility and product velocity through the alignment of microservices and capabilities.
Then we will tackle how all of this relates to Domains and Bounded Contexts.
Finally, we will look at how some technical concerns, such as integration can be soothed by better understanding how a capability map gives you more effective boundaries.
Being Staff Plus
For a long period of time the only path that organizations offered developers who wanted to grow their influence was the management track. In recent years organizations have begun to offer individual contributor roles beyond senior developer such as staff or principal engineer.
Staff Plus roles differ from senior engineering roles and require new skill sets to influence, guide and shape the engineering direction of an organization and often require the engineer to work independently.
In this presentation we will cover what you need to know about Staff Plus roles:
* Staff Plus Roles and Archetypes
* Moving Beyond Code
* Technical Leadership
* Work on What Matters
We will cover topics around influence without authority, determining where to spend your time, and how to help the engineering teams succeed.
We will finish with an exploration of how you move toward a Staff Plus role
Adopting Poyglot Flow
There are many brokers that we could consider using when building an Event Driven Architecture. Do we go with Kafka, RMQ, Pulsar, NATS to name but a few? Vendors make bold claims, promising that their broker alone is adequate to form the digital nervous system for your architecture. What should you do?
In this session we argue that one type of broker may not meet all our needs. Akin to polyglot programming - picking the best language for the job - or polyglot persistence - picking the best language for the job - when using Polyglot Flow we pick the best broker for the job.
We will look at the different protocols for messaging: series and discrete and understand their different characteristics with examples in RMQ and Kafka. We will also look at the functionality that brokers may have such as dynamic routing, requeue and dead letter queues, delay queues, and consumer groups and the scenarios that we enable with them. We will look at the ecosystem that surrounds that broker, such as support for aggregation and filtering. Finally, we will consider the environment - how does running on Kubernetes impact your choice of broker?
We will then ask the question, how do you evaluate your architure's needs to determine which characteristics you need and thus what is the smallest set of brokers you can pick to meet them, without having to work around the limitations of any one broker.
By the end of the session you should be able to understand if you can survive with a monoculture, or if you need to embrace Polyglot Flow.
NDC Sydney 2024 Sessionize Event
NDC London 2024 Sessionize Event
NDC London 2023 Sessionize Event
Build Stuff 2022 Lithuania Sessionize Event
NDC Oslo 2022 Sessionize Event
Domain-Driven Design Europe 2022 Sessionize Event
NDC London 2022 Sessionize Event
NDC Porto 2022 Sessionize Event
NDC Oslo 2021 Sessionize Event
Build Stuff 2021 Lithuania Sessionize Event
NDC London 2021 Sessionize Event
Build Stuff 2020 Lithuania Sessionize Event
DDD East Midlands Limited 2019 Sessionize Event
NDC Oslo 2019 Sessionize Event
NDC Minnesota 2019 Sessionize Event
NDC Porto 2019 Sessionize Event
NDC London 2019 Sessionize Event
NDC Oslo 2018 Sessionize Event
NDC Minnesota 2018 Sessionize Event
NDC London 2018 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top