Download as PDF, PPTX
Uploaded byEberhard Wolff
Self-contained Systems: A Different Approach to Microservices
Self-contained systems (SCS) represent an approach to microservices, focusing on autonomous web applications that integrate their own data, logic, and user interface without shared code. They allow for independent development, deployment, and scaling, reducing communication overhead and making changes localized to specific systems. This approach aims for robustness and agility, enabling teams to manage individual components while minimizing risks associated with large-scale migrations from monolithic architectures.
More Related Content
Similar to Self-contained Systems: A Different Approach to Microservices
Self-contained Systems: A Different Approach to Microservices
- 1. Self-contained Systems: A Different Approachto Microservices
- 2.
- 3.
- 4.
- 5.
- 6. Server Server Microservices: Definition >Independent deployment units > Any technology > Any infrastructure > UI + Logic Micro Service Micro Service
- 7.
- 8.
- 9.
- 10. Why Microservices? Strong Modularization ScalingAgile 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 Sustainabledevelopment Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology
- 12. Single Developer Scaling Agile Sustainabledevelopment Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology
- 13. Replace Monolith Scaling Agile Sustainabledevelopment Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology
- 14. Layered iOS Android Web OrderSearch Catalog BillingCustomer Backend Backend Backend
- 15. Layered > Reusable BackendServices > Mobile client / Web App as frontend > Backend for frontend (BFF): Custom backend services > ...to implement frontend specific logic > E.g. Netflix
- 16. Layered: Benefits > Goodway to build an API > E.g. for mobile > Might be easier to migrate into > …if existing architecture is similar
- 17. Layered: Issues > BFFmight contain the same logic – same processes > Processes are the most relevant logic > Changing a business process cause changes in many services – BFF, Frontend, backend > Lots of communication between teams and components
- 18.
- 19. Self-contained Systems (SCS) > SCS:Autonomous web application > Optional service API (e.g. for mobile clients) > Includes data & logic > Might contain several microservices > No shared UI > No shared business code > E.g. Otto, Kaufhof, Kühne + Nagel ...
- 20. SCS: Benefits > Businesslogic for one domain in one SCS > Change usually local to one SCS > Less communication between SCS > I think this should be the goal
- 21.
- 22. Deployment monolith Graphics by RomanStranghöhner, innoQ http://scs-architecture.org
- 23.
- 24.
- 25. … a lotof modules, components, frameworks and libraries
- 26. With all these layersin one place, a monolith tends to grow.
- 27.
- 28. … wrap domainin separate web application …
- 29.
- 30. Decentralized unit communicating with othersystems via RESTful HTTP or lightweight messaging.
- 31. SCS can be individually developedfor different platforms.
- 32. An SCS containsits own user interface, specific business logic and separate data storage
- 33. Web user interface composedaccording to ROCA principles. http://roca-style.org
- 34. optional API e.g.for mobile
- 35. Logic only sharedover a well defined interface.
- 36. Business logic can consistof microservices
- 37. Every SCS bringsits own data storage with ist own (potentially redundant) data
- 38. Redundancies: tolerable as longas sovereignty of data by owning system is not undermined.
- 39.
- 40. Technical decisions can bemade independently from other systems (programming language, frameworks, tooling, platform)
- 41. Domain scope enables development, operation and maintenanceof SCS by a single team.Team 1 Team 2 Team 3
- 42. Self-contained Systems should be integrated inthe web interface
- 43. Hyperlinks to navigatebetween systems. System 1 System 2
- 44. System 1 System2 Redirection > Use of callback URIs > As seen e.g. in OAuth flows
- 45. Server-side integration > Centralizedaggregation > Bottleneck (runtime/development time) Browser UI 1 UI 2 Frontend Server Backend 1 Backend 2
- 46.
- 47. Client-side integration > Proprietaryintegration > Client requirements (e.g. CORS, JS) > Upcoming: HMTL Imports Browser UI 1 UI 2 Backend 1 Backend 2
- 48. Client-side Integration: Code $("a.embeddable").each(function(i, link){ $("<div />").load(link.href, function(data, status, xhr) { $(link).replaceWith(this); }); }); > Replace <a href= " " class= "embeddable"> with content of document in a <div> (jQuery)
- 49.
- 50. Synchronous remote calls insidethe business logic should be avoided.
- 51. Asynchronous Remote calls reduce dependenciesand prevent error cascades.
- 52.
- 53. An integrated system ofsystems like this has many benefits.
- 54. Resilience is improved throughloosely coupled, replaceable systems.
- 55. SCSs can be individually scaledto serve varying demands.
- 56. No risky bigbang to migrate an outdated, monolithic system into a system of systems. Version 1Version 2
- 57. Migration in small,manageable steps which minimize risk of failure and lead to an evolutionary modernization of big and complex systems.
- 58.
- 59. Conclusion > SCS: autonomouosweb application > Might consist of Microservices > Focus on UI Integration > Almost completet independence > Coarse-grained architecture approach
- 60. Conclusion > Self-contained systemsare Microservices … > that are not “micro”… > and don’t have to be “services” > Many are doing it already!
- 61. > http://scs- architecture.org > Creativecommons > Source on Github > Slidedeck