SOFTWARE ARCHITECTURE AS SYSTEMS DISSOLVE GOTO London 2016 Eoin - PowerPoint PPT Presentation


 SOFTWARE ARCHITECTURE AS SYSTEMS DISSOLVE GOTO London 2016 Eoin Woods - Endava 
 @eoinwoodz

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

SYSTEMS ARE DISSOLVING!

5 AGES OF SOFTWARE SYSTEMS Internet 
 is the System 
 (2010s) Distributed 
 Monoliths 
 (1990s) Intelligent 
 Connected 
 Internet 
 (2020s) Connected 
 (2000s) Monolithic 
 (1980s)

OUR HISTORY

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

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

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

CURRENT ERA

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)

ARCHITECTURAL DRIVERS Continuous Development Constant Competition => & 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!

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

IMPLICATIONS (1) • Design in CD from the start • remove obstacles to automation, testing, deployment • Allow modular evolution • bounded contexts, “micro services” Also see the 12factor.net advice • Assume “cloud” deployment • “cattle not pets”, no “snowflakes”, no static config, …

IMPLICATIONS (1) Also see the 12factor.net advice • Design in CD from the start 1. One codebase tracked in revision control, many deploys 2. Explicitly declare and isolate dependencies • remove obstacles to automation, testing, deployment 3. Store config in the environment 4. Treat backing services as attached resources • Allow modular evolution 5. Strictly separate build and run stages 6. Execute the app as one or more stateless processes • bounded contexts, “micro services” 7. Export services via port binding 8. Concurrency scale out via the process model 9. Disposability by maximizing robustness (startup, shutdown) • Assume “cloud” deployment 10. Dev/Prod Parity by aligning development, staging, and prod • “cattle not pets”, no “snowflakes”, no static config, … 11. Treat logs as event streams 12. Run admin/management tasks as one-off processes

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

ON THE FUTURE

INTELLIGENT CONNECTED Our future as software architects … • 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”

INTELLIGENT CONNECTED How will it affect software architects? 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

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

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

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

THANK YOU … QUESTIONS? Eoin Woods 
 Endava 
 eoin.woods@endava.com @eoinwoodz