Embed Size (px)
Citation preview
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
IntelligentConnected
(2020s)
Internetis the System
(2010s)
InternetConnected
(2000s)
DistributedMonoliths(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 deploys2. Explicitly declare and isolate dependencies3. Store config in the environment4. Treat backing services as attached resources5. Strictly separate build and run stages6. Execute the app as one or more stateless processes7. Export services via port binding8. Concurrency scale out via the process model9. Disposability by maximising robustness (startup, shutdown)10. Dev/Prod Parity by aligning development, staging, and prod11. Treat logs as event streams12. 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
