Presented at CloudDevelop 2016 Building cloud native applications in containers is a new hot topic. Netflix and Google are two prime examples that have been doing it successfully for some time. Some of the new exciting projects like Docker and Kubernetes are focused on cloud native applications in containers. There are supposed to be numerous benefits including the ability to scale applications out easily while doing development on small systems like laptops, the ability for the system to handle some operational problems, and the capability to safely deploy updates to production many times per day. But, what does this look like in practice and how do you start the move to cloud native and containerized applications? In this session we'll look at what makes up a cloud native application, how they work, and how you can start small. We'll look at applications from an architecture and process point of view along with how you can deploy them to AWS, Azure, or Google Cloud. You'll walk away ready to start development on a cloud native app.

1. Dipping Your Toes Into Cloud
Native Application
Development

2. Who is this guy?
– mattfarina.com, @mattfarina
– Principal Engineer, Advanced Technology
Group, Hewlett Packard Enterprise
– Go, Node.js, PHP, Ruby, Python, .NET… in
just past 5 years
– Recently wrote book, “Go in Practice”
– Co-lead Kubernetes SIG Apps
– Likes to build things in the cloud
– Doesn’t like bullet lists
2

3. 3By Swaminathan https://www.flickr.com/photos/araswami/2284451064/
Been doing cloud for 6 years and cloud
native for 4 years. Yes, there is a
difference

4. 4By Ted Silveira https://www.flickr.com/photos/cafebongo/14062452417/
Went from a large monolithic pet app to
a cloud native application through a
practical process

5. 5By Dubwise Version https://www.flickr.com/photos/dubwise_version/4718137117

6. 1.Why care about cloud native
development?
2.What is cloud native?
3.What tools can be used?
4.How can you get from here to
there?
6

7. Why care about
cloud native?
7

8. 8By: Fernando Frazão/Agência Brasil
Speed and Flexibility

9. 9
Almost No Downtime
By: Marcin Wichary

10. What does cloud
native really
mean?
10

11. “container packaged,
dynamically scheduled,
and microservices based
application development
and operations.”
– Cloud Native Computing Foundation (CNCF)
11

12. “container packaged”
12By Sergio Morchon https://www.flickr.com/photos/smorchon/2431349077/

13. Containers isn’t just Docker…
13

14. Does this mean I
can’t do cloud
native with VMs?
14

15. “dynamically scheduled”
15

16. Method 1: You Manage It
16
Object
Storage
Chef, Ansible, or Puppet
Network
Compute
Compute
Compute
Compute
Compute
Compute
Compute
Compute

17. But, what way do most desktop applications work?
Choice 1 Choice B
17
App Laptop
Desktop
Pro Desktop
App CPU(s)
RAM
Drives
NIC(s)

18. Method 2: Datacenter/Cluster as a Computer
18
Computer
• Could be a
datacenter, rack,
or single
computer
• Manages the
needed infra
and changes for
your apps for
you
• Think of it as
one computer
rather than
managed
collection
REST API

19. What’s Happening Inside The Computer?
19
Computer
REST API
Router
Scheduler
App 1 App 2
App 3 App 4
Storage
Config

20. 20

21. Combined Truth
21
ComputerREST API
Server
Server
Server Server
Server
Server
Router
Router
Router
Chef,
Ansible, or
Puppet
As app devs and operators see it What infra devs and operators do

22. Managing Apps and a Datacenter as a Computer
22

23. What You Can Use Today
23

24. “microservices based”
What is a microservice?
–Small
–Focused on doing one thing well (single responsibility principle)
–Independently deployable
–Clearly defined API for interaction
–Potentially reusable in other systems
24

25. 25
Monolithic App
Monolithic App
Monolithic App
Monolithic App
…
Micro Micro Micro Micro Micro
Micro
Micro
Micro
Micro
Micro
Micro
Micro
Micro

26. Potential Network Problem
Don’t let the network be your bottleneck
26

27. What makes a good REST API?
– Versioned, typically in the URL
– Use proper HTTP methods
– Behind Authentication and Authorization
– HTTP/2 if possible (for pipelines and connection reuse)
– TLS/HTTPS (encrypted transport)
– Proper HTTP response codes
– JSON
– Open API Initiative (Swagger)
27

28. Reuse connections
28

29. HTTP/2 and Pipelining
29

30. 12 Factor++ (12factor.net)
1. One codebase tracked in revision
control, many deploys
2. Explicitly declare and isolate
dependencies
3. Store config in the environment
4. Treat backing services as attached
resources
5. Strictly separate build and run
stages
6. Execute the app as one or more
typically stateless processes
containers
7. Export services via port binding
8. Scale out via the process model
containers
9. Maximize robustness with fast
startup and graceful shutdown
10.Keep development, staging, and
production as similar as possible
11.Treat logs as event streams
12.Run admin/management tasks as
one-off processes containers
30

31. Store config in the environment
31

32. Treat backing services as attached resources
32
µ

33. Execute the app as one or more stateless processes
33

34. Treat logs as event streams (stdout)
34

35. Pets vs cattle
35

36. Updating
Applications
36

37. 37
App
(online)
App
(online)
App
(online)
App
(offline)
App
(offline)
App
(offline)
App
(update)
App
(update)
App
(update)
App
(online)
App
(online)
App
(online)

38. Blue / Green Deployments
Start with Green
38
RouterUsers
App
App
App
App
App
App
App
App

