Meetup Cloud Native Night Mainz, Dezember 2022, Mario-Leander Reimer (@LeanderReimer, Principal Software Architect bei QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Die einfache und effiziente Entwicklung Cloud-nativer Anwendungen stellt viele Teams vor erhebliche Herausforderungen. Denn zusätzlich zur Umsetzung fachlicher Features und Microservices sind Entwickler nun oft auch für den Aufbau der benötigten Cloud-Services mit Infrastructure as Code à la Terraform mitverantwortlich.
Die damit verbundene hohe kognitive Last (Cognitive Load) führt leider schnell zu Überlastung und suboptimalen Lösungen. Aber es geht einfacher!
Dieser Vortrag zeigt den praktischen Einsatz nützlicher Frameworks, um Cloud-Infrastruktur einfach und schnell durch Feature-Teams provisionieren zu lassen.
3. “Too much cognitive load will become a bottleneck for fast
flow and high productivity for many DevOps teams.”
QAware | 3
■ Intrinsic Cognitive Load
Relates to fundamental aspects and knowledge in the
problem space (e.g. used languages, APIs, frameworks)
■ Extraneous Cognitive Load
Relates to the environment (e.g. console
command, deployment, configuration)
■ Germane Cognitive Load
Relates to specific aspects of the business domain
(aka. „value added“ thinking)
4. A Platform team and its engineers are a key enabler for high
productivity of stream-aligned DevOps teams.
QAware | 4
■ Responsible to build and operation a platform to
enable and support the teams in their day to day
development work.
■ The platform aims to hide the inherent complexity
to reduce the cognitive load for the other teams.
– Standardization
– Self-Service
■ Fully automated software delivery is the goal!
https://hennyportman.wordpress.com/2020/05/25/review-team-topologies/
6. Cloud-native
Application Engineering
Cloud-native
Platform Engineering
The 5 Layers of Cloud-native Software Engineering
QAware | 6
IaaS
Network, Compute, Storage
(VPC, EC2, NLB, ALB, ...)
CaaS
(Kubernetes Services)
PaaS
(Software Infrastructure Blueprints with Helm and
Continuous Delivery Toolchain)
Application-specific
Software Infrastructure
Cloud-friendly & cloud-native
Applications
Architect Build Run
Amazon SNS
AWS IAM
Amazon
EC2
Amazon EBS
7. The 5 Layers of Cloud-native Software Engineering
QAware | 7
IaaS
Network, Compute, Storage
(VPC, EC2, NLB, ALB, ...)
CaaS
(Kubernetes Services)
PaaS
(Software Infrastructure Blueprints with Helm and
Continuous Delivery Toolchain)
Application-specific
Software Infrastructure
Cloud-friendly & cloud-native
Applications
Architect Build Run
Amazon SNS
AWS IAM
Amazon
EC2
Amazon EBS
?
8. Why not model cloud infrastructure
as Kubernetes resources?
9. Custom Resource Definitions are user-defined, declarative
extensions of the Kubernetes API
QAware | 9
■ Abstraction of complex application constructs and concepts
■ Definition solely via CustomResourceDefinitions
■ Structure definition via OpenAPI v3.0 Validation Schema
■ Default Support for several API Features: CRUD, Watch, Discovery,
json-patch, merge-patch, Admission Webhooks, Metadata, RBAC, …
■ Versioning und Conversion supported via Webhooks
12. Operators are codified Ops procedures!
QAware | 12
■ Operators are the path towards Zero-Ops. They enable
auto-updating, self-monitoring and self-healing infrastructure
and applications.
■ The concept was coined in the Kubernetes world. It’s now been
adopted and used widespread in the cloud native world.
■ Examples: OKD, Sealed Secrets, Kube Monkey, Weave Flux,
Crossplane, and many more …
19. Config Connector Addon for Google Kubernetes Engine
QAware | 19
■ Define and use Google Cloud resources directly from Kubernetes. No need to define
resources outside the cluster using traditional IaC tools.
■ Config Connector can be added during GKE installation or later
■ Some in-cluster configuration required after initial setup
■ Requires a dedicated service account with suitable permissions
■ Currently all major Google services and resources supported
■ https://cloud.google.com/config-connector/docs/reference/overview
21. Manage AWS services using the Amazon Controllers for
Kubernetes (ACK)
QAware | 21
■ Define and use AWS service resources directly from Kubernetes. No need to define
resources outside the cluster using traditional IaC tools.
■ Each ACK service controller is packaged into a separate container image and Helm chart
■ Uses IAM Roles for Service Accounts (IRSA) to automate the provisioning and rotation of
temporary IAM credentials
■ Currently 20 different controllers with RELEASED status available, however, most of these
are still in PREVIEW maintenance phase
■ https://aws-controllers-k8s.github.io/community/
23. Crossplane in a Nutshell
QAware | 23
■ Open Source Kubernetes Add-on. Universal Control Plane for Cloud Infrastructure.
■ Cloud Infrastructure Services can be defined declaratively by application teams
■ Platform teams can provide relevant cloud infrastructure services via high level
self-services APIs
■ Individual Provider bundle a set of Managed Resources with their controllers. All major
cloud providers are supported, e.g. AWS, GCP, Azure, Alibaba, …
■ Managed Resources are fine granular representations of external cloud resources
■ Composite Resource Definitions or XRDs enable the definition and creation of new
abstractions for composite managed resources
■ https://crossplane.io
25. Kubernetes Cluster API
QAware | 25
■ Official Kubernetes sub-project
■ Declarative APIs and tooling to
provision, upgrade, and operate
multiple Kubernetes clusters
■ Work in different environments, both
on-premises and in the cloud
■ Reuse and integrate existing ecosystem
components rather than duplicating