Invasion of Lightweight Architectures

Transcription

1 Invasion of Lightweight Architectures Strategy Digital Technology Operations

2 Bio Matt Lancaster >10 years building software for fun and profit (ongoing) Twice CTO, once professor, occasional angel investor, now Benevolent Dictat Lightweight Architecture lead at Accenture Also have degrees in Philosophy and Ancient History If you want raunchy Roman poetry or a long conversation about Alexander s successors, I m also your guy!

3 New IT is the New Normal Software is eating the world: Primary channels of customer engagement are digital Software is being embedded in everything Digital experiences now permeate everything from cars to toasters Adaptation means three fundamental challenges: Delivery speed; Lean Startup approach Become a Digital Native Deliver at or below current budgets

4 Examples vs vs

5 How to Adapt? New Delivery Methods Lightweight Architecture DevOps They re linked! To succeed, we must tackle all three!

6 What are Lightweight Architectures, anyway? Traditional Architectures Lightweight Architectures Monolithic Modular Device Specific Development Responsive Web Design Single Technology Best tool for the Job Tool Based Integration Standards & API based integration Closed / Vendor driven Open Source & Ecosystem Embraced Features Released in Months Features Released in Days

7 Traditional Architecture: Hospitality Example Web Mobile Channels ESB Reservations Loyalty CRM Content Monolithic Backend Systems

8 Lightweight Architecture: Hospitality Example Web Mobile Any Channels Third Party Things Channels Above Property APIs On-Property APIs Reservations Loyalty CRM Content Physical Property Microservices

9 1=0, 2=0, 3=3 The benefits of New IT are often sought by making token delivery changes / partial DevOps implementation Even with continuous delivery capability and Lean Agile delivery, legacy architecture can make us fail! Without architecture changes, DevOps or modern, lean delivery methods will fail to produce significant results. vs is not a fair fight, and no amount of training or process change can fix this!

10 Why Do We Need Lightweight Architectures? Problem Solved by Test/Integration Complexity Modularity / Contracts Slow Feature Release Separate Modular Deployables Scalability Exponentially Expensive Elastic Architectures Unreliable / Costly Failure Protection Build for Breaking Tech Limits UX Tech Empowers UX ALL of these issues have significant delivery impacts and business strategy impact!

11 Business Problems and Solutions: Deeper Dive

12 Test / Integration Complexity Cause: monolithic systems, deep interdependence Solution Patterns: microservices, modular UI Microservice API Interfaces App Logic Data Solution Details (left and right) Representative technologies gokit Microservice Architecture API Gateway Supporting Services Microservice Microservice Elastic Infrastructure

13 Slow Feature Releases Cause: monolithic all or nothing model Container Application Additional Services Solution Patterns: separate deployables, modular UI Solution Details (left) App Platform Microkernel Representative technologies Host

14 Exponentially expensive scalability Cause: threaded application and architecture model Solution Patterns: distributed app patterns (Reactor, Actor Model, etc) Stores and retrieves events Event Dispatcher Synchronous Event Demultiplexer Reactor Pattern events Event Handlers Event Handlers Event Handlers Initiators and Receivers responses Solution Details (left and right) Representative technologies Actor System Execution Context Dispatcher Thread Management Actor Client Immutable Message Serializable Actor Behavior & State Mailbox Msg Queue Durability Actor Supervisor Supervisor Strategy Exception Handling Guardian Actor / User Actor Ref Spring Reactor

15 Unreliable / Costly Failure Protection Cause: protect from failure mindset Contemporary middleware Solution Patterns: distributed horizontal Browser scalability, Circuit Breaker Horizontally Scalable Lightweight Distributed Architecture Browser HW LB HW LB SW LB SW LB Circuit Breaker Pattern Success count threshold reached Closed Failure count threshold reached Solution Details (left and right) Web Web Web App App App Web App Service Service Halfopen Timeout times expired Operation failed Open Representative DB technologies DB Store Store Disk Disk Disk Disk

16 Technology Limits User Experience Cause: Legacy UI technologies, Fragmented UI Client Pattern Example: MVC PushState Passes calls to Router Controller Updates User Interaction manipulates DOM View Fires events Fires events on Model Solution Patterns: Client/API, Modular UI Solution Details (left and right) Representative technologies Booking Microservice Microservice Modular UI Loyalty Common Framework Separate SPAs APIs Content On-Prem UIs

17 and More! Many more business problems are solved and constraints are lifted by putting our system architectures on a diet! If we want to survive in the now universally digital native landscape, it s not a question of if, but when!

18 Implications and Commentary

19 What Does This Mean for Us? Switch from Infantry Divisions to Special Forces Teams Lightweight Architecture, combined with new delivery methods and DevOps will drastically reduce the manpower needed to deliver an application, but each individual will need to be more skilled. Software Architecture becomes critical to business strategy!

20 And Now for Some Fun, Provocative Statements :)

21 ESBs Must Die The ESB has no place in modern system architectures (outside of continuing to support legacy systems) APIs & Microservices built on top of an ESB mean that you re attaching a cruise ship anchor to a steamboat Modern system architectures are analogous to the architecture of the Internet itself: distributed by design an integration bus is only a SPOF!

22 No More Sporks! The era of single-language systems is quickly coming to a close Java and (traditional).net are being replaced (in some cases wholesale) Down with (many applications of) Java, long live the JVM! Most modern systems are polyglot, and components are fit for purpose and select the best language/tool for the job If you say you re a J(2)EE Architect or a Java Architect, it s code for Don t Hire Me

23 Don t Assemble a Bunch of Packages If your resulting system architecture looks like a bunch of proprietary software icons connected with lines, you re doing it wrong Most packaged software vendors haven t caught up yet, they re still mostly monoliths Friends don t let friends create houses of cards stuck together with old chewing gum ;)

24 Don t Use Queues, JMS or Otherwise They re just bottlenecks, and have no place in remotely distributed systems Use patterns like Reactor / Proactor / Actors instead