Software architectures for hybrid cloud scenarios

Hybrid cloud scenarios are an important topic in many larger organizations that want to keep their very sensitive data and functionality on premise but that also desire to benefit from the advantages of public cloud offerings.
Such a scenario forces software archictects and developers into the consideration of some special requirements. This session introduces you to the topic „hybrid cloud“ and aims to give you a guidance to the solution of topics like latency differences, security and integration. The session give you insights into the following questions:
- How do I make sure that I can deploy my software to various cloud platforms?
- How do I make sure that my business logic and data are correctly split up between a public and an on premis cloud solution?
- What are integration related considerations of my macro architecture in such a scenario?
- How do I deal with internal legacy applications in a hybrid cloud scenario?

Transcript

1. Software Architectures for hybrid cloud scenarios Michael Plöd Principal Consultant @bitboss
2. I will not deliver any rocket science at all
3. 3 The usual questions
4. 4 What does the term hybrid cloud mean and which challenges come with it?
5. 5 How do I make sure that I can move my software from one cloud provider to another?
6. 6 How do I cut my microservices in this scenario in terms of business capabilities?
7. 7 What do I need to consider with regards to integration and communication in a hybrid cloud scenario?
8. 8 How do I deal with existing legacy systems, which are probably operated in a „classic“ fashion on premise?
9. 9 This talk focusses on software architecture and not on infrastructure
10. 10 What does the term hybrid cloud mean and which challenges come with it?
11. 11 Combination of internally hosted cloud platforms On Premise PaaS CaaS
12. 12 Combination of internally hosted cloud platforms with lots of legacy On Premise PaaS CaaS Legacy
13. Public 13 On Premise PaaS CaaS 13 Combination of public and on premise cloud platforms
14. Public 14 Public PaaS CaaS 14 Combination of various public offerings
15. Sidenote You don’t want this scenario in the first place
16. General challenges 16 Latency Expect differing latencies between cloud-internal and external communication. Mind this in your approach towards resilience. Data Mind your internal data protection policies and regulations with regards to decisions about data storage and processing Security How do you plan to deal with security between different cloud providers?
17. 17 How do I make sure that I can move my software from one cloud provider to another?
18. 18 Independence Choose Your Features Wisely 12
 Factors ISA
19. 19 Independence ISA • Independent Systems Architecture • Collection of best practices based on experience in particular with microservices and Self-contained Systems • http://isa-principles.org/
20. 20 Independence ISA Container Proces Virtual Machine Modules Macro / Micro Architecture Independent
 Continuous
 Delivery Resilience Integration Communication Standardized Operations Standards: Interface only
21. 21 Independence Choose Your Features Wisely AVOID VENDOR SPECIFIC FEATURES
22. 22 Independence 12
 Factors • Defined by Heroku for SaaS apps • Declarative formats • Clean contract for maximum portability • Deployment on modern cloud platforms • Minimize env divergence • Scalability • https://12factor.net//
23. 23 Independence 12
 Factors Dependencies Codebase Config Processes Backing Services Build, release, 
 run Admin processes Dev / prod parity Logs Disposability Port binding Concurrency
24. 24 Independence Choose Your Features Wisely 12
 Factors ISA
25. 25 How do I cut my microservices in this scenario in terms of business capabilities?
26. Bounded Context Every sophisticated business (sub-) domain consists of a bunch of Bounded Contexts Each Bounded Context contains models and maybe other contexts The Bounded Context is also a boundary for the meaning of a given model
27. Example 1 - Customer Reservations Event
 Management Badges Customer Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle
28. Approach
29. If a Bounded Context defines the technical system boundaries, it not only partitions domain model but also defines units for: > development (teams) > deployment > availability > scalability > security zones Context boundary == System boundary
30. 1. Domain model: Domain objects and their relations 2. Use Cases, processes and workflows 3. Quality goals, non-functional requirements 4. Organizational aspects What to consider?
31. > Identify domain objects: events, aggregates, etc. > Analyze and describe relations between domain objects > Be aware of an object’s varying characteristics in different use cases > Maybe try Event Storming Domain model
32. > Identify processes that need to be owned and controlled by one person in charge and one team > Concentrate responsibility for business goals / KPIs in one hand > Examples: User registration, eCommerce checkout, conversion rates Process ownership
33. > Derived from real business goals > Examples: > Time 2 Market (release/deployment cycles) > Security > Availability > Load and performance (read/write) > Scalability > User experience > … Quality goals
34. > Do you have authorization and power to adapt the organization to your system design? > What are the constraints you can‘t change? > Corporate structures > Teams, people and skillsets > … Organizational constraints
35. Domain Model Quality goals Organizational constraints Process ownership Domain 
 Architecture
36. 36 What do I need to consider with regards to integration and communication in a hybrid cloud scenario?
37. Context Map The DDD Context Map helps you in sketching out integration in a hybrid cloud scenario Not every pattern will be suitable for you The Context Map is also a great starting point for future transformations
38. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Two teams share a subset of the domain model including code and maybe the database. not suitable
39. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language There is a customer / supplier relation ship between two teams. The downstream team is considered to be the customer, sometimes with veto rights. sometimes ok
40. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language The downstream team conforms to the model of the upstream team. There is no translation of models and no vetoing. If the upstream model is a mess, it propagates to the downstream model. not suitable
41. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language The anticorruption layer is a layer that isolates a client’s model from another system’s model by translation. suitable
42. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language There is no connection between the bounded contexts of a system. This allows teams to find their own solutions in their domain. suitable
43. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open Host Service Published Language Each Bounded Context offers a defined set of services that expose functionality for other systems. Any downstream system can then implement their own integration. This is especially useful for integration requirements with many other systems. suitable
44. Context Map Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open Host Service Published Language Published Language is quite similar to Open Host Service. However it goes as far as to model a Domain as a common language between bounded contexts. suitable
45. Hybrid-Cloud best Practices Hints Anti- Corruption Very good suitability for all kinds of integration, especially when integrating legacy systems („Anti- Corruption Microservice“) Published Language Maximized decoupling, keep it small! Open Host Service See ISA Principles: Modules that expose interfaces Separate Ways Aim for Separate Ways in many cases, but it can be hard or unsuitable to achieve
46. Integration-Technologies Integration RESTful HTTP Suitable inside one Cloud Environment. Would avoid synchronous Communication between two environments WebServices Only for the integration of Legacy systems with an „Anti-Corruption“ Microservice Feeds Excellent fit for the integration between two cloud environments Messaging Suitable inside one Cloud Environment. Would avoid between two environments
47. 47 How do I deal with existing legacy systems, which are probably operated in a „classic“ fashion on premise?
48. On Premise Public SCS A Old School ACL SCS C Legacy Old School System SCS 1 SCS 1 SCS B WebService Events HTTP-Feed HTTP-Feed
49. Macro Architecture Micro Architecture > Communication within one cloud platform > Communication between cloud platforms > Unified handling of security > Resilience inside and outside cloud platforms > Integration to legacy software (ACL?) > Implementation of each system > Persistence > Module / System specificts Architecture Decisions
50. 50 Vielen Dank! MICHAEL PLÖD
 Principal Consultant at INNOQ Deutschland GmbH