Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Architecture as Systems Dissolve

755 views

Published on

The way we build systems is changing. From our history of monolithic systems, then distributed systems, to Internet connected systems, we are now entering the era of cloud-hosted, microservice based, pay-for-usage system development. What does the history of software architecture tell us about the challenges of this new environment? And how does our approach to software architecture need to evolve in order to meet them?

Software architecture has been a mainstream discipline since the 1990s and in that time has become a recognised, widely researched and often valued part of the software engineering process. However architecture approaches must reflect the technologies and priorities of the systems we are building and in this regard its future has never looked more uncertain or more exciting. From our history of monolithic compile time architecture, to many tiered distributed systems, to Internet connected services, we are now entering the era of cloud-hosted, microservice-based, pay-for-usage systems development. In this new world the boundaries of “my” system are no longer so clear and our systems are dissolving into complex webs of independently owned and evolved services, with nothing more in common than a shared credit card for billing and an agreement on the format of network requests. What can the history of software architecture tell us about the likely challenges in this environment? And how must it develop in order to meet them?

This version of the talk was presented at GOTO London in October 2016.

Published in: Software
  • Be the first to comment

Software Architecture as Systems Dissolve

  1. 1. SOFTWARE ARCHITECTURE AS SYSTEMS DISSOLVE 
 GOTO London 2016 Eoin Woods - Endava
 @eoinwoodz
  2. 2. BACKGROUND • Eoin Woods • CTO at Endava (technology services, 3300 people) • 10 years in product development - Bull, Sybase, InterTrust • 10 years in capital markets applications - UBS and BGI • Software engineer, then architect, now CTO • Author, editor, speaker, community guy
  3. 3. SYSTEMS ARE DISSOLVING!
  4. 4. 5 AGES OF SOFTWARE SYSTEMS Intelligent
 Connected
 (2020s) Internet
 is the System
 (2010s) Internet
 Connected
 (2000s) Distributed
 Monoliths
 (1990s) Monolithic
 (1980s)
  5. 5. OUR HISTORY
  6. 6. MONOLITHIC • Structuring of computer programs • Algol, FORTRAN, COBOL,Assembler, Pascal, … • Fundamentals of modularisation • information hiding, composition, concurrency • Dahl, Dijkstra, Hoare, Jackson, Knuth, Nygaard, Zave • Architecture is largely a vendor concern
  7. 7. DISTRIBUTED MONOLITHS • Clients + Servers + Databases • “Batch” ➡“Online” • Software architecture emerges • basic thinking, first conference, early academic interest • Architectural style (C/S) now the vendor concern
  8. 8. INTERNET CONNECTED • Distributed monoliths web UIs connected to the Internet • new (unknown) non-functional demands • “Online” ➡“Always On” • Explosion of interest in software architecture • books, methods, conferences, NFR focus, styles & patterns, viewpoints • Vendors concerned with achieving non-functionals • firewalls for security, big servers for scalability, …
  9. 9. CURRENT ERA
  10. 10. INTERNET ASTHE SYSTEM • Public API and mobile UI are the default interfaces • “Always On” ➡ “Access from Anywhere” • More dynamic architectural styles emerge • Microservices become popular • Vendor concern now providing “platforms” (PaaS)
  11. 11. ARCHITECTURAL DRIVERS Constant Competition => Continuous Development & 100% Uptime Unknown Users => Measurement of Behaviour Unpredictable Demand => Dynamic Response to Load Part of the Internet => Consumable by Systems Visible from Anywhere => Constant AttackThreat Accessed Globally => Compliant Everywhere!
  12. 12. I-A-T-S PRINCIPLES • Evolve continually • Respond dynamically • Analyse don’t ask • APIs for everything • Secure by Design • Internationalise instinctively
  13. 13. IMPLICATIONS (1) • Design in CD from the start • remove obstacles to automation, testing, deployment • Allow modular evolution • bounded contexts,“micro services” • Assume “cloud” deployment • “cattle not pets”, no “snowflakes”, no static config, … Also see the 12factor.net advice
  14. 14. IMPLICATIONS (1) • Design in CD from the start • remove obstacles to automation, testing, deployment • Allow modular evolution • bounded contexts,“micro services” • Assume “cloud” deployment • “cattle not pets”, no “snowflakes”, no static config, … Also see the 12factor.net advice 1. One codebase tracked in revision control, many deploys 2. Explicitly declare and isolate dependencies 3. Store config in the environment 4. Treat backing services as attached resources 5. Strictly separate build and run stages 6. Execute the app as one or more stateless processes 7. Export services via port binding 8. Concurrency scale out via the process model 9. Disposability by maximising robustness (startup, shutdown) 10. Dev/Prod Parity by aligning development, staging, and prod 11. Treat logs as event streams 12. Run admin/management tasks as one-off processes
  15. 15. IMPLICATIONS (2) • Provide measurement in the core • instrumentation, store, analytics engine • Structure around “public”APIs • the “Amazon” pattern • Design and build to be securable • security principles, threat models, scanning, …
  16. 16. ONTHE FUTURE
  17. 17. INTELLIGENT CONNECTED • Data and algorithms become key to achieving architectural qualities • Architecture becomes (more) runtime emergent • Vendor concern moves to “intelligent behaviour” • “Access from Anywhere” ➡“Intelligent Assistance” Our future as software architects …
  18. 18. INTELLIGENT CONNECTED Less More Structural Design Data and Algorithm Design Defined Structure Emergent Structure Decisions Principles, Policies,Algorithms Certainty Probability Operational Processes Operational Policy & Automation Capex Opex How will it affect software architects?
  19. 19. CONCLUSIONS • Our past can point to the future • Monolithic led to structures • Distributed Monoliths led to software architecture • Internet Connected systems brought software architecture mainstream • Each era develops the practice needed to meet its challenges
  20. 20. CONCLUSIONS • Internet as the System needs some specific software architecture practice too: - Continuous Delivery - Measure and Analyse Built In - Modular Evolution - Public APIs for everything - Cloud Enabled - Secure by Design • How we should be enabling all our systems today
  21. 21. CONCLUSIONS • New in the Intelligent Connected systems era? - Data and algorithms are back - Architecture via principles, policies and patterns - Operation at huge varying scale (again policy based) - New economics of systems • This is what we need to know to be ready
  22. 22. THANKYOU … QUESTIONS? Eoin Woods
 Endava
 eoin.woods@endava.com @eoinwoodz

×