The Future of Services: Building Asynchronous, Resilient and Elastic Systems

WEBINAR

The Future of Services: Building Asynchronous, Resilient and Elastic Systems

by Jamie Allen (@jamie_allen)

@jamie_allen

Traditional application architectures and platforms are obsolete.Gartner

@jamie_allen

Reactive: The new way of building software

@jamie_allen

• Accelerate teams• Reduce dependency nightmares• Increase application throughput

What are we trying to achieve?

Calvin and Hobbes, Bill Waterston

@jamie_allen

• Size is irrelevant

“Microservices” is a lousy term

Bing Images

@jamie_allen

• At the API• In our source• For our data

We want isolation

Wikipedia, Creative Commons, created by DFoerster

@jamie_allen

We want realistic data management• Transactions, especially distributed, will not work• Consistency is an anti-pattern at scale• Synchronous updates are a fallacy• Distributed locks for replication fail• Databases and Data Fabrics break these conventions

@jamie_allen

@jamie_allen

CQRS and Event Sourcing• Command/Query Responsibility Segregation• Immutable data• Available systems lack consistency guarantees• Replayable state for failure recovery• Completely isolated

Think in terms of compensation, not prevention.Kevin Webber, Lightbend

@jamie_allen

We want to ACID v2• Associativity and Commutativity are the path to scale• Idempotent and Distributed

Wikipedia, Creative Commons, created by Weston.pace

@jamie_allen

We want real resilience• It is merely whether or not something has been handled• It is only an external view, not internal where the failure has occurred• Resilience is being able to handle the “why” in a meaningful way

• Threads• Within One Node• Across Many Nodes• Across Many Servers• Across Data Centers

@jamie_allen

We want asynchronous APIs• Synchronous request/response semantics are expensive

• REST can be asynchronous, but still heavy• Each call requires a connection• Best used for external APIs

• Stream-based interactions for inter-service communication where responses are not required

• Message-based interactions for inter-service communication where responses are required

@jamie_allen

We want immutable deployments• We can bind a build of our application to a version of our configuration and

always know what is currently running • You cannot edit configuration and keep running

Dilbert, Scott Adams

@jamie_allen

We want to expose a “tip of the iceberg”

• Users see the public API• The API hides much complexity

MyBluePuzzle.org

@jamie_allen

We want Domain Driven Design• Knowing/understanding it is not necessarily a requirement• “Solving your pain” is the most important reason for microservices• In a greenfield project, Bounded Contexts and Aggregate Roots can help you to

decompose the problem

@jamie_allen

• Proxying• Service Discovery/Gateway• Stateless aggregation• Orchestration• Failure management• Versioning

We will have additional operational complexity

Complexityandotherbeasts.com

@jamie_allen

• Service API• Persistence API• Development environment• Production environment

@jamie_allen

• Create single project definition in sbt, use runAll, includes:• In-memory Cassandra with own keyspaces• A service locator• A service gateway

• Overload Mode: recompile and redeploy on save

Development Environment

@jamie_allen

• Deployment• Monitoring• Scaling• Can test locally with ConductR then push to production• Launch multiple instances with a single command

Production Environment (Lightbend RP)

@jamie_allen

LinksProject Site:http://www.lightbend.com/lagom

GitHub Repo:https://github.com/lagom

Documentation:http://www.lagomframework.com/documentation/1.0.x/Home.html

lightbend.com/pov

Reactive RoundtableWorld Tour by Lightbend

lightbend.com/reactive-roundtable

Proof of Value ServiceAccelerate Project Success