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.

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.

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 overload our terms a lot in this industry. "Coupling" is one such. That word covers situations ranging from essential to accidental to comical to cosmic. Coupling seems to be the root of all ills. It is the molasses that slows our every move. And yet, in the industry from which we borrowed the term, "coupling" was not a dirty word. It meant something ingenious. Let us contemplate coupling for a time and see what we can do about it.

We overload our terms a lot in this industry. "Coupling" is one such. That word covers situations ranging from essential to accidental to comical to cosmic. Coupling seems to be the root of all ills. It is the molasses that slows our every move. And yet, in the industry from which we borrowed the term, "coupling" was not a dirty word. It meant something ingenious. Let us contemplate coupling for a time and see what we can do about it.

We overload our terms a lot in this industry. "Coupling" is one such. That word covers situations ranging from essential to accidental to comical to cosmic. Coupling seems to be the root of all ills. It is the molasses that slows our every move. And yet, in the industry from which we borrowed the term, "coupling" was not a dirty word. It meant something ingenious. Let us contemplate coupling for a time and see what we can do about it.

What can a rogue fighter pilot from the 1960’s teach us about software architecture? Quite a lot, as it turns out. In 1964, John Boyd introduced ””energy-maneuverability”” theory. It showed that the fastest airplane didn’t always win the dogfight. Rather, the one that could accelerate or decelerate fastest would win.

Software architecture today is about gaining and shedding mass rapidly. One must scale up and scale down, and be able to adapt quickly to changing situations. Sadly, enterprise integration destroys maneuverability more often than it helps.

As architects, we can change the way we integrate systems to produce maneuverability, via some different techniques and patterns. Some of these techniques may appear to contradict past notions of sound architecture. Our industry evolves rapidly, however, and last year’s sound practice might just be drag this year.

KEYWORDS

Architecture, Agile, Microservices, Maneuverability, Enterprise, Scale

What can a rogue fighter pilot from the 1960’s teach us about software architecture? Quite a lot, as it turns out. In 1964, John Boyd introduced ””energy-maneuverability”” theory. It showed that the fastest airplane didn’t always win the dogfight. Rather, the one that could accelerate or decelerate fastest would win.

Software architecture today is about gaining and shedding mass rapidly. One must scale up and scale down, and be able to adapt quickly to changing situations. Sadly, enterprise integration destroys maneuverability more often than it helps.

As architects, we can change the way we integrate systems to produce maneuverability, via some different techniques and patterns. Some of these techniques may appear to contradict past notions of sound architecture. Our industry evolves rapidly, however, and last year’s sound practice might just be drag this year.

KEYWORDS

Architecture, Agile, Microservices, Maneuverability, Enterprise, Scale

What can a rogue fighter pilot from the 1960’s teach us about software architecture? Quite a lot, as it turns out. In 1964, John Boyd introduced ””energy-maneuverability”” theory. It showed that the fastest airplane didn’t always win the dogfight. Rather, the one that could accelerate or decelerate fastest would win.

Software architecture today is about gaining and shedding mass rapidly. One must scale up and scale down, and be able to adapt quickly to changing situations. Sadly, enterprise integration destroys maneuverability more often than it helps.

As architects, we can change the way we integrate systems to produce maneuverability, via some different techniques and patterns. Some of these techniques may appear to contradict past notions of sound architecture. Our industry evolves rapidly, however, and last year’s sound practice might just be drag this year.

KEYWORDS

Architecture, Agile, Microservices, Maneuverability, Enterprise, Scale

Big companies can create really big software disasters. Some of the worst commercial failures have come from undersized production systems. Millions of dollars get thrown into hardware at the last minute. Just moving to the cloud doesn’t help. It lets you get the (virtual) hardware in place faster, but you still might spend a lot more than you expect for capacity. This session will present a technique for analyzing your system’s capacity–either during development or as you contemplate changes. Using these techniques could save you a lot of embarrassing downtime and your company a lot of money.

Big companies can create really big software disasters. Some of the worst commercial failures have come from undersized production systems. Millions of dollars get thrown into hardware at the last minute. Just moving to the cloud doesn’t help. It lets you get the (virtual) hardware in place faster, but you still might spend a lot more than you expect for capacity. This session will present a technique for analyzing your system’s capacity–either during development or as you contemplate changes. Using these techniques could save you a lot of embarrassing downtime and your company a lot of money.

