Why new deployments

should default to

(Public) Cloud

Kurt Garloff

OpenStack Cloud Architect

kurt.garloff@t-systems.com

CeBIT, 20.-24.3.2017, Hannover

https://slides.com/kgarloff/automation-with-otc-api-1-1

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?

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

https://cloud.telekom.de/blog

https://github.com/OpenTelekomCloud

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

OpenStack Powered (DefCore) - Marketplace

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

Open Telekom Cloud

Resources

Open Build Service

RPMs / DEBs (uvp-tools, otc-tools, openstackclient, ...)

home:garloff:OTC

OpenTelekomCloud Blog

https://cloud.telekom.de/blog

Slides

https://slides.com/kgarloff/

ImageFactory

https://imagefactory.otc.t-systems.com/

github

Community / Foundation

Questions &

Call to Action

Adopt DevOps

Migrate to Public Cloud Architecture

Chose OpenStack

Use Open Telekom Cloud

Automate

Contact: /me

kurt.garloff@t-systems.com

t-systems@garloff.de

Cheat Sheet

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

OTC Service Catalog

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 ...