Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Architecture as Systems Dissolve

Eoin Woods
October 13, 2016

Software Architecture as Systems Dissolve

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?

Eoin Woods

October 13, 2016
Tweet

More Decks by Eoin Woods

Other Decks in Technology

Transcript

  1. SOFTWARE ARCHITECTURE
    AS SYSTEMS DISSOLVE

    GOTO London 2016
    Eoin Woods - Endava

    @eoinwoodz

    View Slide

  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

    View Slide

  3. SYSTEMS ARE DISSOLVING!

    View Slide

  4. 5 AGES OF SOFTWARE SYSTEMS
    Intelligent

    Connected

    (2020s)
    Internet

    is the System

    (2010s)
    Internet

    Connected

    (2000s)
    Distributed

    Monoliths

    (1990s)
    Monolithic

    (1980s)

    View Slide

  5. OUR HISTORY

    View Slide

  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

    View Slide

  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

    View Slide

  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, …

    View Slide

  9. CURRENT ERA

    View Slide

  10. INTERNET AS THE 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)

    View Slide

  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 Attack Threat
    Accessed Globally => Compliant Everywhere!

    View Slide

  12. I-A-T-S PRINCIPLES
    • Evolve continually
    • Respond dynamically
    • Analyse don’t ask
    • APIs for everything
    • Secure by Design
    • Internationalise
    instinctively

    View Slide

  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

    View Slide

  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

    View Slide

  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, …

    View Slide

  16. ON THE FUTURE

    View Slide

  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 …

    View Slide

  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?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  22. THANK YOU … QUESTIONS?
    Eoin Woods

    Endava

    [email protected]
    @eoinwoodz

    View Slide