Kurt Garloff
Long time Open Source engineer and leader. Linux and OpenStack Clouds.
Why new deployments
should default to
(Public) Cloud
Kurt Garloff
OpenStack Cloud Architect
kurt.garloff@t-systems.com
Frühjahrsfachgespräche, 23.-24.3.2017, Darmstadt
Mode 1 Enterprise IT
Reliable
Highly available Infrastructure
Carefully planned
Avoiding
risks (by avoiding changes)
Evolving slowly
Managed by experts
Expensive
€€€€€
Software Companies
set the bar higher
Customer experience
Dynamic Adaptation
Scale
Cost
Multi-
Device
Multi-
Channel
Innovation
Service
oriented
Experimentation
Data
driven
DevOps beating Enterprise IT
vs.
More reliable (!)
How so?
Text
CI/CD
Test driven
Version Control
Redeployment
Microservices
Modular APIs
Autoscaling
Open Source
Building Blocks
Automation
Why Public Cloud?
It's not only technology ...
Classical Deployment
Cloud Installation
And the result is ...
What went wrong?
Culture
- Manual approvals
Technology
- Manual installations
Automation
Automating virtual Infrastructure
- DIY REST (curl, jq)
- libcloud
- ansible
- heat
- terraform
- juju
- bosh
- ...
OpenStack REST API
cloud-init
- controlled by meta-data src
- run upon boot
- user accounts, ssh keys
- hostname, timezone
- networks, mounts
- package updates & installation
- arbitrary scripts
- phone home
- subject VM to config mgmt
Config Mgmt Tools
- ansible, chef, saltstack, puppet
- run repeatedly to ensure compliance or changes
- configuration properties
- software packages
- can control infra as well
Application Management
What deployment model?
Private
Cloud:
- Often Enterprise Virtualization relabeled as cloud
- Limited elasticity
- CapEx
- Non-standard APIs
Recommendation: Build for
Hyperscale Public Cloud
Standard
APIs
Think multitenant
Elastic, pay per use
... you can still always go private or hybrid ....
Leverage
platform
services
Automate:
Redeployment, Scaling, Alarms
Cloud everywhere?
Use OpenStack
Freedom to use several providers
(e.g. for compliance, support, ...)
Freedom to host yourself
Powerful standardized API
Open Telekom Cloud
Tools & API
Text
Environment ~/.ostackrc
# Adapt the first three lines ...
export OS_PASSWORD="XXXXXXXXXXXXXXXXXX"
export OS_USERNAME="14610698 OTC00000000001000XXXXXX"
export OS_USER_DOMAIN_NAME="OTC00000000001000XXXXXX"
export OS_TENANT_NAME=eu-de
export OS_PROJECT_NAME=eu-de
export OS_AUTH_URL=https://iam.eu-de.otc.t-systems.com/v3
export OS_PROJECT_DOMAIN_NAME=
export OS_IDENTITY_API_VERSION=3
export OS_VOLUME_API_VERSION=2
export OS_IMAGE_API_VERSION=2
export OS_ENDPOINT_TYPE=publicURL
export NOVA_ENDPOINT_TYPE=publicURL
export CINDER_ENDPOINT_TYPE=publicURL
Template preinstalled in our images
Using OpenStack CLI tools
- Compute (nova v2) - Nova: 2.22.0 – 2.23.3 (Kilo)
- Images (glance v2) - Glance: 0.15.0 – 0.16.0 (0.17.x does not work, 1.1.0 does)
- Block Storage (cinder v2) - Cinder: 1.1.1 – 1.3.1 (all versions tested worked)
- Networking (neutron v2) - Neutron: 2.3.12 (newest versions fail)
- IAM (keystone v3) - Keystone: 1.3.4 (only libs needed, client itself deprecated)
- OpenStack: 1.0.4 – 1.5.x
OTC is based on OpenStack Juno Mitaka plus backports plus extensions ...
Recommended client tools
Preinstalled in CentOS7, openSUSE42 images (OBS)
docker container (Ubuntu) - docker pull tsiotc/otc-client/
Use pip otherwise
InterOp Challenge
Text
16 OpenStack based clouds
Same application (Wordpress, 4VMs)
Same automation (ansible + shade)
Text
Roll your own?
Setup, Operate, Maintain, Innovate
Economies of scale
OpenStack Powered (DefCore) - Marketplace
Community / Foundation
Open Telekom Cloud
OTC Service Catalog
Resources
Open Build Service
RPMs / DEBs (uvp-tools, otc-tools, openstackclient, ...)
OpenTelekomCloud Blog
Slides
ImageFactory
Call to Action
& Questions
Adopt DevOps
Migrate to Public Cloud Architecture
Chose OpenStack
Use Open Telekom Cloud
Automate
Apply for a job :-)
Cheat Sheet
| Service | openstack | OTC |
|---|---|---|
| compute (VMs) | nova v2 (server) | ECS |
| block storage | cinder v2 (volume) | EVS |
| object storage | [SWIFT] |
OBS (S3) |
| network |
neutron (net, router, floating IP) | VPC (EIP) |
| images |
glance v2 |
IMS |
| authentication |
(keystone v3) |
IAM / MyWorkPl |
| LoadBalancer |
neutron LBaaS | ELB / LBaaSv2 |
| Relat Database |
(trove) | RDS (1.0.1) |
| Containers | (magnum / k8s) | CCE (1.0.1) / k8s |
Containers
... will be the unit of management for many next generation applications
VMs beneath expected to be managed automatically?
Deployment models still emerging
Technologies still emerging
Docker, CoreOS, Kubernetes, Mesos, ...
OTC: Cloud Container Engine (Docker/Kubernetes)
since 1.0.1 (7/2016)
Ecosystem & Services
Conclusions
API support for Automation:
Needed for Agility and Scaling out
Clear commitment to provide native OpenStack APIs on Open Telekom Cloud is progressing
Demonstrated otc-tools, openstack native and ansible
Vast amount of API abstraction tools available
Broad tool support requires more than DefCore APIs
Credits
Hui-Bin Ma: Great support with API enablement
Christian Kortwich: API abstration tools survey
Zsolt Nagy: otc-tools (also python+Java tools)
Frank K / Reik K: ansible-otc
Bernd R & Anthony C: API testing ...
Public Cloud, OpenStack, OpenTelekomClound
By Kurt Garloff
Public Cloud, OpenStack, OpenTelekomClound
Kurt Garloff, FFG 2017: The default architecture for new (modern) applications should be cloud-native. Why this, why chose OpenStack and why OTC might be interesting.
