Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software architectures for hybrid cloud scenarios

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?

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

March 23, 2018
Tweet

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