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.

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.

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.

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.

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.