Mario-Leander Reimer presented on building cloud-native .NET microservices with Kubernetes. He discussed key principles of cloud native applications including designing for distribution, performance, automation, resiliency and elasticity. He also covered containerization with Docker, composing services with Kubernetes and common concepts like deployments, services and probes. Reimer provided examples of Dockerfiles, Kubernetes definitions and using tools like Steeltoe and docker-compose to develop cloud native applications.

1. Mario-Leander Reimer
mario-leander.reimer@qaware.de
@LeanderReimer
Cloud-native .NET Microservics
mit Kubernetes
Mainz, 28. September 2017

2. Mario-Leander Reimer
Chief Technologist, QAware GmbH
Contact Details
Phone: +49 89 23 23 15 121
Mail: mario-leander.reimer@qaware.de
Twitter: @LeanderReimer
Github: https://github.com/lreimer
2
Developer & Architect
20+ years of experience
#CloudNativeNerd
Open Source Enthusiast
QAware

3. Let‘s talk about Cloud Native Applications.
3QAware

4. DISRUPT
4
CLOUD NATIVE APPLICATIONS
INDUSTRIALIZE
OPEX SAVINGS
(automation & utilization)
ANTIFRAGILITYHYPERSCALE
TRAFFIC, DATA, FEATURES
DEVOPS &
CONTINUOUS DELIVERY
QAware

5. BUILT AND COMPOSED
AS MICROSERVICES
3KEYPRINCIPLES
5
CLOUD NATIVE APPLICATIONS
PACKAGED AND
DISTRIBUTED IN CONTAINERS
DYNAMICALLY
EXECUTED IN THE CLOUD
QAware

6. Robert A. Heinlein, 1966, The Moon Is a Harsh Mistress
„There ain’t no such thing
as a free lunch.“

7. 7
The 5 Cloud Commandments:
1. Everything Fails All The Time.
2. Focus on MTTR not MTTF.
3. Know the Eight Fallacies of Distributed Computing.
4. Scale out, not up.
5. Treat resources as cattle not as pets.
picture alliance / United Archive

8. Design Principles for Cloud Native Applications.
8
Design for Distribution: Containers; microservices; API driven development.
Design for Performance: Responsive; concurrent; resource efficient.
Design for Automation: Automated Dev & Ops tasks.
Design for Resiliency: Fault-tolerant and self-healing.
Design for Elasticity: Scales dynamically and reacts to stimuli.
Design for Delivery: Short roundtrips and automated provisioning.
Design for Diagnosability: Cluster-wide logs, metrics and traces.
QAware

9. Different Levels of Cloud Native Application Maturity.
9
Scales dynamically based on stimuli.
Dynamic infrastructure migration without
service downtime.
Level 3: Cloud Native
Fault tolerant and resilient design.
Metrics and monitoring built-in.
Runs anywhere. Infrastructure agnostic.
Level 2: Cloud Resilient
Consists of loosely coupled systems.
Services can be found by name.
Adheres to the 12-factor app principles.
Level 1: Cloud Friendly
No file system requirements.
Runs on virtualized hardware.
Executed as self-contained image.
Level 0: Cloud Ready
https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf
QAware

10. The Anatomy of the Cloud Native Stack.
10
How to decouple
from physical
hardware?
How to provide the
right resources for
container execution?
How to run (containerized)
applications on a cluster?
How to automate standard
operations procedures?
What infrastructure
to provide to cloud
native applications?
QAware

12. Specific Cloud Native Stack with .NET Core + Steeltoe
OSS and Kubernetes.
QAware 12

13. (1) Microservices
(2) Containerization
(3) Composition
(4) Orchestration
The 4 Phases of Cloud Native Application Development.
13QAware

14. Microservices

15. 15
Cloud Native Application Development: Components All
Along the Software Lifecycle.
DESIGN BUILD RUN
§ Complexity unit
§ Data integrity unit
§ Coherent and cohesive
features unit
§ Decoupled unit
§ Planning unit
§ Team assignment unit
§ Knowledge unit
§ Development unit
§ Integration unit
§ Release unit
§ Deployment unit
§ Runtime unit
(crash, slow-down, access)
§ Scaling unit
1:1 n:1
QAware

