Enterprise Cloud Native ist das neue Normal

ENTERPRISE
CLOUD NATIVE
IST DAS
NEUE NORMAL
| 4. Münchner SE-Couch Meetup | @LeanderReimer #cloudnativenerd #qaware

| 4. Münchner SE-Couch Meetup | Enterprise Cloud Native ist das neue Normal | @LeanderReimer #cloudnativenerd #qaware
#whoami
2
Mario-Leander Reimer
Chief Software Architect
QAware GmbH
Yes, this is me!

1996
3

2000
4

Bild: Jupiterimages – gettyimages.de

Bild: Berkozel – gettyimages.de

Bild: NatalyaLucia – gettyimages.de
Dev
Ops

https://commons.wikimedia.org/w/index.php?curid=2223771

Enterprise Cloud Native ist das neue Normal

2020
10

| 4. Münchner SE-Couch Meetup | Enterprise Cloud Native ist das neue Normal | @LeanderReimer #cloudnativenerd #qaware11
By Simon Wardley #EEA @swardly https://twitter.com/swardley/status/1143463178396979200?s=03

https://www.loodse.com/blog/why-you-should-go-cloud-native-in-2020

Enterprise Cloud Native
ANTIFRAGILITYHYPERSCALE
TRAFFIC, DATA, FEATURES
RECRUITING
SPEED
DEVOPS &
CONTINUOUS DELIVERY
OPEX SAVINGS
(automation & utilization)

NOPE, IT'S ALL BAD.
SO THIS IS

CLOUD NATIVE?

YOU KNOW WHAT?

IT'S NOT HALF BAD.

NATÜRLICH IST NICHT

ALLES ROSAROT IM

CLOUD NATIVE LAND.

Nicht schön. Hat aber funktioniert.
16
Ein Monolith
Komponente
A
Komponente
T
Komponente
?

Deﬁnitiv keine gute Idee!
17
Microservice
A
Microservice
T
Microservice
?

Fachlichkeit
an erster Stelle
18

Hands-on Event Storming.
Event storming is a workshop-based interactive method
for rapidly identifying the key concepts and boundaries
in a business domain and aligning a variety of stake-
holders in the best way to slice potential solutions. The
basic idea is to bring together software developers and
domain experts and learn from each other. The business
process is "stormed out" as a series of domain events
which are denoted as sticky notes on a wide wall. It was
invented by Alberto Brandolini in the context of domain-
driven design (DDD).
19
https://www.thoughtworks.com/radar/techniques/event-storming

Domain Event
An event that occurs in the business process. Written in past tense.
Issue
An issue or question that needs to be clarified and resolved.
Business Process
Processes commands according to business rules. Creates 1..* domain events.
Aggregate
Cluster of domain objects that can be treated as a single unit.
Command
A command executed on an aggregate that results in the creation of a domain event.
External System
A third-party service provider such as a payment gateway or shipping company.
View
A view that users interacts with to carry out a task in the system.
1.Domain Event Storming
Domain Events in Vergangenheitsform auf Post-Its
schreiben. Chronologisch anordnen.
2.Story Telling
Moderiert durch den Prozess führen. Post-Its neu
anordnen, Duplikate entfernen.
3.Functional Refinement
Suchen und finden von fachlichen Kontexten und
Sollbruchstellen in den Prozessen
4.Technical Refinement
Weitere Unterteilung. Mögliche Indikatoren: Size,
Isolation, Speed, Redundanz

picture alliance / United Archive
8 Fallacies of Distributed Systems
1. The network is reliable
2. Latency is zero
3. Bandwidth is inﬁnite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The networks is homogeneous

1. The network is reliable
Problem: Netzwerk-Aufrufe werden fehlschlagen.
• Circuit Breaker und Retries sind eine Lösung, aber oft ein Pﬂaster.
• Service Meshes können helfen, bringen aber zusätzliche Komplexität und
Overhead. Istio, Linkerd, et.al. -> Service Mesh Interface (SMI)
• Nutze Event-driven Architecture (EDA) für lose gekoppelte Systeme. Neue
Herausforderungen: Protokolle, Delivery Garantien, Message-Codierung
• Zahlreiche spannende CNCF Projekte z.B. CloudEvents, OpenMessaging
22
https://landscape.cncf.io/category=streaming-messaging&format=card-mode&license=open-source