It has been five years since Patrick Debois coined the term DevOps to describe a way of working together to deliver systems. In that time, we have rediscovered some gems from the past and we have invented new techniques and tools. In this session, we will take a look at what’s new in the world of DevOps, what’s old-but-good, and where we still need to advance.

It has been five years since Patrick Debois coined the term DevOps to describe a way of working together to deliver systems. In that time, we have rediscovered some gems from the past and we have invented new techniques and tools. In this session, we will take a look at what’s new in the world of DevOps, what’s old-but-good, and where we still need to advance.

It has been five years since Patrick Debois coined the term DevOps to describe a way of working together to deliver systems. In that time, we have rediscovered some gems from the past and we have invented new techniques and tools. In this session, we will take a look at what’s new in the world of DevOps, what’s old-but-good, and where we still need to advance.

Big companies can create really big software disasters. Some of the worst commercial failures have come from undersized production systems. Millions of dollars get thrown into hardware at the last minute. Just moving to the cloud doesn’t help. It lets you get the (virtual) hardware in place faster, but you still might spend a lot more than you expect for capacity. This session will present a technique for analyzing your system’s capacity–either during development or as you contemplate changes. Using these techniques could save you a lot of embarrassing downtime and your company a lot of money.

In this full-day workshop, you will learn how to create applications that survive the rigors of life in production. Too often, project teams aim to pass QA instead of aiming for success in production. Testing is not enough to prove that your software is ready for continuous availability in the corrosive environment of the Internet. During this workshop, you will receive an understanding of the architecture and design patterns that can produce high availability in distributed, multithreaded systems. You will also learn about the antipatterns that can sabotage your systems availability and capacity.

In this full-day workshop, you will learn how to create applications that survive the rigors of life in production. Too often, project teams aim to pass QA instead of aiming for success in production. Testing is not enough to prove that your software is ready for continuous availability in the corrosive environment of the Internet. During this workshop, you will receive an understanding of the architecture and design patterns that can produce high availability in distributed, multithreaded systems. You will also learn about the antipatterns that can sabotage your systems availability and capacity.

Architecture plans in enterprises tend to resemble late-night infomercials. First, you see a person or system that seems incapable of survival—a situation that can be immediately rectified if you just buy into the product. (One popular infomercial shows incompetent people mangling tomatoes transitioning into Ginsu-wielding sous chefs; the architecture pitch starts with hideous complexity then moves to clean orthogonal box diagrams.) Operators are always standing by.

Real architecture never reaches that blissful end state. Something always interrupts the program: businesses change, technology changes, or funding dries up. What would happen if you did reach the end state, anyway? Is IT in the company done? Of course not.

The truth is that there is no end state. We must all learn to build systems that evolve and grow. We need to stop aiming for the end state and understand that change is continuous. We cannot predict the details, but we can learn the general patterns.

Michael Nygard demonstrates how to design and architect systems that admit change—bending and flexing through time. Using a blend of information architecture, technical architecture, and some process change, Michael walks you through examples of rigid systems to show how to transform them into more maneuverable architecture.

This workshop includes both teaching and hands-on design sessions. Design sessions will be paper and whiteboard work in small groups. You’ll work on real problems drawn from a variety of industries. If you’re a developer or architect working with medium to large architectures and building applications in the context of existing systems or transitioning to new systems, this is the tutorial for you.

In this full-day workshop, you will learn how to create applications that survive the rigors of life in production. Too often, project teams aim to pass QA instead of aiming for success in production. Testing is not enough to prove that your software is ready for continuous availability in the corrosive environment of the Internet. During this workshop, you will receive an understanding of the architecture and design patterns that can produce high availability in distributed, multithreaded systems. You will also learn about the antipatterns that can sabotage your systems availability and capacity.

In this full-day workshop, you will learn how to create applications that survive the rigors of life in production. Too often, project teams aim to pass QA instead of aiming for success in production. Testing is not enough to prove that your software is ready for continuous availability in the corrosive environment of the Internet. During this workshop, you will receive an understanding of the architecture and design patterns that can produce high availability in distributed, multithreaded systems. You will also learn about the antipatterns that can sabotage your systems availability and capacity.