Presentation: Design Microservice Architectures the Right Way
This presentation is now available to view on InfoQ.com
Watch videoWhat You’ll Learn
- Understand from first-hand experience the many critical decisions you make in designing your microservice architecture.
- Learn first hand what decisions are critical; and which will lead to paralyzing technical debt over time.
- Hear a step by step use case of building a successful microservice platform with all the critical points along the way.
Abstract
Learn from first hand, deep experience, the most critical decisions we face in building successful microservice architectures: how to think about the tradeoffs that impact the productivity of our teams and the quality of our software. In particular, understand how to avoid creating an architecture that eventually (and sometimes quickly) paralyzes our ability to execute. This talk highlights specific key decisions that very directly impact the quality and maintainability of a micro service architecture, covering infrastructure, continuous deployment, communication, event streaming, language choice and more, all to ensure that our teams and systems remain productive as we scale.
Can you give us a teaser of what to expect in this talk?
We will go step by step and talk about the investment needed to run a successful microservice platform, touching on everything from contracts, events, data structure, shared libraries, deployment, isolation, monitoring, etc.
Our primary thesis is to reinforce that a microservice architecture requires significant investment (as do all architectures) to be successful - and then to drive home a few points: microservice != polyglot, importance of continuous delivery and high-quality dev tools, and the usefulness of isolation as a core strategy to manage risk while scaling teams.
What is the level of experience someone attending this talk should have?
Approachable for all; probably most useful for people thinking about creating a microservice architecture or who are suffering from the consequences of a poorly design distributed monolith.
Similar Talks
Scaling DB Access for Billions of Queries Per Day @PayPal
Software Engineer @PayPal
Petrica Voicu
Psychologically Safe Process Evolution in a Flat Structure
Director of Software Development @Hunter_Ind
Christopher Lucian
PID Loops and the Art of Keeping Systems Stable
Senior Principal Engineer @awscloud
Colm MacCárthaigh
Are We Really Cloud-Native?
Director of Technology @Luminis_eu
Bert Ertman
The Trouble With Learning in Complex Systems
Senior Cloud Advocate @Microsoft
Jason Hand
How Did Things Go Right? Learning More From Incidents
Site Reliability Engineering @Netflix
Ryan Kitchens
What Breaks Our Systems: A Taxonomy of Black Swans
Site Reliability Engineer @Slack, Contributor to Seeking SRE, & SRECon Steering Committee
Laura Nolan
Cultivating High-Performing Teams in Hypergrowth
Chief Scientist @n26
Patrick Kua
Inside Job: How to Build Great Teams Within a Legacy Organization?
Engineering Director @Meetup