The Future of Services: Building Asynchronous, Resilient and Elastic Systems
Transcript of The Future of Services: Building Asynchronous, Resilient and Elastic Systems
![Page 1: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/1.jpg)
WEBINAR
The Future of Services: Building Asynchronous, Resilient and Elastic Systems
by Jamie Allen (@jamie_allen)
![Page 2: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/2.jpg)
@jamie_allen
Traditional application architectures and platforms are obsolete.Gartner
![Page 3: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/3.jpg)
@jamie_allen
Reactive: The new way of building software
![Page 4: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/4.jpg)
@jamie_allen
• Accelerate teams• Reduce dependency nightmares• Increase application throughput
What are we trying to achieve?
Calvin and Hobbes, Bill Waterston
![Page 5: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/5.jpg)
@jamie_allen
• Size is irrelevant
“Microservices” is a lousy term
Bing Images
![Page 6: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/6.jpg)
@jamie_allen
• At the API• In our source• For our data
We want isolation
Wikipedia, Creative Commons, created by DFoerster
![Page 7: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/7.jpg)
@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
![Page 8: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/8.jpg)
@jamie_allen
![Page 9: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/9.jpg)
@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
![Page 10: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/10.jpg)
@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
![Page 11: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/11.jpg)
@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
![Page 12: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/12.jpg)
@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
![Page 13: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/13.jpg)
@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
![Page 14: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/14.jpg)
@jamie_allen
We want to expose a “tip of the iceberg”
• Users see the public API• The API hides much complexity
MyBluePuzzle.org
![Page 15: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/15.jpg)
@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
![Page 16: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/16.jpg)
@jamie_allen
• Proxying• Service Discovery/Gateway• Stateless aggregation• Orchestration• Failure management• Versioning
We will have additional operational complexity
Complexityandotherbeasts.com
![Page 17: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/17.jpg)
@jamie_allen
• Service API• Persistence API• Development environment• Production environment
![Page 18: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/18.jpg)
@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
![Page 19: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/19.jpg)
@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)
![Page 20: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/20.jpg)
@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
![Page 21: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/21.jpg)
lightbend.com/pov
Reactive RoundtableWorld Tour by Lightbend
lightbend.com/reactive-roundtable
Proof of Value ServiceAccelerate Project Success
![Page 22: The Future of Services: Building Asynchronous, Resilient and Elastic Systems](https://reader030.fdocuments.in/reader030/viewer/2022020301/586fce0c1a28aba24c8b76d5/html5/thumbnails/22.jpg)