This document discusses the pros and cons of a multicloud approach versus using a single cloud provider. It acknowledges that while a multicloud strategy is important for reducing vendor lock-in, in practice it may be better for new teams to start with AWS due to existing knowledge and support structures. The document provides guidance on how to adopt a multicloud approach over time while still allowing individual teams to choose the cloud provider that best fits their current needs and experience.

1. THE TWO SIDES OF CLOUD
COMPUTING
Event driven multicloud distributed microsystems
Stefan Kürten & Marco Hutzsch

2. • Software Engineer
• Loves Tech
• Writes Code
• Creates Value
• Inhales Challenges
• Helps Product Teams
• Someone you can always have a good
conversation with, no matter which topic, day of
time or mood you have
Introduction
Seite 2
• Software Engineer
• Motivates People
• Solves Problems
• Never gives up
• Exemplifies Technical Excellence
• Has seen it all
• Goto person for technical help, honest opinions
and brutal sarcasm
Stefan Marco

3. MULTICLOUD IS A STUPID
BUZZWORD AND DOES NOT HELP
ANY TEAM AT ALL
Seite 3

4. • Companys vision follows a multicloud approach to be
less dependent on one vendor
• Have a balanced mix between AWS, GCP (and Azure)
• Support decision making in producteams
• Ensure best-in class support offering
• No migration project
A multicloud approach is an important part of technology strategy
Seite 4
• Not much experience with GCP to start
immediately on a large scale
• Collective knowledge for AWS is greater (AWS
Community)
• Technical cross team connections to work best
with AWS
• New teams need quick ramp up of run
environments
• Supporting and governance structures for AWS
exist

5. • Business over Tech: Keep track on Business requirements, reaching business scope is more important than tech
• Don‘t stop any existing teams from using AWS (if they are using it today)
• Avoid multicloud in single teams
• Handle vendor lock in, stay open
o Using high level fully managed services to reduce effort is still a good decision
o Use frameworks to keep chosen services abstract in code, e. g.
- Spring Boot Cloud GCP vs. Spring Data DynamoDB
- Spring Boot Cloud AWS Messaging vs. Spring Cloud GCP for pubsub
• Build collective knowledge, setup a common boilerplates
• Be supportive and help each other, especially cross team
Restrictions, Limitations and Derivations for technical architecture need
to be respected
Seite 5

6. Excerpt from our Technical Manifesto
Principles
• Bounded Contexts & Vertical Systems
• Non Blocking Communication
• Small and Simple (Microservices)
• Evolutionary Architecture
• Cloud Native
• Scale Horizontally
• Use Low-Tech Coupling (aka Smarts in the Nodes not the Network)
Our world
Seite 6

7. SCENARIO
Life on cloud#9 while using single provider
Seite 7

8. SCENARIO
Play with the strange kid
Seite 8

9. SCENARIO
Well, well, well. How the turn tables…
Seite 9

10. Seite 10
Our cloud magician
Kudos to Marcel Sauer for
completing our example
👏

11. REPOS
FOLLOW THE CODE LINES
https://github.com/otto-de/pubsub_sqs_relay
https://github.com/otto-de/sns_pubsub_relay
Seite 11

12. Thanks!
Buy: otto.de
Read: otto.tech
Apply: otto.jobs

13. Contact us:
Marco Hutzsch: Marco.Hutzsch@otto.de
Stefan Kuerten: Stefan.Kuerten@otto.de
HR: Hannah.Wilkens@otto.de