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
   

   View Slide

2. I will not
   deliver any
   rocket
   science at
   all
   
   

   View Slide

3. 3
   The usual
   questions
   

   View Slide

4. 4
   What does the term hybrid cloud
   mean and which challenges come
   with it?
   

   View Slide

5. 5
   How do I make sure that I can move
   my software from one cloud provider
   to another?
   

   View Slide

6. 6
   How do I cut my microservices in this
   scenario in terms of business
   capabilities?
   

   View Slide

7. 7
   What do I need to consider with
   regards to integration and
   communication in a hybrid cloud
   scenario?
   

   View Slide

8. 8
   How do I deal with existing legacy
   systems, which are probably
   operated in a „classic“ fashion on
   premise?
   

   View Slide

9. 9
   This talk focusses on
   software architecture
   and not on
   infrastructure
   

   View Slide

10. 10
    What does the term hybrid cloud
    mean and which challenges come
    with it?
    

    View Slide

11. 11
    Combination
    of internally
    hosted cloud
    platforms
    On Premise
    PaaS
    CaaS
    

    View Slide

12. 12
    Combination
    of internally
    hosted cloud
    platforms
    with lots of
    legacy
    On Premise
    PaaS
    CaaS
    Legacy
    

    View Slide

13. Public
    13
    On Premise
    PaaS
    CaaS
    13
    Combination
    of public and
    on premise
    cloud
    platforms
    

    View Slide

14. Public
    14
    Public
    PaaS
    CaaS
    14
    Combination
    of various
    public
    offerings
    

    View Slide

15. Sidenote
    You don’t want this
    scenario in the first place
    

    View Slide

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?
    

    View Slide

17. 17
    How do I make sure that I can move
    my software from one cloud provider
    to another?
    

    View Slide

18. 18
    Independence
    Choose
    Your
    Features
    Wisely
    12

    Factors
    ISA
    

    View Slide

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/
    

    View Slide

20. 20
    Independence
    ISA
    Container
    Proces
    Virtual Machine
    Modules Macro / Micro
    Architecture
    Independent

    Continuous

    Delivery
    Resilience
    Integration Communication
    Standardized
    Operations
    Standards:
    Interface only
    

    View Slide

21. 21
    Independence
    Choose
    Your
    Features
    Wisely
    AVOID VENDOR
    SPECIFIC FEATURES
    

    View Slide

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//
    

    View Slide

23. 23
    Independence
    12

    Factors
    Dependencies
    Codebase Config
    Processes
    Backing Services Build, release, 

    run
    Admin
    processes
    Dev / prod
    parity
    Logs
    Disposability
    Port binding Concurrency
    

    View Slide

24. 24
    Independence
    Choose
    Your
    Features
    Wisely
    12

    Factors
    ISA
    

    View Slide

25. 25
    How do I cut my microservices in this
    scenario in terms of business
    capabilities?
    

    View Slide

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
    

    View Slide

27. Example 1 - Customer
    Reservations
    Event

    Management
    Badges
    Customer
    Name
    Payment Details
    Address
    Company
    Session Registrations
    Lunch Preferences
    Name
    Job Description
    Twitter Handle
    

    View Slide

28. Approach
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

35. Domain Model Quality goals
    Organizational
    constraints
    Process
    ownership
    Domain 

    Architecture
    

    View Slide

36. 36
    What do I need to consider with
    regards to integration and
    communication in a hybrid cloud
    scenario?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

47. 47
    How do I deal with existing legacy
    systems, which are probably
    operated in a „classic“ fashion on
    premise?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

50. 50
    Vielen Dank!
    MICHAEL PLÖD

    Principal Consultant
    at INNOQ Deutschland GmbH
    

    View Slide