From c1b76e1235a1a0f1bd5e4f1e501db80bd0adb56e Mon Sep 17 00:00:00 2001
From: Monty Taylor
Date: Thu, 2 Jun 2016 05:03:32 +0300
Subject: Add cloud native fallacy talk
---
src/talks/fallacy.hbs | 228 ++++++++++++++++++++++++++++++++++++++++++++++++
src/talks/who-cares.hbs | 196 +++++++++++++++++++++++++++++++++++------
2 files changed, 395 insertions(+), 29 deletions(-)
create mode 100644 src/talks/fallacy.hbs
(limited to 'src/talks')
diff --git a/src/talks/fallacy.hbs b/src/talks/fallacy.hbs
new file mode 100644
index 0000000..bf8936d
--- /dev/null
+++ b/src/talks/fallacy.hbs
@@ -0,0 +1,228 @@
+
+
+
+
+
+
+ The Cloud Native Fallacy: You are not Google, or How to Stop Worrying and Learn to Love your Servers
+
+
+
+
+
+ Who am I?
+
+ Distinguished Engineer
+ IBM Cloud
+
+
+
+ Who am I?
+
+ Technical Committee
+ Foundation Board of Directors
+ Developer Infrastructure Core Team
+
+
+
+
+
+
+
+ Is Cloud Native good?
+ yes
+
+
+
+ Is not-Cloud Native bad?
+ no
+
+
+
+ Do you need to write Cloud Native apps to use cloud?
+ no
+
+
+
+ Are you a bad person if don't write Cloud Native apps?
+ no
+
+
+
+ What is Cloud Native?
+
+
+
+ Cloud-native applications are meant to function "in a world of cloud
+ computing that is ubiquitous and flexible." Applications can be
+ developed on a cloud platform, then deployed to different clouds where
+ supporting software stacks will help them run at scale.
+ Information Week - Jul 30, 2015
+
+
+
+ The Cloud Native Computing Foundation will harmonize emerging
+ technologies and foster innovation in container packaged, dynamically
+ scheduled, and microservices based application development and
+ operations.
+
+
+
+ Cloud Native Is ...
+
+ - Architectural and operational approach
+ - Assume cloud
+ - Assume failures
+ - Microservices
+ - Containerized?
+
+
+
+
+
+
+
+
+ 12 Factor Application
+ I. Codebase - One codebase tracked in revision control, many deploys
+ II. Dependencies - Explicitly declare and isolate dependencies
+ III. Config - Store config in the environment
+ IV. Backing services - Treat backing services as attached resources
+ V. Build, release, run - Strictly separate build and run stages
+ VI. Processes - Execute the app as one or more stateless processes
+ VII. Port binding - Export services via port binding
+ VIII. Concurrency - Scale out via the process model
+ IX. Disposability - Maximize robustness with fast startup and graceful shutdown
+ X. Dev/prod parity - Keep development and production as similar as possible
+ XI. Logs - Treat logs as event streams
+ XII. Admin processes - Run admin/management tasks as one-off processes
+
+
+
+
+
+
+ Except for III
+ I use config files
+
+
+
+ VI. Stateless
+ If /dev/null is fast in web scale I will use it. Is it web scale?
+ Use a service to store your data - like a database
+ Is that database service web scale?
+
+
+
+ Go google and watch "MongoDB is Web Scale"
+
+
+
+ A Foolish Consistency is the Hobgoblin of Little Minds
+
+
+
+ Cloud Native / 12 Factor is **A** great approach
+ You still have to think.
+
+
+
+ As an application developer,
+ I want to deploy and run an application on the internet
+ so that my customers all over the world can consume it.
+
+
+
+ As an operator,
+ I want to deploy the application across multiple clouds
+ so that my service survives issues in any one of them.
+
+
+
+ THIS WORKS
+ I'm doing it myself as we speak
+
+ 10-20k VMs per-day
+ 10 Cloud Regions in 7 clouds
+ Only using OpenStack APIs
+
+
+
+
+
+
+
+ Our VMs are everywhere
+
+ - Rackspace: Dallas, Chicago, DC
+ - Internap: New York
+ - OpenStack Innovation Center: San Antonio
+ - OVH: Strassbourg, Gravelines
+ - Vexxhost: Montreal
+ - Blue Box: San Jose
+ - Red Hat: Phoenix
+
+
+
+
+ We also have servers
+ Infra Cloud - Hardware donated by HPE
+
+
+
+ Architecture
+
+
+
+
+ Gerrit
+
+ -
+ Traditional 'Enterprise' Java Application
+ - Nova VM, Cinder Volume, Trove DB
+ - Scale out farm of git replicas
+
+
+
+
+ nodepool
+
+ - Cloud Native
+ - Purpose built in Python
+ - Keeps a pool of ready to go nodes
+ - Multi-cloud
+ - Fully elastic - responds to demand
+
+
+
+
+ Run what you want
+ 12-factor application on Kubernetes with Kuryr
+ Traditional Java web application behind NAT with a Floating IP
+ Kerberos Server on the Internet with Fixed IP and Reverse DNS
+ Baremetal for hardware enabled transcoding via Ironic
+
+
+
+
+
+
+
+ DevOps recognizes the need for Dev and Ops to collaborate
+
+
+
+ Rigid devotion to any guidelines without judgement is deadly
+
+
+
+
diff --git a/src/talks/who-cares.hbs b/src/talks/who-cares.hbs
index f2675a4..fdc1d2d 100644
--- a/src/talks/who-cares.hbs
+++ b/src/talks/who-cares.hbs
@@ -63,7 +63,7 @@
10-20k VMs per-day
- 3 (soon to be 6) clouds
+ 10 Cloud Regions in 7 clouds
Only using OpenStack APIs
@@ -102,33 +102,30 @@
18 Terabytes of Log Data in six months
-
- We have no servers
-
- - Rackspace Public Cloud
- - HP Helion Public Cloud
- - TripleO Community Cloud hosted at RedHat
-
-
- Coming soon:
-
- - OVH Public Cloud
- - Blue Box Dedicated Cloud on SoftLayer
- - Infra Cloud hosted at HP
- - IBM Public Cloud
-
-
-
-
Our VMs are everywhere
+ Public Clouds
- - HP: Las Vegas, DC
- Rackspace: Dallas, Chicago, DC
- - RedHat: Phoenix
+ - Internap: New York
- OVH: Strassbourg, Gravelines
+ - Vexxhost: Montreal
+ - OpenStack Innovation Center: San Antonio
+
+ Private Clouds
+
- Blue Box: San Jose
- - IBM: Amsterdam, Dallas, Franfurt, Hong Kong, Houston, London, Montreal, Paris, Querétaro, San Jose, São Paulo, Seattle, Singapore, Sydney, Tokyo, Toronto, DC
+ - Red Hat: Phoenix
+
+
+
+
+ We also have servers
+ Infra Cloud
+
+ - Hardware donated by HPE: Houston
+ - Community run cloud using OpenStack Puppet
+ - Bare Metal managed with Bifrost/Ironic
@@ -181,6 +178,141 @@
+
+
+
+ Control plane
+ http://git.openstack.org/cgit/openstack-infra/system-config
+
+ - All server config management in git
+ - Puppet manages the servers: puppet apply
+ - Ansible runs puppet: ansible puppet module
+ - Ansible OpenStack Dynamic Inventory
+ - Only thing not public are keys and secrets
+
+
+
+
+ os-client-config
+ http://git.openstack.org/cgit/openstack/os-client-config
+ A library to handle config information for openstack clients
+ Tracks differences in vendors that can't be discovered
+ In use in python-openstackclient and ansible
+
+
+
+ os-client-config
+ ~/.config/openstack/clouds.yaml
+
+clouds:
+ vexxhost:
+ profile: vexxhost
+ auth:
+ project_name: d8af8a8f-a573-48e6-898a-af333b970a2d
+ username: 0b8c435b-cc4d-4e05-8a47-a2ada0539af1
+ password: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ region_name: ca-ymq-1
+ dreamcompute:
+ profile: dreamhost
+ auth:
+ username: montay6
+ project_name: dhc2111978
+ password: XXXXXXXXXXXXX
+ region_name: RegionOne
+
+
+
+
+ shade
+ http://git.openstack.org/cgit/openstack-infra/shade
+ A library to wrap business logic around client libraries
+
+cloud.create_image('image-name', filename='image-filename.qcow2')
+cloud.create_server('my-server', image='immage-name', auto_ip=True)
+
+ In use in Infra Nodepool and ansible
+
+
+
+ ansible
+ Brand new modules, based on shade
+ Part of 2.0 release
+
+- os_keypair:
+ cloud: hp-mordred
+ name: mordred
+ public_key_file: ~/.ssh/id_rsa.pub
+- os_image:
+ cloud: hp-mordred
+ name: Monty Ubuntu
+ file: ubuntu.vhd
+- os_server:
+ cloud: hp-mordred
+ name: my-server
+ flavor_ram: 1024
+ image: Monty Ubuntu
+
+
+
+
+ ansible
+ multi-cloud support
+
+- os_keypair:
+ cloud: "{{ item }"
+ name: mordred
+ public_key_file: ~/.ssh/id_rsa.pub
+ with-items:
+ - vexxhost
+ - rackspace
+ - ovh
+
+
+
+
+ Ansible Role Cloud Launcher
+ http://git.openstack.org/cgit/openstack/ansible-role-cloud-launcher
+
+profiles:
+ - name: admin-clouds
+ flavors:
+ - name: aoclcompany.xlarge
+ ram: 128
+ vcpus: 1
+ - name: ops
+ images:
+ - name: ubuntu-trusty
+ filename: /home/ubuntu/trusty-server-cloudimg-amd64-disk1.img
+ - name: bootstrap-keypair
+ keypairs:
+ - name: bootstrap-key
+ public_key_file: /home/ubuntu/.ssh/id_rsa.pub
+clouds:
+ - name: awesomecloud
+ profiles:
+ - admin-clouds
+ - bootstrap-keypair
+ - name: yaycloud-ops
+ oscc_cloud: yaycloud-opsuser
+ profiles:
+ - bootstrap-keypair
+ - ops
+
+
+
+
+ nodepool
+
+ - Use shade to treat all cloud regions as one giant cloud
+ - diskimage-builder makes identical base images for each
+ - Pre-cache network artifacts in disk images
+ - glean instead of cloud-init to handle no-DHCP on Rackspace
+ - Pre-spins warm pool - always keep min-ready number of nodes
+
+
+
OpenStack Works!
Why should you care?
@@ -218,7 +350,7 @@
Put it near your users
Don't put it in an NSA data center
Locality Requirements
- What if you have customers in Suriname?
+ What if you have customers in Hungary?
@@ -273,17 +405,23 @@
CityCloud: Sweden, UK
Elastx: Sweden
Datacentred: UK
- Ultimum: Prague
Enter Cloud Suite: Italy, Germany, Frankfurt
Internap: Netherlands, US
- Ultimum: Prague
+ Ultimum: Czech Republic
+ Zetta: Norway
+
+
+
+ Managed Private Cloud
+ Bluebox: an IBM Company
+
+ - Blue Box Dedicated: In any Softlayer Data Center Worldwide
+ Blue Box Local: In your data center
- Global Reach
- Blue Box Dedicated: In every Softlayer Data Center Worldwide
- Including right here in Amsterdam
- Blue Box Local: Same thing, but in your DC
+ Private Cloud Distro
+ Not listing them - I can't possibly remember them all