The Evolution of Architecture
•Download as PPTX, PDF•
1 like•1,105 views
Presentation delivered at NVISIA Digital Platform Conference 2018 by: DAN CHRISTOPHERSON Technical Fellow NVISIA
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to The Evolution of Architecture
Similar to The Evolution of Architecture (20)
More from NVISIA
More from NVISIA (16)
Recently uploaded
Recently uploaded (20)
The Evolution of Architecture
- 1. “The Evolution of Architecture” May 17, 2018
- 2. NVISIA - Confidential and Proprietary Dan Christopherson Technical Fellow danch@nvisia.com 1997 Introduced OO with UI and business domain separation 2000 Mainframe to Java and distributed architecture 2004 Architected Portal solution with JSR-168 and Struts 2006 Architect of enterprise integration tier 2007 Introduced web service architecture for integration with third party products 2013 Architect for enrollment & member access systems 2018 Introducing microservices with API Management platform 2010 Architect of web-based payroll system
- 3. NVISIA - Confidential and Proprietary Let’s transport ourselves back to the ‘90s….
- 4. NVISIA - Confidential and Proprietary Early Intranet Browser (Form posts, no JavaScript, not dynamic) Java App (non-mission-critical, support, workflow, etc.) Supplemental Data Core Application (Mainframe ‘green screen’, client-server, etc.) Core Data
- 5. NVISIA - Confidential and Proprietary Early 2000’s
- 6. NVISIA - Confidential and Proprietary Mainstream Web Browser Supplemental App Supplemental Data Core Application (Mainframe ‘green screen’, client-server, etc.) Core Data Message Oriented Middleware Supply Chain Data Supply Chain System
- 7. NVISIA - Confidential and Proprietary Late 2000’s
- 8. NVISIA - Confidential and Proprietary Service Integration Browser Supplemental App Supplemental Data Legacy System Legacy Data Message Oriented Middleware Purchaing Data Supply Chain System ManufacturingManufact uring Data Product EngineeringMaster BoM
- 9. NVISIA - Confidential and Proprietary Circa 2010
- 10. NVISIA - Confidential and Proprietary JavaScript and AJAX Browser Supplemental App Supplemental Data Legacy System Legacy Data Message Oriented Middleware Purchaing Data Supply Chain System ManufacturingManufact uring Data Product EngineeringMaster BoM JavaScript Enabled Browser Apps
- 11. NVISIA - Confidential and Proprietary 2015
- 12. NVISIA - Confidential and Proprietary Single Page Applications Browser Supplemental App Supplemental Data Legacy System Legacy Data Message Oriented Middleware Purchaing Data Supply Chain System ManufacturingManufact uring Data Product EngineeringMaster BoM Single Page Applications
- 13. NVISIA - Confidential and Proprietary Today
- 14. NVISIA - Confidential and Proprietary Microservices Browser Supplemental App Supplemental Data Legacy System Legacy Data Message Oriented Middleware Purchaing Data Supply Chain System ManufacturingManufact uring Data Product EngineeringMaster BoM Single Page Applications
- 15. NVISIA - Confidential and Proprietary So now what?
- 16. NVISIA - Confidential and Proprietary • Front-end browser/javascript ‘Single Page Application’ • Enables a reasonable user experience, with minimal management overhead • Back-end (data access, business logic, integration) exposed via ReSTful services • Monolithic – multiple services/resources per deployment unit, probably cross-coupled, whether intentionally or accidentally • Microservice – single cohesive service/resource per deployment unit • Multiple datastores, sometimes multiple paradigms • Multiple integration paradigms – synch, asynch, batched. All with multiple transports/toolsets • Multiple vendor systems – on and off prem • Multiple ‘strata’ of legacy • Inconsistent user experience Current State
- 17. NVISIA - Confidential and Proprietary • Environments and infrastructure management • Proliferation of point-to-point integration • ReSTful APIs used by SPAs • Service Versioning • Multiple failure points – fragile and inconsistent • Security is inconsistent and difficult to federate • It can be difficult to support the agility that 21st century business requires • Coupling ossifies systems • Deployments require extensive coordination • User dissatisfaction/inefficiency Challenges
- 18. NVISIA - Confidential and Proprietary • Enterprise Integration Brokers -> Enterprise Service Bus -> API Management • Test Driven Development -> Continuous Integration -> DevOps • Virtualization -> Containers -> Cloud • Waterfall -> Iterative -> Agile Meanwhile – technological developments
- 19. NVISIA - Confidential and Proprietary • Service discovery/location independence – reduce configuration of service endpoints • Security in depth • Robustness – fail over, failure tolerance, 0-down-time rollouts • Automated testing, Continuous integration, Automated deployment • Self-contained deployment • Monitoring and management • Efficient use of physical infrastructure • Automated infrastructure management • API consumer provisioning/API catalog • Endpoint management – rate limiting, enhanced routing, etc. Capabilities Matter
- 20. NVISIA - Confidential and Proprietary • Microservices – smaller deployment units simplify development and deployment • Containerization – enables microservices by automating infrastructure • DevOps – automated testing and deployment Forward – the big picture
- 21. NVISIA - Confidential and Proprietary One way to skin the mule Gateway Browser SPA JavaScript- enabled Apps Native Mobile Container Infrastructure Supply Chain System Product Engineering Message Oriented Middleware Legacy System Legacy Data Supple- mental App Supple- mental Data Purchaing Data Manufact uring Data Master BoM
- 22. NVISIA - Confidential and Proprietary • Containers, gateways, DevOps practices are broadly applicable regardless of application or solution architecture. Microservices are one option in those architectures. • The idea of moving wholly to a microservice architecture is generally impractical – organizations have no control over vendor systems and rearchitecture of legacy systems is often daunting. • Decisions must be made as to where new architectures will be worthwhile, and where they will not (as with every preceding architectural development); where the heavy refactoring required will provide an advantage. Pragmatics
- 23. NVISIA - Confidential and Proprietary • An application that’s been around for a number of years tends to have developed cross-coupling between subjects that you’d like to separate. • Transactions are often used to provide atomicity to units of work that spread across separable subjects. Transaction propagation across microservice boundaries is generally not supported, technically or philosophically. • Naïve refactorings often run into performance issues, or broaden service interfaces to the point that we’ve not actually reduced coupling at all. • Older applications often lack test coverage, making it difficult to verify refactorings. What makes that refactoring difficult?
- 24. NVISIA - Confidential and Proprietary Eating the Elephant
- 25. NVISIA - Confidential and Proprietary
- 26. NVISIA - Confidential and Proprietary
- 27. NVISIA - Confidential and Proprietary
- 28. NVISIA - Confidential and Proprietary
- 29. NVISIA - Confidential and Proprietary
- 30. NVISIA - Confidential and Proprietary
- 31. NVISIA - Confidential and Proprietary Repeat while Beneficial
- 32. NVISIA - Confidential and Proprietary • One bite at a time! • Improve unit and integration test coverage, either over time or as a defined effort • Identify a domain area as the next candidate – start near the ‘bottom’ of any dependency trees. • You may need to refactor internally before this is possible (if there are too many cyclic dependencies) • Determine an appropriate domain boundary for a candidate service to be extracted. • If the service has already been exposed, beware of assuming that what has been exposed is appropriate • Shift internal references to use the new interface. • This may require significant changes if it’s determined that existing logic is inappropriate in the service being extracted. • Shift external references to use the new interface. • Again, this may require more significant changes, and these changes may have to be fit into the client’s release stream. • If there are many external references, both old and new interfaces may have to be supported for some time. This can be approached in a number of ways. • Extract the new service into its own deployment unit. This may happen before all external references are moved – see versioning comment above. • Repeat while beneficial How to eat the elephant?
- 33. NVISIA - Confidential and Proprietary Thank you! What questions do you have?
Editor's Notes
- Scare quotes are to highlight the ambiguity – are we talking about past evolution or future? Is this a history lesson or a how-to? The answer, of course, is both.
- Around 1999, large enterprises began to invest in internal applications using internet technologies (HTML, HTTP). Advantages sought included ease of administration (no desktop installation), improves scalability (especially vs. client-server, and, sometimes, a clean slate for new development Early efforts were often in non-mission critical areas in order to gain experience and prove out the architecture at minimal risk.
- As internet technologies proved themselves, organizations began to use them for more mission-critical applications. ISVs began to offer 'web portals' to support secondary functions (for example, employee self-service) Integration began to be more important to these applications, as enterprise workflows tend to cut across system boundaries. Integration often happened at the data level, through file batches, shared databases, and ETL. Some organizations leveraged existing MOM infrastructure, or introduced it for particularly compelling use cases
- As process automation became more of a necessity, applications supporting different areas of the business needed to be integrated more than ever, and those integrations had to be "real-time" (in reality, this simply meant that it had to be fast enough that a human probably wouldn't notice the delay). These needs lead to increasing levels of integration, using technologies such as CORBA, Java RMI, DCOM, and finally SOAP
- Web applications were initially a step backward in terms of user experience, forcing users to wait for a screen to load before entering data, then submitting and waiting for a response. Often the wait periods were relatively low, but the lack of 'live' lookups often lead to usability issues. Javascript began to be applied to these problems when the 'AJAX' techniques were developed. These techniques required the middle-tier of the applications to expose HTTP service endpoints for the javascript to consume. SOAP was considered too heavyweight and complex for these needs. Nominally, they used XML as a payload in simple HTTP requests, but in some cases javascript or even html fragments were returned to the browser.
- The logical extension of the AJAX technique is the single-page application - an entire user interface written in Javascript, running in the web browser. This generally requires a number of service endpoints to be exposed to the browser. As this architecture became popular, this style of service had come to be called 'ReSTful', whether or not they actually represented the Transfer of a Representation of STate. As more service endpoints are added to applications, the web of dependencies becomes more difficult to manage. Changes in one endpoint carry the risk of disruption of other endpoints in the shared application.
- In order to mitigate the issues we run into when applications expose multiple endpoints, we adopt microservice architectures. Each microservice is a highly cohesive set of endpoints and is loosely coupled with other microservices.
- Microservices – ‘bounded context’
- May want to flip to the last diagram…
- Here ‘technological’ encompasses process and product None of these transitions are truly linear developments
- There’s a lot more that could be said, but I’m keeping this down to three big points, essentially for rhetorical purposes. Key point – moving to microservices (and SPAs) moves complexity from being internal to the back ends to being external, in how those microservices are composed together (and some logic is moved back out to the actual browser based UI). Containerization (and some ‘API Management’ capabilities) helps manage this complexity. Given ‘good’ microservice design (distribution of responsibility), this results in a more even distribution of complexity.
- How do you eat an elephant? One bite at a time!
- Improve test coverage – either over time or as a defined effort.
- Identify a domain area as the next candidate – start near the ‘bottom’ of any dependency trees. You may need to refactor internally before this is possible (if there are too many cyclic dependencies)
- Determine an appropriate domain boundary for a candidate service to be extracted. If the service has already been exposed, beware of assuming that what has been exposed is appropriate
- Shift internal references to use the new interface. This may require significant changes if it’s determined that existing logic is inappropriate in the service being extracted. Shift external references to use the new interface. Again, this may require more significant changes, and these changes may have to be fit into the client’s release stream. If there are many external references, both old and new interfaces may have to be supported for some time. This can be approached in a number of ways.
- Extract the new service into its own deployment unit. This may happen before all external references are moved – see versioning comment above.