Mastering Microservices

Microservices has emerged as both a popular and powerful architecture, yet the promised benefits overwhelmingly fail to materialize. Industry analyst, Gartner, estimates that “More than 90% of organizations who try to adopt microservices will fail…” If you hope to be part of that successful 10%, read on…

Why is the failure rate so high?

Succeeding with microservices requires optimizing for organization-level goals with all teams “rowing in the same direction” which is easier said than done. While the microservices architecture may have been well-defined at some point in history, today the word “microservices” is used as an umbrella to refer to a vast and diverse set of coarse-to-fine grained distributed systems. In short, thanks to the phenomenon of semantic diffusion, the term “microservices” means many different things to many different people.

The promised benefits of microservices (e.g. extremely high agility, scalability, elasticity, deployability, testability, evolvability, etc.) are achieved through a highly contextual hyper-optimization of both the logical architecture of the system as well as optimization of technical practices, tooling, and the organization itself. Operating based on someone else's reference architecture (optimized for their problem space, not yours) or attempting to apply the architectural topology without the necessary team and process maturity is often just laying the foundation for yet another microservice mega disaster.

There simply is no one-sized-fits-all approach to component granularity, optimal inter-service communication, data granularity, data replication and aggregation, minimizing or managing distributed transactions, asynchronous event orchestration or choreography, technology and platform selection/management, along with so many more decisions that are highly contextual. In short, adopting this architecture requires correctly making hundreds of decisions on a path that is fraught with traps and landmines. This is one of the hardest architectures to execute well. In markets with ever-increasing competitiveness, slow and costly trial-and-error is untenable.

Mastering Microservices

Mastering microservices requires that architects and developers understand the numerous tradeoffs (and their consequences) to arrive at an architecture that is both in-reach of the development teams and organization as well as capable of delivering the promised (and often necessary) -illities. This requires deep understanding of the terrain the architect will be exploring, extensive hands-on practice, and the latest tools, patterns, and practices; all of which this workshop is designed to deliver.

If you or your organization hopes to venture down this path, or if you already have but the organization and system is struggling to deliver necessary -illities, or if you just want to have a better understanding of the complex yet powerful architecture category; this workshop is for you.

To maximize your learning experience, seats are very limited. Register today for this live, hands-on, three-day workshop!

About Michael Carducci

Michael Carducci spent years learning to see things as they actually are; first as a magician, then as a software architect, now as both simultaneously. And somehow that’s not even the whole story.

He’s the author of Mastering Software Architecture (Apress, 2025) and is currently writing The Semantic Layer. He has spent over 25 years following interesting problems; through roles from individual contributor to CTO and back again, across industries and continents.

As a speaker, he applies the same toolkit he uses in close-up magic: attention, misdirection, timing, storytelling, and the instinct to take the long way around when that’s where the truth lives. Audiences at hundreds of conferences across four continents have described his talks as the kind that change how you think about a problem rather than just what you know about it.

He also makes YouTube videos about technology and curiosity with his wife Kate, because some ideas are too important (or too interesting!) to leave only in conference rooms.

More About Michael »