You are viewing content from a past/completed QCon

Presentation: From Microliths To Microsystems

Track: Architecting for Failure

Location: Fleming, 3rd flr.

Day of week: Monday

Slides: Download Slides

Level: Intermediate

Persona: Architect

Share this on:

What You’ll Learn

  • Cut through the noise and learn the considerations, tradeoffs, and risks of adopting a Microservice based architecture
  • Hear battle-tested first principles required for Microservices, including how to achieve asynchronous, autonomous, and isolated behavior.
  • Understand how to leverage the Reactive principles and event-driven coordination (and persistence) using events-first Domain Driven Design.

Abstract

Everyone is talking about microservices, and there is more confusion than ever about what the promise of microservices really means and how to deliver on it. To address this we will explore microservices from first principles, distilling their essence and putting them in their true context: distributed systems.

What many people forget is that microservices are distributed and collaborative by nature and only make sense as systems—one collaborator is no collaborator. It is in between the microservices that the most interesting and rewarding, and also challenging, problems arise—enter the world of distributed systems.

Distributed systems are by definition complex, and we system developers have been spoiled by centralized servers for too long to easily understand what this really means. Slicing an existing system into various REST services and wiring them back together again with synchronous protocols and traditional enterprise tools—designed for monolithic architectures—will set us up for failure.

As if that wasn’t enough, we can’t just think about systems of microservices. In order to make each microservice resilient and elastic in and of itself, we have to design each individual microservice as a distributed system—a «microsystem»—architected from the ground up using the reactive principles.

Question: 

QCon: Your original title had Microdisservices before you changed it to the current one. What did you mean by Microdisservices?

Answer: 

You will get Microdisservices when you approach microservices in a too simplistic way. When you do not go all in building systems with Microservices, bringing over too much preconceptions, patterns, tools and ways of thinking, learned from years building monoliths. It’s a good way to shoot yourself in the foot and get all the drawbacks from Microservices without any of the benefits. Microservices is ultimately about trade-offs, and requires very much a new way of thinking and approaching the problem. The biggest difference is that you are entering the world of distributed systems, which is a very different world compared to the monolith.

Question: 

QCon: When is the right time to choose Microservices?

Answer: 

First, Microservices are not a silver bullet. The benefits and drawbacks are extremely contextual. When you start, you need to sit down and look at what kind of application you're building. You need to ask yourself things like: how big are your teams, will it pay off to split up into different teams, does it make sense to ship services independently, etc. Those types of things need to be answered before making the decision to move into a Microservice-based architecture.

Question: 

QCon: Who is the target audience for your talk on ‘From Microliths to Microsystems’.

Answer: 

The target Audience is senior engineers and architects.

Question: 

QCon: What do you want someone to leave your talk with?

Answer: 

I want engineers to leave with an understanding of what it takes to be successful with Microservices (from an architecture and design perspective). I want them to leave knowing how to build “systems” of Microservices that can take full advantage of the Cloud, and how to build “systems” that are inherently elastic and resilient. Finally, I want engineers who attend to learn how to leverage the Reactive principles, Event-driven coordination (and persistence) using Events-first Domain Driven Design.

Speaker: Jonas Bonér

Founder & CTO @Lightbend / Creator of Akka

Jonas Bonér is Founder and CTO of Lightbend, inventor of the Akka project, initiator and co-author of the Reactive Manifesto, and a Java Champion. Learn more at http://jonasboner.com.

Find Jonas Bonér at

Last Year's Tracks