This document provides an overview and agenda for a developer 2 developer webcast series on microservice architecture and container technologies. It includes details on upcoming webcasts in March and April 2017 focused on microservice architecture, Azure container service, Pivotal cloud foundry, and RedHat OpenShift. The document also advertises a webcast on RedHat OpenShift presented by John Archer on containerization with OpenShift and how it enables modern application development.

1. Developer 2 Developer
Building microservices webcast series
Ravi Tella - Microsoft
John Archer - Red Hat

2. Microservice architecture → 3/03/2017
Azure container service → 3/10/2017
Pivotal cloud foundry → 3/31/2017
RedHat OpenShift → 4/28/2017
Developer 2 Developer
RedHat OpenShift

3. Content:
http://aka.ms/houaz

4. @OpenShift
RHOpenShift
OpenShift on Azure
John Archer
Senior AppDev Solution Architect
Energy Pod
@archerj

5. APPLICATIONS
New ways of developing,
delivering and integrating
applications
INFRASTRUCTURE
Modernize existing and
build new cloud based
infrastructure
PROCESS
More agile processes
across both IT and the
business
5
Digital Transformation
There is Evolution in...

6. Containers - Transform Apps, Infrastructure & Process
6

7. ● Enable efficiency and automation for
microservices, but also support
traditional applications
● Enable faster and more consistent
deployments from Development to
Production
● Enable application portability across 4
infrastructure footprints: Physical,
Virtual, Private & Public Cloud
Containers - An Evolution in Application Deployment
7

8. What Are Containers?
● Sandboxed application processes
on a shared Linux OS kernel
● Simpler, lighter, and denser than
virtual machines
● Portable across different
environments
● Package my application and all of
its dependencies
● Deploy to any environment in
seconds and enable CI/CD
● Easily access and share
containerized components
INFRASTRUCTURE APPLICATIONS
It Depends on Who You Ask
8

9. Understanding Containers

10. Virtualization vs Containerization

11. Infrastructure as Code in Containers

12. GUEST OS
HARDWARE
HOST OS (RHEL/ATOMIC)HOST OS (RHEL)
LIBS A LIBS B LIBS...
APP A APP B
Traditional ContainerVirtualized
TRADITIONAL VS. VIRTUALIZED VS. CONTAINERS
HARDWAREHARDWARE
LIBS A
APP A
HYPERVISOR
CONTAINER CONTAINER
LIBS A LIBS B
APP A APP B
CONTAINER
LIBS C
APP C
GUEST OS
LIBS A
APP A
GUEST OS
LIBS A
APP A

13. Cloud Service Models
COMPUTE RESOURCES
(CPU, RAM, NETWORK, DISK)
VIRTUAL GUEST IMAGES
OPERATING SYSTEM
APPLICATION PLATFORM
(App Server, Middleware, Languages)
APPLICATION
Automated and Managed by
the Cloud Provider
Provided and Controlled by
Cloud Consumer
IaaS PaaS SaaS
Increased Control
Increased Automation
DEVELOPER TOOLING
(IDE, Source Control, Build Tools, CI)

14. Cloud Service Models
COMPUTE RESOURCES
(CPU, RAM, NETWORK, DISK)
VIRTUAL GUEST IMAGES
OPERATING SYSTEM
APPLICATION PLATFORM
(App Server, Middleware, Languages)
APPLICATION
Automated and Managed by
the Cloud Provider
Provided and Controlled by
Cloud Consumer
IaaS CaaS SaaS
Increased Control
Increased Automation
DEVELOPER TOOLING
(IDE, Source Control, Build Tools, CI)

15. PaaS + CaaS
A Distributed Cloud Application Platform
Code Deploy Run
Save Time and Money
Code your app
Push-button
Deploy, and
your App is
running in the
Cloud!

16. Born in 2011

17. Community Powered Innovation

18. SERVICE CATALOG
(LANGUAGE RUNTIMES, MIDDLEWARE, DATABASES, …)
SELF-SERVICE
APPLICATION LIFECYCLE MANAGEMENT
(CI / CD)
BUILD AUTOMATION DEPLOYMENT AUTOMATION
CONTAINER CONTAINERCONTAINER CONTAINER CONTAINER
NETWORKING SECURITYSTORAGE REGISTRY
LOGS &
METRICS
CONTAINER ORCHESTRATION & CLUSTER MANAGEMENT
(KUBERNETES)
RED HAT ENTERPRISE LINUX
CONTAINER RUNTIME & PACKAGING
(DOCKER)
ATOMIC HOST
INFRASTRUCTURE AUTOMATION & COCKPIT
OpenShift Container Platform - Stack
Build, Deploy and Manage Containerized Apps
Build RUNTIME

19. RED HAT CONFIDENTIAL
Pipelines Supported Out Of The Box

