Modern times - architectures for a Next Generation of IT
•
14 j'aime•3,532 vues
In this presentation I focus on the architectural aspect of the next generation of enterprise IT topic I already covered in some other presentations. The slide deck starts with a quick motivation. It describes the external drivers that require traditional enterprise IT to change. Based on these drivers, the drivers and requirements for an architecture that supports the external drivers are derived. The second major part of the slide deck then examines some of today's IT hype topics and evaluates them with respect to the architectural requirements derived before. Be aware that the evaluation partially is hard to understand without the voice track. Actually, at some places the explanations on the voice track are more important than the evaluations themselves. Thus, please do not take them too literally. The last major part then tries to sketch a possible architectural style that suits the given requirements. Again, the rationale for picking the respective elements are on the voice track, and it is just one possible style. There are for sure more styles available that suit the needs. Yet I think, the style described makes clear that the upcoming enterprise architectural styles are quite different from the styles that were predominant in the last 10 or 15 years and makes clear that we all have to face new challenges - not only on the architectural level. Sorry again that the voice track is missing. Yet I think, that the presentation provides some helpful ideas even without the voice.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Modern times - architectures for a Next Generation of IT
Similaire à Modern times - architectures for a Next Generation of IT (20)
Plus de Uwe Friedrichsen
Plus de Uwe Friedrichsen (12)
Dernier
Dernier (20)
Modern times - architectures for a Next Generation of IT
- 1. Modern Times Architectures for a Next Generation of IT Uwe Friedrichsen, codecentric AG, 2014-2015
- 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
- 3. Why do we need a “Next Generation IT”?
- 5. Economic Darwinism Everyone is affected by Economic Darwinism • All sectors • Growing globalization on all levels • Internet business • More competitors per customer • Higher customer expectations • Lower customer loyalty à In the long run only those will survive who meet the customer needs and demands best
- 6. Nice, but how does this relate to IT?
- 7. IT is the nervous system IT is vital • All companies • IT is not just supporter or „cost center“ … • … but it is the central nervous system • Even short IT outages considered critical • No business change without IT • No new products without IT à IT limits the maximum possible adaption rate of a company
- 8. IT is a key success factor for belonging to the survivors of the economic darwinism
- 9. What business needs from IT …
- 11. How IT serves business …
- 14. But there is more …
- 15. Lean Enterprise Product shaping/optimization Innovation Measure & analyze Accelerating OODA loop Quick customer feedback cycles
- 17. IT as a Product Virtualization of products IT-centric business models Disruptive new business models
- 18. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product IT Technology-related Change Drivers
- 19. Pay-per-Use Business Case Self-Service Cloud Elasticity Unreliable COTS Hardware Provisioning Speed
- 20. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IT Technology-related Change Drivers
- 21. Zero Downtime Peer Multiplication Mobile & IoT Deep Process Integration Unreliable Communication Unpredictable Load Patterns
- 22. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Technology-related Change Drivers
- 23. … and more Big Data Analysis Amplifiers Social
- 24. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Big Data Analytics Social Technology-related Change Drivers
- 25. Why does traditional IT usually fail to respond to those challenges?
- 26. Traditional IT bases its optimization efforts on the wrong goals and principles
- 27. Traditional IT goals/principles • Fault avoidance at any cost a.k.a. “the root of all evil” • Tayloristic organization • Local optimization • Process frenzy • Central control • Long-running projects • Standardization • Cost minimization à Not suitable to respond to new challenges
- 28. Then, what are the new goals?
- 29. Economic Darwinism Business-related Change Drivers Lean Enterprise IT as a Product Cloud IoT Mobile IT Big Data Analytics Social Technology-related Change Drivers
- 30. Short cycle times Continuous output High flexibility High reliability Equally Valued Goals Holistic consideration Goals of a Next Generation (of) IT
- 31. And what are the new principles?
- 32. Principles of a Next Generation (of) IT The Core Principles Maximizing innovation instead of minimizing costs Controlled experiments instead of fault avoidance at any cost Decentralized, self dependent teams instead of central control and goal sheets Flexible adaption instead of static planning Accepting complexity on all levels Based on Jeff Sussna's 21st Century IT Manifesto (http://blog.ingineering.it/post/39385342347/21st-century-it-manifesto) Refined in collaboration with Eberhard Wolff
- 33. Principles of a Next Generation (of) IT The Technical Principles Diversity & lightweight tools instead of monoculture & integrated solutions Resilience instead of stability (µ)Services instead of monoliths Elasticity instead of upfront capacity planning Consistent automation of routine tasks Based on Jeff Sussna's 21st Century IT Manifesto (http://blog.ingineering.it/post/39385342347/21st-century-it-manifesto) Refined in collaboration with Eberhard Wolff
- 34. Nice (again), but how does this relate to architecture?
- 35. Goals & Principles Architecture drives supports
- 36. What does that mean for architecture?
- 37. Architectural drivers • Need for quick change and extension • Replace over reuse • Need for quick releases • Unpredictable load patterns • Distributed, highly interconnected systems • Extreme high service availability • Diverse front-ends and devices • Cost efficiency
- 38. Architectural requirements • Easy to understand • Easy to extend • Easy to change • Easy to replace • Easy to deploy • Easy to scale • Easy to recover • Easy to connect • Easy to afford
- 39. Architectural requirements • Easy to understand à Understandability • Easy to extend à Extensibility • Easy to change à Changeability • Easy to replace à Replaceability • Easy to deploy à Deployability • Easy to scale à Scalability • Easy to recover à Resilience • Easy to connect à Uniform interface • Easy to afford à Cost-efficiency (for development & operations)
- 40. What are the appropriate solutions?
- 41. Let’s check a few hype topics …
- 42. µServices • Built for replacement (not reuse) • Self-dependent, loosely coupled services • Should be aligned with business capability • Size should not exceed what one brain can grasp
- 44. REST • Uniform access interface to resources • Closely related to the HTTP protocol • HATEOAS (Hypermedia as the engine of application state)
- 46. Event-driven • Asynchronous communication paradigm • Technical decoupling of communication peers (isolation) • Location transparency in conjunction with MOM • Call-stack paradigm replaced by (complex) message networks
- 48. CQRS • Command Query Responsibility Segregation • Separate read and write interfaces including underlying models • Separation can be extended up to the data store(s) • Allows for optimized data representations and access logic READ WRITE
- 50. Reactive • Event-driven – asynchronous and non-blocking • Scalable – scaling out and embracing the network • Resilient – isolation, loose coupling and hierarchical structure • Responsive – latency control and graceful degradation of service
- 52. Functional Programming • Alternative programming paradigm • Functional languages (Erlang, Haskell, Clojure, …) • Hybrid languages (Scala, …) • Languages with functional extensions (Python, JavaScript, Java, …)
- 54. NoSQL • Augments the data store solution space • Different sweet spots than RDBMS • Key-Value Store – Wide Column Store – Document Store • Graph Database
- 56. Continuous Delivery • Automate the software delivery chain • Build – Continuous Integration, … • Test – Test Automation, … • Deploy – Infrastructure as Code, …
- 58. Cloud provisioning model • On-demand provisioning and de-provisioning • Instant availability • Self-service • Pay-per-use
- 60. Docker • Build, ship, run on container-basis • Process-level isolation • Declarative communication path configuration • Cambrian explosion of ecosystem at the moment
- 62. … and there are many more
- 63. What can we learn from this?
- 64. Findings • There is not a simple solution and no “one size fits all” • Some of the topics evaluated have a high potential • Some of the topics evaluated do not help so much • A combination of several approaches is needed
- 65. How would an architectural style look like?
- 66. µServices • Conway’s law • Built for replacement • Aligned with business capabilities • Bounded Context (Domain-Driven Design) • Separate UI and service
- 67. Bounded Context Bounded Context Bounded Context µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS UI e.g., B2C-Portal UI e.g., embedded in Partner-Portal UI e.g., Mobile App UI e.g., Clerk Desktop
- 68. REST interfaces • Use as API gateway for client access • Encapsulate dynamics and complexity of service landscape • Provide client-driven, coarse-grained service calls behind a uniform API based on a proven protocol • Should be provided on bounded context level • Decouple speed of evolvement (services vs. API)
- 69. Bounded Context µS µS µS µS µS REST API Gateway µS Bounded Context Other Client User Interface Bounded Context Message-based API also okay, but requires clear and stable, client-oriented contract
- 70. Event-driven communication • Use for inter-service communication • Decoupling and isolation • Vertical slicing of functionality • Easier evolution of flows and processes • Configuration-visualization-monitoring support required
- 71. µS Request/Response : Horizontal slicing Flow / Process µS µS µS µS µS µS Event-driven : Vertical slicing µS µS µS µS µS Flow / Process
- 72. Resilient/reactive design • Resilience and responsiveness are mandatory • Elastic design for scalability • Start with isolation and latency control • Separate control and data flow • Many new challenges for developers
- 73. Event/data flow Event/data flow Resource access Error flow Control flow µS Isolation
- 74. Cloud provisioning model • Basis for elasticity at runtime • Basis for speed and flexibility at development time • Private, hybrid or public • Should be combined with container approaches (e.g., Docker) • “Natural” infrastructure for µService architecture
- 75. Container Manager µS µS µS µS µS µS µS µS µS µS µS µS µS µS µS Container Explicitly declared communication paths µService
- 76. Automate • Automate everything • Build, test & deployment (Continuous Delivery) • Resource provisioning (Cloud API) • Restart, failover, error handling (Resilience) • Starting and tearing down instances (Scalability)
- 77. Wrap-up • IT is the nervous system of a company • Delivery speed is the new benchmark • Architecture must support the drivers • The new architectures are different • New challenges for developers (& ops)
- 78. It’s the most disruptive and exciting change we have seen in IT for many years Join the IT revolution!
- 79. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com