Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dipping Your Toes Into Cloud Native Application Development

1,599 views

Published on

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.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Dipping Your Toes Into Cloud Native Application Development

  1. 1. Dipping Your Toes Into Cloud Native Application Development
  2. 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. 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. 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. 5. 5By Dubwise Version https://www.flickr.com/photos/dubwise_version/4718137117
  6. 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. 7. Why care about cloud native? 7
  8. 8. 8By: Fernando Frazão/Agência Brasil Speed and Flexibility
  9. 9. 9 Almost No Downtime By: Marcin Wichary
  10. 10. What does cloud native really mean? 10
  11. 11. “container packaged, dynamically scheduled, and microservices based application development and operations.” – Cloud Native Computing Foundation (CNCF) 11
  12. 12. “container packaged” 12By Sergio Morchon https://www.flickr.com/photos/smorchon/2431349077/
  13. 13. Containers isn’t just Docker… 13
  14. 14. Does this mean I can’t do cloud native with VMs? 14
  15. 15. “dynamically scheduled” 15
  16. 16. Method 1: You Manage It 16 Object Storage Chef, Ansible, or Puppet Network Compute Compute Compute Compute Compute Compute Compute Compute
  17. 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. 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. 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. 20
  21. 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. 22. Managing Apps and a Datacenter as a Computer 22
  23. 23. What You Can Use Today 23
  24. 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. 25 Monolithic App Monolithic App Monolithic App Monolithic App … Micro Micro Micro Micro Micro Micro Micro Micro Micro Micro Micro Micro Micro
  26. 26. Potential Network Problem Don’t let the network be your bottleneck 26
  27. 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. 28. Reuse connections 28
  29. 29. HTTP/2 and Pipelining 29
  30. 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. 31. Store config in the environment 31
  32. 32. Treat backing services as attached resources 32 µ
  33. 33. Execute the app as one or more stateless processes 33
  34. 34. Treat logs as event streams (stdout) 34
  35. 35. Pets vs cattle 35
  36. 36. Updating Applications 36
  37. 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. 38. Blue / Green Deployments Start with Green 38 RouterUsers App App App App App App App App
  39. 39. Blue / Green Deployments Switch to Blue 39 RouterUsers App App App App App App App App
  40. 40. Canary Release 40
  41. 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. 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. 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. 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. 45. 3 Paths To Cloud Native: 1. Migration 2. Greenfield 3. Additive 45
  46. 46. Path 1: Migrating 46
  47. 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. 48. 3x Web Apps + more coming 48
  49. 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. 50
  51. 51. 51
  52. 52. 52 aPaaS
  53. 53. 53 Development Platform
  54. 54. 54
  55. 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. 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. 57. Continuous Integration is about trust 57https://commons.wikimedia.org/wiki/File:CISV_trust_game.JPG
  58. 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. 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. 60. Started With A Mono App 60 Stackato memcached MySQL Filesystem Service App 1 Big Mono App
  61. 61. Started With A Mono App 61 Stackato memcached MySQL Filesystem Service App 1Slightly Smaller Big App App 1Microservice (App 2)
  62. 62. Path 2: Greenfield 62
  63. 63. Start With Your Setup 63 Computer REST API
  64. 64. Setup CI 64 Environment 1 Stackato Environment 2 Stackato Environment 3 Stackato Personal Environment(s) CI/CD (Code Engine / Jenkins) GitDev
  65. 65. Built a Cloud Native Application 65 Stackato DB DB DB User Interface Service1 Service2 Service3 Service4 ServiceN … SaaS
  66. 66. Built a Cloud Native Application 66 Docker DB DB DB User Interface Service1 Service2 Service3 Service4 ServiceN … SaaS
  67. 67. Automation and ChatOps FTW 67
  68. 68. Path 3: Additive 68
  69. 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. 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. 71. Monitor Everything 71 Webserver Webserver Webserver MongoDB MongoDB MongoDB MongoDB Webserver Stackato Service 1 Service 2 Load Balancers Load BalancersUsers
  72. 72. Monitor Intelligently If you didn’t monitor it did it happen? 72
  73. 73. Tools You Can Use 73
  74. 74. 74
  75. 75. Datacenter/Cluster as a Computer Make it easy for developers 75 Computer REST API Thing that deploys
  76. 76. Start With A Platform Think Datacenter as a Computer 76
  77. 77. Lifecycle Management Consider Helm when using Kubernetes 77 Kubernetes REST APIHelm (to manage deployment)
  78. 78. CI/CD The CI/CD System Make it easy for developers 78 Computer REST APIThing that deploys GitDev
  79. 79. CI/CD Systems There are just so many 79
  80. 80. Some Are Container Based By Default 80
  81. 81. ChatOps 81
  82. 82. Config service 82
  83. 83. Monitor Everything 83
  84. 84. GitHub Scientist Plus others following suit with more language support 84
  85. 85. GitHub Scientist http://githubengineering.com/scientist/ 85
  86. 86. Questions?Matt Farina @mattfarina mattfarina.com / hpe.com 86

×