Software architectures for hybrid cloud scenarios

Slide 1

Slide 1 text

Software Architectures for hybrid cloud scenarios Michael Plöd Principal Consultant @bitboss

Slide 2

Slide 2 text

I will not deliver any rocket science at all

Slide 3

Slide 3 text

3 The usual questions

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

9 This talk focusses on software architecture and not on infrastructure

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

11 Combination of internally hosted cloud platforms On Premise PaaS CaaS

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Public 14 Public PaaS CaaS 14 Combination of various public offerings

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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?

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

18 Independence Choose Your Features Wisely 12  Factors ISA

Slide 19

Slide 19 text

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/

Slide 20

Slide 20 text

20 Independence ISA Container Proces Virtual Machine Modules Macro / Micro Architecture Independent  Continuous  Delivery Resilience Integration Communication Standardized Operations Standards: Interface only

Slide 21

Slide 21 text

21 Independence Choose Your Features Wisely AVOID VENDOR SPECIFIC FEATURES

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 Independence 12  Factors Dependencies Codebase Config Processes Backing Services Build, release,   run Admin processes Dev / prod parity Logs Disposability Port binding Concurrency

Slide 24

Slide 24 text

24 Independence Choose Your Features Wisely 12  Factors ISA

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Example 1 - Customer Reservations Event  Management Badges Customer Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle

Slide 28

Slide 28 text

Approach

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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?

Slide 31

Slide 31 text

> 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

Slide 32

Slide 32 text

> 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

Slide 33

Slide 33 text

> Derived from real business goals > Examples: > Time 2 Market (release/deployment cycles) > Security > Availability > Load and performance (read/write) > Scalability > User experience > … Quality goals

Slide 34

Slide 34 text

> 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

Slide 35

Slide 35 text

Domain Model Quality goals Organizational constraints Process ownership Domain   Architecture

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

50 Vielen Dank! MICHAEL PLÖD  Principal Consultant at INNOQ Deutschland GmbH