Chris Richardson is a developer and architect. He is a Java Champion, a JavaOne rock star and the author of POJOs in Action, which describes how to build enterprise Java applications with frameworks such as Spring and Hibernate. Chris was also the founder of the original CloudFoundry.com, an early Java PaaS for Amazon EC2.
Today, he is a recognized thought leader in microservices and speaks regularly at international conferences. Chris is the creator of Microservices.io, a pattern language for microservices, and is the author of the book Microservices Patterns. He provides microservices consulting and training to organizations that are adopting the microservice architecture and is working on Eventuate, which is an open-source microservices collaboration platform.
In order to thrive in today’s volatile and uncertain world, businesses needs to innovate at a much faster pace. Recognizing this, IT organizations are adopting the principles and practices of DevOps and the organizational patterns defined by Team Topologies. But while DevOps and Team topologies are vital for delivering the fast flow of changes that today’s businesses need, they are insufficient. To prevent applications from becoming obstacles to rapid change, IT must also create architectures that support fast flow.
In this full day workshop, I describe the architectural requirements that enable DevOps and Team Topologies to deliver a fast flow of changes. You will learn about the forces that shape an architecture and the trade-offs that you will need to make when designing an architecture. I show how to decide between the monolithic and microservice architectural styles. You will learn key monolithic architecture patterns for fast flow. I describe how to design a microservice architecture.
The microservice architecture has become increasingly popular over the past decade. Its key benefits include significantly improving the developer experience and accelerating software delivery. Sadly, however, microservices have often been widely misunderstood and used inappropriately. As a result, many organizations have struggled to benefit from their adoption. I’ve had numerous conversations where developers have complained that their new microservices-based applications are difficult to change.
In this presentation, I describe 11 development and architecture rules (a.k.a. best practices) that should prevent an organization from making a mess of its microservice architecture. I say should because given semantic diffusion and the incredible ability of many organizations to misinterpret and misapply rules, there are no guarantees. However, I believe that if an organization follows these rules when adopting microservices, it will increase their chance of success.