39. Blue / Green Deployments
Switch to Blue
39
RouterUsers
App
App
App
App
App
App
App
App

40. Canary Release
40

41. Rolling Updates
41
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1

42. Rolling Updates
42
v2 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1

43. Rolling Updates
43
v2 v2
v1 v1
v2 v2
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v2 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1
v1 v1

44. Rolling Updates
44
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2
v2 v2

45. 3 Paths To Cloud Native:
1. Migration
2. Greenfield
3. Additive
45

46. Path 1: Migrating
46

47. My Web App Before The Cloud
47
This may look familiar
Webserver
Webserver
Webserver
Webserver
Load Balancers
Load BalancersUsers
Shared
filesystem
Via Gluster
memcached
memcached
memcached
memcached
MySQL
MySQL
MySQL
MySQL
MySQL had
master and slave
with fail over
Setup split
between two
physical locations
Individual servers managed by Chef in Prod, Test, and Dev environments

48. 3x Web Apps
+ more coming
48

49. … at the same time... Experiments in the cloud
49
Object Storage
VMVM VM
VM VM VM
Network
Users
Cloud resources managed by scripts and toolchains (like Chef)
Block
Storage

50. 50

51. 51

52. 52
aPaaS

53. 53
Development Platform

54. 54

55. Stackato Cluster(s)
Stackato Clusters
Production, QA, and Development Clusters
55
App 1
Load Balancers
Load BalancersUsers
memcached
memcached
memcached
MySQL
MySQL
MySQL
MySQL shifted over life of
cluster. In Stackato and
SaaS were used
Automation and scripts managed the clusters running on a IaaS (backed by
VMs, Networking, Block Storage, and Object Storage).
App 1
App 1
App 1
App 1
App 2
App 1
App 1
App N
…
Detected top level
problems and
handled some failover
Ops Managed Platform
Filesystem
Service

56. Stackato Clusters
Dev Process
56
Production
Stackato
QA
Stackato
Dev
Stackato
Personal
Environment(s)
CI/CDGitDev
Branch to environment:
master → production
QA → QA
devel → Dev
Production
and QA used
blue/green
deployments
with zero
downtime
Features work on
via feature
branches

57. Continuous Integration is about trust
57https://commons.wikimedia.org/wiki/File:CISV_trust_game.JPG

58. Continuous Integration brings reproducibility
58
https://en.wikipedia.org/wiki/Assembly_line#/media/File:Ford_assembly_line_-_1913.jpg https://en.wikipedia.org/wiki/KUKA_Systems#/media/File:Application_field_automotive.jpg

59. What is CD in CI/CD?
Continuous Delivery
Continuous Deployment
59
Code change
pushed
Test
code
Build
Image
Store
build
...
New build
detected /
chosen
Deploy to
environment

60. Started With A Mono App
60
Stackato
memcached
MySQL
Filesystem
Service
App 1
Big Mono App

61. Started With A Mono App
61
Stackato
memcached
MySQL
Filesystem
Service
App 1Slightly Smaller
Big App
App 1Microservice
(App 2)

62. Path 2: Greenfield
62

63. Start With Your Setup
63
Computer
REST API

64. Setup CI
64
Environment 1
Stackato
Environment 2
Stackato
Environment 3
Stackato
Personal
Environment(s)
CI/CD
(Code Engine /
Jenkins)
GitDev

65. Built a Cloud Native Application
65
Stackato
DB DB DB
User Interface
Service1
Service2
Service3
Service4
ServiceN
…
SaaS

66. Built a Cloud Native Application
66
Docker
DB DB DB
User Interface
Service1
Service2
Service3
Service4
ServiceN
…
SaaS

67. Automation and ChatOps FTW
67

68. Path 3: Additive
68

69. We had a traditional application
69
These were physical but could have been VM
Webserver
Webserver
Webserver
Load Balancers
Load BalancersUsers
MongoDB
MongoDB
MongoDB
MongoDB
Setup split
between multiple
physical locations
Individual servers managed by Chef in Prod, Test, and Dev environments
Webserver

70. Added Cloud Native Environment
70
The legacy environment was not retired
Webserver
Webserver
Webserver MongoDB
MongoDB
MongoDB
MongoDB
Legacy App called
to cloud native app
over REST API
Webserver
Stackato
Service 1
Service 2
Service 3
Service 4
Load Balancers
Load BalancersUsers

71. Monitor Everything
71
Webserver
Webserver
Webserver
MongoDB
MongoDB
MongoDB
MongoDB
Webserver
Stackato
Service 1 Service 2
Load Balancers
Load BalancersUsers

72. Monitor Intelligently
If you didn’t monitor it did it happen?
72

73. Tools You Can Use
73

74. 74

75. Datacenter/Cluster as a Computer
Make it easy for developers
75
Computer
REST API
Thing that deploys

76. Start With A Platform
Think Datacenter as a Computer
76

77. Lifecycle Management
Consider Helm when using Kubernetes
77
Kubernetes
REST APIHelm (to manage
deployment)

78. CI/CD
The CI/CD System
Make it easy for developers
78
Computer
REST APIThing that
deploys
GitDev

79. CI/CD Systems
There are just so many
79

80. Some Are Container Based By Default
80

81. ChatOps
81

82. Config service
82

83. Monitor Everything
83

84. GitHub Scientist
Plus others following suit with more language support
84

85. GitHub Scientist
http://githubengineering.com/scientist/
85

86. Questions?Matt Farina
@mattfarina
mattfarina.com / hpe.com
86