2. Latency is zero
Problem: Netzwerk-Aufrufe haben eine Verzögerung. Das n+1 Problem.
• Schicke alle benötigten Daten mit möglichst wenigen (1) Requests.
• Es gibt Alternativen zu REST: GraphQL, eﬃziente Binärprotokolle, gRPC.
• Umsetzung von B4F und API-Gateway Patterns zur Server-side Daten-Aggregation.
• Inversion of Control: Nutzung von Pub/Sub Mechanismen, Server-sent Events, Web
Sockets, Local Storage
• Die Daten müssen näher zum Client. Nutzung von Availability Zones, Content Delivery
Networks und intelligentes Caching.
23
https://landscape.cncf.io/category=remote-procedure-call&format=card-mode&license=open-source

3. Bandwidth is inﬁnite
Problem: Natürlich ist die Bandbreite limitiert.
• Große und komplexe Objekt-Graphen sollten vermieden werden.
• Übertrage nur die Daten die wirklich benötigt werden. Das steht im
Konﬂikt mit Latency is zero.
• Domain Driven Design hilft bei der Partitionierung der Domäne und der
Daten-Modelle in Bounded Contexts.
• CQRS ermöglicht optimierte Datenmodelle für Schreibende und
Lesende Use Cases.
24

4. The network is secure
Problem: Das Netzwerk ist unsicher.  
„Running workloads in the cloud is easy - doing it securely and in a compliant way is hard.“
• Security by Design -> Continuous Security -> Continuous Compliance.
• Layered-Security Ansatz: Absicherung auf Netzwerk, Infrastruktur, Plattform und
Anwendungsebene. Free eBook.
• 4C’s of Cloud Native Security: Cloud, Cluster, Container, Code. 
https://kubernetes.io/docs/concepts/security/overview/
• Nutzung von Distroless Images. https://github.com/GoogleContainerTools/distroless
• Zero Trust per Default: mTLS zwischen Services per Service Mesh und SPIFFE.
• Compliance per GitSec und Phylake -> Open Policy Agent (OPA), Kubernetes, Istio, Falco
25
https://landscape.cncf.io/category=security-compliance&format=card-mode&license=open-source

5. Topology doesn’t change
Problem: Netzwerk Topologien ändern sich ständig.
• Abstraktion der physischen Netzwerk-Struktur. Nutzung von DNS oder
Discovery Services.
• Cloud-native API Gateways sorgen für zusätzliche Location Transparency.
• Cattle, not pets. Treat Clusters Like Cattle. Immutable Infrastructure.
• Regelmäßige Chaos-Tests zur Überprüfung der Robustheit: Netﬂix Chaos
Monkey, kube-monkey, Chaos Toolkit, Gremlin, …
26
https://landscape.cncf.io/category=chaos-engineering&format=card-mode&license=open-source

6. There is one administrator
Problem: Diese 1 Person die alles weiß gibt es nicht.
• Jeder im Team ist für den Release Prozess verantwortlich. Frühzeitiges involvieren aller
beteiligten Stakeholder. DevOps.
• Klare Deﬁnition der DevOps-Topologie, Rollen, Verantwortlichkeiten, SLOs und SLAs.
• Manuelle Änderungen an der Infrastruktur sind tabu! GitOps heißt das Stichwort!
• Weave Flux: https://github.com/weaveworks/ﬂux
• Automatisierte CI/CD Pipeline: Knative Build, Spinnaker, Drone, GitLab, JenkinsX, …
• Seales Secrets: https://github.com/bitnami-labs/sealed-secrets
27
https://landscape.cncf.io/category=continuous-integration-delivery&format=card-mode&license=open-source

7. Transport cost is zero
Problem: Transport cost is not zero.
• Zwei Seiten der Medaille:
• Kosten für Netzwerk-Infrastruktur. Egal ob On-Premise oder Cloud.
• Kosten (CPU Zeit) für Serialisierung und Deserialisierung.
• Möglichst Eﬃziente Nutzung der Infrastruktur.
• XML ist teurer als JSON. JSON ist teurer als Binärprotokolle.
28