20. RED HAT CONFIDENTIAL
OpenShift provides multiple Deployment Models.
.. we don’t force a certain way. Enterprises can
adopt the change at their own pace.

21. Kubernetes Contributors

22. Application Services
JBoss EAP
JBoss Web Server
JBoss Data Grid
JBoss Dev Studio
JBoss Ops Network
Red Hat MobileNGINX
Juniper Networks
Crunchy DB
& More
JBoss Fuse
JBoss AM-Q
JBoss Data Virt
3Scale
JBoss BRMS
JBoss BPM Suite
Red Hat Software
Collections
Red Hat Container
Catalog
Red Hat
SSO
Red Hat
Storage
Docker Hub
OpenShift
Primed
Your
Private
Registries

23. Facilitating a rich container ecosystem
Represented by a broad coalition of
industry leaders focused on common
standards for software containers
Create and drive the adoption of a new
computing paradigm that is optimized for
modern distributed systems

25. RED HAT CONFIDENTIAL
Self Service Model
Developer time is too expensive to wait for provisioning VMs
Code Deploy Run
Save Time and Money
Code your app
Push-button
Deploy, and
your App is
running in the
Cloud!

26. Start with Source Code - S2I

27. Deploy a Container Image

28. Deploy a Dockerfile

29. Deploy a Binary Artifact

30. Run a CI/CD Pipeline on OpenShift Cluster

31. Use your existing CICD Pipeline to
Deploy to OpenShift

32. Build locally with an all-in-one cluster on
your Workstation

33. RED HAT CONFIDENTIAL
Zero Downtime Deployments
Blue/Green, Canary Deployments, AB testing.. Out of the box.
Language Agnostic, No Code Intrusion

34. 10,000 foot overview

35. RED HAT CONFIDENTIAL
NEXT-GEN ECOSYSTEMS

36. RED HAT CONFIDENTIAL
THE APPSERVER 2000-2014
36
Framework / APIs
Middleware Services
Operational Platform
App App
Persistence | Security | Transaction | Messaging | HTTP
Deployment | Management | Monitoring | HA | Logging
Virtual Machine | Operating System
App AppApp App

37. RED HAT CONFIDENTIAL
Runtime
App
Cloud Platform
Data
Build | Deploy | Scheduling | Scaling | Elasticity | Metrics | Logging
Security IMDG Messaging
Runtime
Svc
Runtime
Svc
Cloud Provider
THE APPSERVER 2014 - ...

38. RED HAT CONFIDENTIAL
38
50% OF THE
ENTERPRISE APP
MARKET
WHERE DEVELOPERS ARE GOING

39. RED HAT CONFIDENTIAL
39
● Enable a new class
of modern apps
● Remain committed
to our customers
and existing
workloads
● Continue to be a
trusted advisor for
new workloads and
customer
engagements
OUR CHALLENGE

40. RED HAT CONFIDENTIAL40
JBoss EAP
Existing, Java EE,
Spring MVC
WildFly
Swarm
Monolith
Decomposition,
Enterprise Java
MSA
Fast Monoliths
(Java EE, Spring)
Tomcat
Spring Boot /
MVC
JBoss WS
Tomcat,
Spring MVC,
SpringBoot
Greenfield
Reactive Java
Java EE - mono to
micro. / greenfield
vert.x
Reactive Java
/ Polyglot
MSA
Node.js
Reactive
client /
server-side
JavaScript
Greenfield
polymorphic
JavaScript
FaaS /
Server-le
ss
Existing Applications New Applications
Spring
Cloud
Java
MSA
Greenfield
Java / Spring
MSA

41. RED HAT CONFIDENTIAL
Opinionated Development for OpenShift
Integrating language
runtimes with OpenShift
and middleware services
Opinionated approach to
developing for a
containerized environment
Accelerating path to
business value

42. Openshift 3.5 on Azure
https://github.com/glennswest/azure-openshift

43. Reference Architecture Overview
•Openshift 3.5 automatically deployed on Azure
• 3 Availability sets – master, infra, and nodes
• 2 Load Balancers – Web Console/API and Application Routers
• Registry via Azure Blob Storage
• 3 – 30 Compute Nodes
• 3 Masters
• 3 Infrastructure
• Storage by Generic Storage Profile on top of Azure VHD
• Automatically created and provisioned disk via Azure Cloud Provider
• Automation by Azure Resource Manager and Ansible

44. Deployment via Form or CLI

45. Deployment via form
Fill out the form
RedHat Login
Machine Sizes
Openshift Login
SSH Keys
Azure AD Login Credentials

46. Deployment
•Once information provided
• All hosts, networks and resources are
created by ARM template
• Openshift Install is automatically started by a
Azure extenstion, launching bastion.sh
• Bastion.sh kicks off:
• Ansible install of openshift
• Setup of Registry
• Setup of PV and Storage Accounts
• Generic Storage Profile