16. 16
Dev Components Ops Components?:1
System
Subsystems
Components
Services
Good starting point
Decomposition Trade-Offs
Microservices
Nanoservices
Macroservices
Monolith
+ More flexible to scale
+ Runtime isolation (crash, slow-down, …)
+ Independent releases, deployments, teams
+ Higher utilization possible
- Distribution debt: Latency
- Increasing infrastructure complexity
- Increasing troubleshooting complexity
- Increasing integration complexity
QAware

17. A simple microservices using .NET Core and Steeltoe.
17
https://github.com/lreimer/cloud-native-basta17
QAware

18. Steeltoe OSS enables developers to implement Cloud-
native .NET microservices with ease.
QAware 18
Steeltoe client libraries enable .NET Core and .NET Framework apps to leverage Netflix Eureka, Hystrix,
Spring Cloud Config Server, and Cloud Foundry services.
Services that enable .NET and ASP.NET developers to leverage Spring Cloud:
Configuration Server client
Service Discovery client
Hystrix Circuit Breaker
Management endpoints
Services that simplify using .NET and ASP.NET on Cloud Foundry:
Connectors (e.g. MySql, Redis, Postgres, RabbitMQ, OAuth, etc)
Configuration providers
Security providers (OAuth SSO, JWT, Redis Key Ring Storage, etc.)
Logging providers

19. Containerization

20. Hardware vs. OS Virtualization.
20
Real Hardware
Virtual Hardware
OS
OS Libraries
Application
Real Hardware
(Virtual Hardware)
OS
OS Libraries
Application
HSI*
SCI*
Hardware Virtualization OS Virtualization
Private Copy
Shared ResourcesVirtualMachine
Container
Isolated Hardware Isolated NW-interface, process space, file system
*) HSI = Hardware Software Interface
SCI = System Call Interface
§ Less volume of private copy
§ Near zero runtime overhead
§ Short start-up time
§ Stong isolation
QAware

21. Developer‘s Perspective of the Docker Workflow.
21
$ docker build -t cloud-native-basta17:1.0.1 .
$ docker run --name cloud-native-basta17 -d
-p 5000:5000 cloud-native-basta17:1.0.1
$ docker stop cloud-native-basta17
$ docker start cloud-native-basta17
$ docker tag cloud-native-basta17:1.0.1
lreimer/cloud-native-basta17:1.0.1
$ docker push lreimer/cloud-native-basta17
QAware

22. FROM microsoft/dotnet:1.1.4-runtime
MAINTAINER Mario-Leander Reimer <mario-leander.reimer@qaware.de>
# defined working directory and copy the published output
WORKDIR /cloud-native-basta17
COPY out .
# define the entry point for this container
# run the application and bind to network interfaces
EXPOSE 5000
ENTRYPOINT ["dotnet", "cloud-native-basta17.dll"]
CMD ["--server.urls", "http://0.0.0.0:5000"]
Example Dockerfile.
22QAware

23. Some Useful Tips on using Docker.
23
A Dockerfile is code! Treat it as 1st class citizen.
Know your base image. Size matters.
Chain RUN commands. Use intelligent layering.
Remove temporary files and directories.
Define ENV variables for important parameters.
Use one image for all your environments.
Version your images.
Use quality tools to check Dockerfiles and images.
QAware

24. Composition

25. Microservices need an Ecosystem to run in.
25
How to access
endpoints from
the outside?
How to expose
and find service
endpoints?
How to execute an
ops component?
How to call other
endpoints resilient
and responsive?
How to detect and
resolve operational
anomalies?
How to provide cluster-
wide configuration and
consensus?
QAware

26. 26QAware

27. Conceptual View on Infrastructure Composition.
27QAware

28. version: '3'
services:
eureka: ...
config-server: ...
cloud-native-basta17:
build: .
image: lreimer/cloud-native-basta17
environment:
- EUREKA_HOST=eureka
depends_on:
- eureka
- config-server
ports:
- “5000:5000"
networks:
- backend
Example docker-compose.yml
28
$ docker-compose build
$ docker-compose up –d --build
$ docker-compose logs
$ docker-compose down
QAware

