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

Intelligent
 Connected
 (2020s) Internet
 is the System
 (2010s) Internet
 Connected
 (2000s) Distributed
 Monoliths
 (1990s) 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

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!

I-A-T-S PRINCIPLES

• Evolve continually
• Respond dynamically
• Analyse don’t ask
• APIs for everything
• Secure by Design
• Internationalise

instinctively

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

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 maximizing 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

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

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

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?

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