Self-contained Systems: A Different Approach to Microservices

This presentation discusses approaches to Microservices - including self-contained systems and their benefits and trade-offs.

1. Self-contained Systems: A Different Approach to Microservices
2. http://continuous-delivery-buch.de/
3. http://microservices-buch.de/ http://microservices-book.com/
4. http://microservices-book.com/primer.html FREE!!!!
5. Microservice Definition
6. Server Server Microservices: Definition > Independent deployment units > Any technology > Any infrastructure > UI + Logic Micro Service Micro Service
7. Components Collaborate Micro Service Micro Service Link Data Replication REST Messaging
8. Distributed System
9. Distributed System Why??
10. Why Microservices? Strong Modularization Scaling Agile Sustainable development Replaceable Services Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Small teams develop and deploy independently Add services – not code Small Services Failure limited to single Microservice
11. Why Microservices? Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology
12. Single Developer Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology
13. Replace Monolith Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology
14. How should I build my system?
15. Layered iOS Android Web Order Search Catalog Billing Customer Backend Backend Backend
16. Layered > Reusable Backend Services > Mobile client / Web App as frontend > Backend for frontend (BFF): Custom backend services > ...to implement frontend specific logic > E.g. Netflix
17. Layered: Benefits > Good way to build an API > E.g. for mobile > Might be easier to migrate into > …if existing architecture is similar
18. Layered: Issues > BFF might contain the same logic – same processes > BFF might contain most relevant logic > Change to a business process means changing many services > Lots of communication
19. Self-Contained System (SCS)
20. Deployment monolith Graphics by Roman Stranghöhner, innoQ http://scs-architecture.org
21. Various Domains
22. User interface Business logic Persistence
23. … a lot of modules, components, frameworks and libraries
24. With all these layers in one place, a monolith tends to grow.
25. Cut Deployment monolith along domains …
26. … wrap domain in separate web application …
27. Self-contained System (SCS) – individually deployable
28. Decentralized unit communicating with other systems via RESTful HTTP or lightweight messaging.
29. SCS can be individually developed for different platforms.
30. An SCS contains its own user interface, specific business logic and separate data storage
31. optional API e.g. for mobile
32. Logic only shared over a well defined interface.
33. Business logic can consist of microservices
34. Every SCS brings its own data storage with its own (potentially redundant) data
35. Redundancies: tolerable as long as sovereignty of data by owning system is not undermined.
36. Enables polyglot persistence Neo4J CouchDB Oracle
37. Technical decisions can be made independently from other systems (programming language, frameworks, tooling, platform)
38. Domain scope enables development, operation and maintenance of SCS by a single team. Team 1 Team 2 Team 3
39. Web user interface composed according to ROCA principles. http://roca-style.org
40. Self-contained Systems should be integrated in the web interface
41. Hyperlinks to navigate between systems. System 1 System 2
42. System 1 System 2 Redirection > Use of callback URIs > As seen e.g. in OAuth flows
43. Dynamic inclusion of content served by another application System 1 System 2
44. https://www.innoq.com/ de/blog/transklusion/
45. ESI (Edge Side Includes) ... <div> ... a lot of static content and images ... </div> ... ... <header> ... Logged in as: Ada Lovelace ... </header> <div> some dynamic content </div>
46. ESI (Edge Side Includes) ... <div> ... a lot of static content and images ... </div> ... ... <esi:include src="http://example.com/header" /> <esi:include src="http://example.com/dynamic" /> http://www.w3.org/TR/esi-lang
47. Client-side Integration: Code $("a.embeddable").each(function(i, link) { $("<div />").load(link.href, function(data, status, xhr) { $(link).replaceWith(this.children); }); }); > Replace <a href= " " class= "embeddable"> with content of document in a <div> (jQuery)
48. Synchronous remote calls inside the business logic should be avoided.
49. Asynchronous Remote calls reduce dependencies and prevent error cascades.
50. Data model’s consistency guarantees are relaxed.
51. An integrated system of systems like this has many benefits.
52. Resilience is improved through loosely coupled, replaceable systems.
53. SCSs can be individually scaled to serve varying demands.
54. No risky big bang to migrate an outdated, monolithic system into a system of systems. Version 1 Version 2
55. Migration in small, manageable steps which minimize risk of failure and lead to an evolutionary modernization of big and complex systems.
56. 1 *Microservice SCS
57. Conclusion > SCS: autonomouos web application > Might consist of Microservices > Focus on UI Integration > Almost completely independent > Coarse-grained architecture approach
58. Conclusion > Self-contained systems are Microservices … > that are not “micro”… > and don’t have to be “services” > Many are doing it already!
59. > http://scs- architecture.org > Creative commons > Source on Github > Slidedeck