29. Orchestration

30. echo "- The default provider is GCE"
export KUBERNETES_PROVIDER=gce
export KUBE_GCE_ZONE=europe-west1-d
export NUM_NODES=4
echo "- Another possible provider is AWS"
export KUBERNETES_PROVIDER=aws
export KUBE_AWS_ZONE=eu-central-1a
export NODE_SIZE=t2.small
curl -sS https://get.k8s.io | bash
Easy K8s setup: Local, Bare Metal, Cloud or Managed.
30QAware

31. Conceptual View on Kubernetes Building Blocks.
31QAware

32. Services are an abstraction for a logical
collection of pods.
Pods are the smallest unit of compute in
Kubernetes
Deployments are an abstraction used to
declare and update pods, RCs, …
Replica Sets ensure that the desired
number of pod replicas are running
Labels are key/value pairs used to identify
Kubernetes resources
Config Maps store K/V pairs that can be
passed to containers as ENV variables or as
volume mounts.
Most important Kubernetes concepts.
32QAware

33. Single or Multi Container Pods?
33QAware

34. K8s Deployment Overview.
34QAware

35. K8s-only Deployment Variation.
35QAware

36. apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: cloud-native-basta17
spec:
replicas: 4
template:
metadata:
labels:
app: cloud-native-basta17
spec:
containers:
- name: cloud-native-basta17
image: "lreimer/cloud-native-basta17"
ports:
- containerPort: 5000
env:
- name: EUREKA_HOST
value: eureka
Example K8s Deployment Definition.
36QAware

37. resources:
# Define resources to help K8S scheduler
# CPU is specified in units of cores
# Memory is specified in units of bytes
# required resources for a Pod to be started
requests:
memory: "128Mi"
cpu: "250m"
# the Pod will be restarted if limits are exceeded
limits:
memory: "192Mi"
cpu: "500m"
Define Resource Constraints carefully.
37QAware

38. # container will receive requests if probe succeeds
readinessProbe:
httpGet:
path: /admin/info
port: 5000
initialDelaySeconds: 30
timeoutSeconds: 5
# container will be killed if probe fails
livenessProbe:
httpGet:
path: /admin/health
port: 5000
initialDelaySeconds: 90
timeoutSeconds: 10
Liveness and Readiness Probes for Actuator endpoints.
38QAware

39. apiVersion: v1
kind: Service
metadata:
name: zwitscher-service
labels:
app: cloud-native-basta17
spec:
# use NodePort here to be able to access the port on each node
# use LoadBalancer for external load-balanced IP if supported
type: NodePort
ports:
- port: 5000
selector:
app: cloud-native-basta17
Example K8s Service Definition.
39QAware

40. Programmable MIDI Controller.
Visualizes Deployments and Pods.
Scales Deployments.
Supports K8s, OpenShift, DC/OS.
http://github.com/qaware/kubepad/
Let‘s have some fun with K8S!
40QAware

42. No magic! Just complex technology.
42
Building distributed systems is hard!
.NET Core and Steeltoe OSS hide most of the inherent complexity.
High abstraction: Boon and Bane of software development.
Developers and architects need additional skills and know-how.
Favour gradual transition over big bang cloud migration.
QAware

43. Sources and some articles to read @ home …
43
https://github.com/lreimer/cloud-native-basta17
Der Cloud Native Stack: Mesos, Kubernetes und Spring Cloud
https://goo.gl/U5cJAU
Spring Cloud und Netflix OSS: Cloud-native Anwendungen bauen
https://goo.gl/edNlUK
Cloud-native Anwendungen mit Kubernetes
https://goo.gl/dVkoyR
Eine Einführung in Apache Mesos: Das Betriebsystem der Cloud
https://goo.gl/7SnMZA
QAware

44. QAware 44

45. Mario-Leander Reimer
mario-leander.reimer@qaware.de
@LeanderReimer github.com/lreimer
linkedin.com/qaware slideshare.net/qaware
twitter.com/qaware xing.com/qaware