Ian Cooper
Coding architect, pierced, bearded, tattooed
London, United Kingdom
Actions
Polyglot Coding Architect in London, founder of #ldnug, speaker, tabletop gamer, geek. Tattooed, pierced, and bearded. The 'guv' on @BrighterCommand
Badges
Area of Expertise
Topics
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.
Using AsyncAPI To generate code
AsyncAPI allows us to describe our messaging endpoints so that we can document our Messaging and Event APIs for others, but AsyncAPI can be used for more than this: it allows us to generate code from that definition. At the simple level, this is how we generate HTML documentation, but there are a wider range of use cases:
- We can use AsyncAPI to scaffold our application, allowing us to build our API contract-first then generate the matching code for both our producers and consumers.
- We can use AsyncAPI to register our message schemas with a registry for validation, allowing us to be strict about what we send (or receive).
- We can use AsyncAPI to create the infrastructure that we need for messaging such as topics, queue and their permissions.
Derived from how we use AsyncAPI day-to-day for these tasks at Just Eat Takeaway, in this talk we will build simple versions of our tools that demonstrate how to generate code from your AsyncAPI definitions in C#, JavaScript and Go to fulfil the above use cases.
As a result of this talk you should understand code generation from AsyncAPI and how to provide added value to your developers from their AsyncAPI definitions, encouraging the spread of AsyncAPI within your organisation.
TDD Rediscovered
The practice of TDD has diverged from its roots. The techniques that Kent Beck documented and has taught, differ from those that many struggle with today. As a result, tests slow down development, hamper rather than aid refactoring, and force terms like unit, integration, and acceptance into a practice that never had them, with disastrous results.
In this workshop we want to re-discover the practice of TDD as originally envisaged by Kent Beck. We will seek to understand:
Why tests are about behavior not structure.
Why adhering to Red-Green-Refactor makes tests cheap to write in comparison to the code they cover.
Why we test abstractions, not details.
Why tests should be easy to read, and how we achieve that.
When and how we refactor.
Why 'driving in gears’ is a concept that is not practiced enough.
How design patterns can be used for good, as part of our TDD practice.
We will also understand why you might not value TDD as many subsequent interpreters have communicated it, and how you can grow to love it in its intended form.
But most of all we hope to show that the original practice of TDD was not the onerous make-work it has become at the hands of considerable misunderstandings, but ‘greases the wheels’ of software development.
We will use Python for demos during this presentation, but the focus of this course will be on basics that can be applied in any language. You will do exercises in a language of your choice
Responsibility Driven Design Revisited
How do we use objects to model a domain? Whilst Domain Driven Design (DDD) exhorts its practitioners to focus on the domain, it is surprisingly sparse on how we should accomplish that, other than a few patterns whose job is to abstract away concepts that live outside of that domain. What though of the domain model?
In Domain Driven Design, Eric Evans is explicit that it relies on usage of Rebecca Wirfs-Brock's Responsibility Driven Design (RDD), which sees allocation of responsibilities as the key technique for splitting our system into co-operating objects.
Despite this, many developers who are aware of DDD, know little about RDD. In this talk we aim to set that right with a journey into RDD. In an example-driven talk we will work through analysing a domain using RDD, explaining key techniques such as CRC cards for modelling the domain. Along the way, we will explain key concepts like responsibilities, roles, object stereotypes, and control styles.
Finally, we will ask how RDD fits into our current approaches to software development. We will re-explore its relationship to DDD and look at how techniques like TDD can be used to help us uncover responsibilities, roles and collaborators.
Practical Messaging
In this tutorial, we will look at distributed systems, and how we integrate them. We will understand why we would prefer to integrate via messaging, the fundamentals and key concepts of messaging and how to build an event driven architecture.
If you have ever been put off moving from HTTP or RPC-based solutions to messaging because of the need to learn how to implement messaging-based solutions, this workshop will get you started.
If you have been using messaging but want to gain a firmer understanding of how to build event driven architectures, this workshop will help you understand how to succeed with reactive approaches.
The material is presented in two parts: an introduction to using messaging middle-ware (including hands-on exercises in RabbitMQ and Kafka) and the fundamentals of how we construct event driven architectures.
Hands-on exercises are offered in C#, Java, JavaScript, Python and Go.
Topics covered will include:
Day 1: Messaging
- Distribution
- Integration Styles
- Messaging Patterns
- Queues and Streams
- Managing Asynchronous Architectures
Day 2: Conversations
- Flow
- Process Automation
- Control Flow
- Activities
Modern Observability and Event Driven Architectures
Flow is a key property of event driven systems and yet understanding flow through a distributed system is notoriously hard. This manifests in how we think about flow: “what path does this operation take through the system” or “what message entering this component led to another message leaving this component” or even “why did this flow take the fault path”. This goes further into how we think about resolving errors like “in which component did this flow error and why”
Traditional approaches like logging inevitably create more noise than signal when we try to observe flow across components, and other methods like intercepting messages using a wiretap have limited effectiveness in telling us “why” something happened. Both of these techniques often create as many questions as they answer.
In this talk we look at how utilising modern observability techniques can help you to understand the flow of your event driven system.
We’ll cover different techniques for modelling your telemetry and look at the Semantic Conventions for Messaging. We’ll discuss how using standardised naming helps us provide trusted signal data, as opposed to the noise. We will look at the W3C Trace Context standards, and understand how this gives us a view of flow within our system along with live demos on how to make it all work together
With examples in C# and JavaScript throughout we will show you different approaches to observing the flow of your system, and their trade-offs. We will show a range of middleware transports including Azure Service Bus and Kafka
Managing Event Driven Architectures
When you scale event driven architectures, your ability to keep the model of how you use events 'in your head' collapses and you need to move towards more formality in how you manage your events.
- How do you discover event APIs? Who publishes, who subscribes? What do the fields on the message mean?
- How do you gain an understanding of the flows of messages in your system for choreography?
- How do you manage the infrastructure associated with events such as topics, queues, access controls?
- How do you manage the versioning of events and ensure you do not break consumers?
In this session we will examine these questions and more. We will look at the use of emerging standards such as AsyncAPI and CloudEvents to document our event based APIs, how they can help us generate code to manage the required infrastructure, how they can help us to understand the flow of events within our systems and how they can help us scaffold new applications. We will demo an end-to-end usage of AsyncAPI to define our APIs, scaffold the code required, and deploy the necessary infrastructure to run.
Kafka for .NET Developers
Kafka is a low-latency streaming solution with a rich ecosystem of tools but is less well-known to .NET developers.
In this workshop we will introduce Kafka, explaining the mysteries of records, offsets, SerDes and schema registries, in-sync replicas, partitions and tools like Redpanda Connect.
We will work on a series of examples in .NET building a messaging solution for your applications.
By the end of this workshop you should feel comfortable with the concepts required to use Kafka as a .NET developer (or even Azure Event Hubs via the Kafka client).
Agile Software Architecture
We don't need no stinking architects! Martin Fowler famously declared that architects and software architecture as a practice was dead, and those of us who work as architects have been justifying our existence ever since.
In this talk, I hope to bust some myths and answer some questions
What is software architecture? How is it changed in an agile software development environment? Do we do it at all in agile, or is that just the anti-pattern of Big Design Up Front.
What is the role of architecture in agile software development methodologies like XP and Crystal? Who fulfills that role?
If we want to practice agile architecture, as opposed to other forms of architecture what is required for that to happen?
Finally, how should someone who is an architect spend their time in order to help a team succeed.
Level: Intermediate
At Least Once
We want to ensure that all parties to a transaction are consistent. In a distributed system two-phase commit becomes a barrier to scaling. Instead we rely on eventual consistency. But for an even driven architecture, what does "relying on eventual consistency" mean in practice?
Drawing on Pat Helland's paper "Life Beyond Distributed Transactions", in this presentation we will look at:
- The two approaches we can take towards ensuring eventual consistency: choreography and orchestration, and the trade off between them.
- Why asynchronous approaches are more reliable.
- What to do if things go wrong or compensation, and the different strategies we have from retry to reservation.
- How we deal with stale data.
- Why we can only ever promise "at least once", and how we offer "at least once."
Finally, we will demo the Outbox, using the .NET OSS library Brighter and EF Core, to show how you can ensure "at least once".
Automating Business Processes
The problem space for software is often the automation of a business process - everything from obtaining a quote for insurance to purchasing food from a grocery. Often we understand and resolve these problems in ad-hoc fashion. In this talk we deep dive into the analysis, design and execution of business processes. Along the way we will over thorny topics like orchestration, choreography, routing slips and sagas.
First, we will look at working with your customers to discover their use cases and associated business processes. We will cover value stream mapping, event storming, but particularly domain storytelling as a way to discover your customer's business processes. Then we will dip down into tools like BPMN or Service Blueprints, to see how we model the processes that we have discovered.
Then, we will look at how we create solutions to automate these processes. We will consider your implementation options from embedded workflow engines (which may be as simple as a bespoke state machine or pipes and filters architecture) through to external workflow engines like AWS Step Functions and Azure Logic Apps.
By the end of this talk you should feel comfortable understanding how to identify, model, and automate your organisations business processes..
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.
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.
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.
The Emissary
Twenty years ago, Pat Helland identified three key patterns in autonomous computing: fiefdoms, collaborations, and emissaries. While fiefdoms have been explored via SOA and microservices and collaborations through workflows and sagas, less has been said about emissaries. Yet emissaries answer an essential question—how do you use a service? At its simplest level, the emissary is an SDK or UI, but this lens of external consumption misses the other value of the emissary within your architecture and not outside it.
From DDD, we learn about the bounded context as the boundary of ubiquitous language. However, our language bleeds out of our context into others without attention to context mapping. Eric Evans points out that microservices may not be single bounded contexts, separating out the ideas of their Internal Context from their Interchange Context.
In this talk, we look at the Emissary as an example of how we can implement an Interchange Context that reduces the bleed of language across contexts.
As specific examples, we will look at:
- Using Reference Data via ECST to build a forward cache and prevent the need for an HTTP GET between services, and how we can use the emissary pattern to avoid bleeding our domain details along with that reference data.
- The problem of ACID transactions that span service boundaries and how an emissary can allow you to run another service's code to prevent needing to distribute within that transaction.
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