47. Openshift Console

48. Openshift Persistent Volume For MongoDB

49. Docker Registry on Azure Blob Storage

50. Master Availability Set

51. Master API/Console Load Balancer

52. Integrated support
In-portal customer experience for PAYG
deployments
Co-located support with Red Hat on-site
team
ISO 27001 compliant B2B
communication channel
Integrated support is available 24x7 for
Cloud Access (BYOS) as well as
On-Demand (PAYG) deployments
Microsoft Help
+ Support
Red Hat
Customer Portal
Flexibility in support channels
SSO access to Red Hat support
Co-location and
cross-product support
Microsoft Azure
support
Red Hat
support
Ticket exchange platform
Cross-team hand off

53. Agility
Secure Manageable Supported
Integrated
support
Log correlation
and app insights
Item-level
restore
Identity
management
Threat insights
Master Nodes Infrastructure Nodes App Nodes

54. Integrated support
Integrated support is available for many Red Hat
solutions in Azure:
Red Hat Enterprise Linux®
Red Hat Enterprise Linux® for SAP HANA
Red Hat Gluster Storage
Red Hat OpenShift Container Platform
Red Hat JBoss® Middleware portfolio,
including Fuse and BRMS
Red Hat CloudForms
Microsoft Help
+ Support
Red Hat
Customer Portal
Flexibility in support channels
SSO access to Red Hat support
Co-location and
cross-product support
Microsoft Azure
support
Red Hat
support
Ticket exchange platform
Cross-team hand off

55. Key takeaways
The cloud is where open enterprise
innovation is happening
Microsoft Azure offers the security,
manageability and support you’ve
come to expect from Red Hat
solutions
Microsoft and Red Hat have a unique
partnership that includes joint
portfolio and engineering, global
reach and integrated, co-located
support
2
3
1 +
Azure
=
Agility
Secure Manageable Supported

56. OpenShift
Architecture Overview

57. OpenShift runs on your choice of infrastructure

58. Nodes are instances of RHEL where apps will run

59. Apps and components run in containers
Container
Image
Container
Pod

60. Pods are the orchestrated unit in OpenShift

61. Masters are the Control Plane

62. API and Authentication

63. Desired and Current State

64. Scheduler Pulls From The Registry

65. Orchestration and Scheduling

66. Placement by Policy

67. Services connect application components

68. Health and Scaling

69. What about unhealthy Pods?

70. The Master remediates Pod failures

71. What about app data?

72. Routing layer for external accessibility

73. Access via Web UI, CLI, IDE, API

74. OpenShift
Source-to-Image

75. Source 2 Image Walk Through
Code
Build
Deploy
Container
Image
Registry

76. Source 2 Image Walk Through
Code
Developers can leverage existing
development tools and then access
the OpenShift Web, CLI or IDE
interfaces to create new application
services and push source code via
GIT. OpenShift can also accept
binary deployments or be fully
integrated with a customer’s
existing CI/CD environment.

77. Source 2 Image Walk Through
Container
Image
Registry
Build
OpenShift automates the Docker
image build process with
Source-to-Image (S2I). S2I
combines source code with a
corresponding Builder image from
the integrated Docker registry.
Builds can also be triggered
manually or automatically by setting
a Git webhook. Add in Build
pipelines

78. Source 2 Image Walk Through
Container
Image
Registry
Deploy
OpenShift automates the
deployment of application
containers across multiple Node
hosts via the Kubernetes
scheduler. Users can automatically
trigger deployments on application
changes and do rollbacks,
configure A/B deployments & other
custom deployment types.

79. Backup
K8S concepts

80. You instantiate a container image
to get a container..
Just like Object instantiated from
a Class

81. So where does the container
image come from?
Images are stored in a Container
Registry

82. OpenShift/K8s puts your
container inside a Pod.
Pod is a wrapper. Gets an ip
address.
Container adopts Pod’s ip

83. Some pods may have more than
one container.. that’s a special
case though!!
All the containers in a pod die
along with a pod.

84. When you scale up your
applicatioin component, you are
scaling up pods..

85. Pods get distributed on your
cluster.. They may land on
different nodes
So as a client do I need to deal
with all these pod ips? .. wait

86. Pods can be frontended by a
Service.
Service is a proxy.. Every node
knows about it.
Service gets an ip
Service knows which pods to
frontend based on the labels

87. By changing the labels end points
of service change

88. Clients can talk to the service.
Service redirects the requests to
the pods.
Service also gets a DNS Name
Client can discover service… built
in service discovery!!

89. When you want to expose a
service externally eg: access via
browser using a URL, you create
a “Route”
Route gets added to a HAProxy
LB.
You can configure your F5 as
well as LB.