8. The networks is homogeneous
Problem: The network is not homogeneous.
• Nutzung von Standard-Formaten um Vendor Lockin zu vermeiden.
• XML, JSON, Protocol Buffers.
29

 
DevOps Anti-Type, e.g. DevOps Team Topologies, e.g.
https://web.devopstopologies.com
DevOps Team Silo
Dev Don’t Need Ops
Rebranded SysAdmin
Dev and Ops Collaboration Fully Shared Ops Responsibilities
SRE Team (Google Model) DevOps Advocacy Team
Ops as Infrastructure-as-a-Service DevOps as External Service

Improve your
inner development loop and the
Cloud Native DevEx
of your teams!

Optimiert die Cloud Native DevEx
32
vs.
https://www.datawire.io/guide/development/development-environments-microservices/

33
vs.

34
vs.

35
vs.

Zahlreiche Tools helfen dabei den Inner Development
Loop einfacher und eﬃzienter zu machen.
• The Rise of the IDE: Plugins, Plugins, Plugins. Beispiele: Cloud Code,
OpenShift Extension
• Squash enables easy remote debugging of running microservices in
Kubernetes und OpenShift from within your IDE.
• Kustomize, Draft, Skaffold, oder Tilt für Continuous Development. 
Die verschiedenen Entwicklungs-Phase werden zusammenfasst in
einem CLI Command. Der Entwickler Workﬂow wird vereinfacht.
36
https://tilt.devhttps://draft.sh https://skaffold.dev

Skaffold Workﬂow and Architecture
37
$ skaffold init 
$ skaffold dev
Demo repository https://github.com/lreimer/jakartaee8-java11

Telepresence verspricht schnelle lokale Entwicklung
für Kubernetes und Openshift Microservices.
38
Laptop
Source Code
Lokaler
Service
TelepresenceClient
IDE
Remote Kubernetes Cluster
TelepresenceProxy
Service A
Service B
Database
Queue
https://www.telepresence.io
2-way
Network
Proxy

Serverless
ist die nächste logische Evolution im
Cloud Native Software Engineering.
39

Kein Server ist einfacher zu verwalten, als kein Server!
Werner Vogels, CTO, Amazon

–https://landscape.cncf.io/
„Serverless computing refers to a new model of
cloud native computing, enabled by architectures
that do not require server management to build and
run applications. It leverages a ﬁner-grained
deployment model where applications, bundled as
one or more functions, are uploaded to a platform
and then executed, scaled, and billed in response to
the exact demand needed at the moment.“
41

Funktionen
sind das bevorzugte
aber nicht das einzige
Programmiermodell
von Serverless Apps.

Hybrid Architecture Use Cases
• Kombination von Microservice
Architektur mit EDA
• Nutzung von Function Services für
Event-getriebene Use Cases
• Reduzierter Ressourcen-Verbrauch
per Scale-to-Zero
• Integration in bestehende
Enterprise PaaS Umgebung
43
Shared Enterprise PaaS
Microservices
Function Services FaaS Platform
X Y ZF1 F2 Fn
DevOps
S1 S2 Sn L M T

• Fission ist eine schnelle und komplette Platform
mit Unterstützung für viele Sprachen.
• Knative ist eine K8s-basierte Plattform um
Serverless Workloads zu bauen und zu betreiben.
• Kubeless ist einfach und leichtgewichtig.
• Nuclio ist super schnell, mit kleinem Footprint
und vielen Triggern.
• OpenFaaS ist sehr populär mit einer aktiven und
guten Community. Schnell. ARM Support.
• Kyma positioniert sich als komplette Enterprise
Serverless Platform mit vielen Features.
• https://github.com/lreimer/the-big-faas-lebowski

YOUR CLOUD NATIVE
FUTURE IS SO BRIGHT,
YOU NEED SHADES.

Mario-Leander Reimer
Chief Software Architect, QAware GmbH
mario-leander.reimer@qaware.de
https://www.qaware.de
https://speakerdeck.com/lreimer/ 
https://github.com/lreimer/
&

Enterprise Cloud Native ist das neue Normal

Enterprise Cloud Native ist das neue Normal

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Enterprise Cloud Native ist das neue Normal

Similar to Enterprise Cloud Native ist das neue Normal(20)

More from QAware GmbH

More from QAware GmbH(20)

Enterprise Cloud Native ist das neue Normal