Datacomm Kubernetes as a Service Product Launch

1. F26173-201211
CONFIDENTIAL Designator
Cloud-Native
Journey
1

2. @burrsutter bit.ly/teachingelephants
@burrsutter bit.ly/teachingelephants

3. Going cloud native: Where to start?
3
Optimize what you have and Innovate your new future
Speed - Safety - Scale
Develop & deploy new
applications faster
Modernize & integrate
existing applications
Automate & optimize
application infrastructure
Cloud Native Development

4. What kind of application platform will you need?
4
Process Infrastructure Architecture
Waterfall Datacenter Monolith
CICD DevOps Any Cloud (Micro)Services
Lean, collaborative and fully
automated software delivery
lifecycle
Write once, run anywhere. On-
demand Scale, Fault tolerant by
design and advance deployments.
Loosely-coupled, modular
apps are easier to build, test,
deploy, update and change.
Manage change by structuring teams & their work to utilize
automation and architecture of cloud computing to boost innovation velocity
Cloud Native Development

5. RED HAT TECH READY 2020
CONFIDENTIAL - INTERNAL AND PARTNER
UNDER NDA USE ONLY
5
(Micro)services
Containers
Domain
modeling
APIs +
Integration
Architecture and
design practices
Agile, DevOps
team structures
Cloud-native team
enablement
Value delivery on
open hybrid cloud
Development
workflow
Secure, automated
container pipeline
Applications
Public | Private | Hybrid
Cloud-native development journey
Iterative feedback
Measured outcomes

6. GENERAL DISTRIBUTION
Kubernetes: Container Orchestration Engine
6
DevOps with Containers and Kubernetes
IMAGE
REGISTRY
SELF-SERVICE
APP. SERVICES
APP. LIFECYCLE MANAGEMENT
MONITORING AND LOGGING
OVERLAY NETWORK

7. F26173-201211
CONFIDENTIAL Designator
DIY K8s
vs
Red Hat
Openshift
7

8. What’s needed to put Kubernetes into production?
Enterprise Linux
Cluster services
monitoring,
showback, registry,
logging
Application services
middleware, functions, ISV
Service mesh
Developer services
dev tools, automated
builds, CI/CD, IDE
Automated operations
certified
Lacks many essential components
1. Operating system
2. Developer tooling and UX
3. Container runtime (CRI-O, Containerd, Docker,
etc).
4. Image registry
5. Software-defined networking
6. Load‐balancer and routing
7. Log management
8. Container metrics and monitoring
9. DNS
10. Ingress
11. RBAC
1
2
11 10
3 6 7 4 5 8 9
The customer (or third-party) must configure,
integrate, operate and support additional
components to be fully operational.

9. “Kubernetes” vs. Red Hat OpenShift

10. Developer Productivity
Cluster Services
Automated Ops ⠇Over-The-Air Updates ⠇Monitoring ⠇Registry ⠇Networking ⠇Router ⠇KubeVirt ⠇OLM ⠇Helm
10
Kubernetes
Developer CLI ⠇VS Code
extensions ⠇IDE Plugins
Code Ready Workspaces
CodeReady Containers
Service Mesh ⠇Serverless
Builds ⠇CI/CD Pipelines
Full Stack Logging
Chargeback
Databases ⠇Languages
Runtimes ⠇Integration
Business Automation
100+ ISV Services
Platform Services Application Services Developer Services
Physical Virtual Private cloud Public cloud
OpenShift
Kubernetes
Engine
Build Cloud-Native
Apps
Manage Workloads
Multi-cluster Management
Discovery ⠇Policy ⠇Compliance ⠇Configuration ⠇Workloads
Advanced
Cluster
Management
OpenShift
Container
Platform
Managed cloud
(Azure, AWS, IBM)
Red Hat Enterprise Linux & RHEL CoreOS
OpenShift is 100% certified Kubernetes
Red Hat OpenShift = Enterprise Kubernetes

11. Based on the open Eclipse Che project (>10M pulls)
Devfiles provide developer environments as code
Extensible with VS Code extension compatibility
Code Ready Workspaces
11
Cloud-Native IDE for secure and fast code development
Onboard developers faster
Easily monitor and operate with Prometheus and
Grafana dashboards
Reduce risk of security vulnerabilities in applications

12. What's new in OpenShift 4.6
Connectivity mode
- Allows developers to focus on the
composition of their application, both on
how it’s managed as well as how things are
connected.
Parity between List & Graphical
- Display Options
- Filters
- Find
Admin’s Project-> Workload tab has
an increased feature set
Consumption mode
- Allows developers to focus solely on
components consuming resources.
- Thus, no connectors are shown (Service
Binding, Visual, Traffic, Triggers, etc), nor
groupings. Pod count is shown by default.
Application topology
12

13. What's new in OpenShift 4.6
Monitor your applications with ease!
● Improved discoverability of alerts in topology
and Monitoring
● Easy access to Alert Details
● Alerts tab allows users to view application alerts
& silence them as as needed
● Monitoring your sample application Quick Start
available to show users how to access basic
monitoring features
Product Manager: Christian Heidenreich
13
Application Monitoring & Troubleshooting

14. What's new in OpenShift 4.6
Abstract Fluentd configuration by introduce new log
forwarding API to improve support and experience
for customers.
● Introduce a new, cluster-wide ClusterLogForwarder CRD (API)
that replaces needs to configure log forwarding via Fluentd
ConfigMap.
● The API helps to reduce probability to misconfigure Fluentd
and helps bringing in more stability into the Logging stack.
● Features include: Audit log collection and forwarding, Kafka
support, namespace- and source-based routing, tagging, as
well as improvements to the existing log forwarding features
(e.g. syslog RFC5424 support).
● WARNING: We will not automagically migrate old Tech
Preview CRs into a GA CR.
Infra
App
Audit
Forward logs to
different systems
based on their
“inputSource”.
inputSource=app
inputSource=audit
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
spec:
outputs:
- name: MyLogs
type: Syslog
syslog:
Facility: Local0
url: localstore.example.com:9200
pipelines:
- inputs: [Infrastructure,
Application, Audit]
outputs: [MyLogs]
Introduce new log forwarding API
14