DevOps at Scale with Containers and the Cloud
•Download as PPTX, PDF•
0 likes•637 views
This is a presented at Canterbury Software Summit 2015 IBM Masterclass. There is an associated demo - to be uploaded to Youtube.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to DevOps at Scale with Containers and the Cloud
Similar to DevOps at Scale with Containers and the Cloud (20)
More from Alan Kan
More from Alan Kan (13)
Recently uploaded
Recently uploaded (20)
DevOps at Scale with Containers and the Cloud
- 1. With Containers and the Cloud Devops at Scale Alan Kan NZ Technical Leader – IBM Cloud and Digital Innovation @alankannet http://www.linkedin.com/in/zenmaster/
- 2. “Just a few seconds”
- 3. Micro Service Architecture increases the need for DevOps and Scale
- 4. 3 Success Factors for DevOps Scaling - Consistency - Capacity - Connectedness
- 5. Containers are efficient and portable QA server Development VM Customer Data Center Production ClusterPublic Cloud Static website User DB Analytics DBQueueWeb frontend Build Ship Ru n
- 7. Bluemix scales and automates +
- 8. What is Bluemix? Platform for Digital Innovation
- 9. How does Bluemix work? Bluemix is underlined by three key open compute technologies: Cloud Foundry, Docker, and OpenStack. It extends each of these with a growing number of services, robust DevOps tooling, integration capabilities, and a seamless developer experience. 9 Flexible Compute Options to Run Apps / Services Instant Runtimes Containers Virtual Machines Platform Deployment Options that Meet Your Workload Requirements Bluemix Public Bluemix Dedicated Bluemix Local* DevOps Tooling Your Own Hosted Apps / Services Integration and API Mgmt Powered by IBM SoftLayer In Your Data Center + + + + + Catalog of Services that Extend Apps’ Functionality Web Data Mobile AnalyticsCognitive IoT Security Yours + *Bluemix Local coming Q4 2015
- 10. Build Staging Prod Prod App code Docker file IBM Container Image Build Service Container Group (Auto-recovery) Bluemix DevOps Services Notifications Image Registry
- 11. Consistency + Capacity + Connectedness +
- 12. ibm.biz/bluemixrocks/ Thank you Alan Kan NZ Technical Leader – IBM Cloud and Digital Innovation @alankannet http://www.linkedin.com/in/zenmaster/
Editor's Notes
- Alexander Bell invented telephone in 1876. It was one that has a direct line to another phone. Not long after that, he proposed a design where a telephone can call more than one parties. That is the start of telephone exchanges. When it was first started, the telephone exchange has manual operators to connect the caller and the receiver. They physically plug cables into ports of the receiving party’s end to make the connection. The act of plugging in the cable only takes a few seconds. So the operator will respond to the calling party by saying “just a few seconds”. Telephone has gained popularity and within a few years, there are 10,000s customers. The telephone exchange hired a lot of telephone operators to cope with the massive demand. Wait time started to get longer – although the act of plugging in the cables only takes a few seconds, the wait time for an operator to answer the phone is taking longer and longer. One caller – Almon Strawger – often gets to wait for a long time. Out of frustration, he decided to design an automated system to connect lines, which became the first automated telephone exchange. The rest is history. Although the simple action of plugging in the phone cable only takes a few seconds, in the face of massive scaling, it significantly increased wait time because it is a bottleneck. Often when we create our deployment process, we build semi-automated processes. We may use Jenkins to automate a few steps, and then have to go AWS to spin up a machine manually, or run a test script manually, before we run another deployment script for app server. Although the simple act of kicking off an automated script manually only takes a few minutes, in the face of massive scaling, this will become the bottleneck of the Devops process and slow it down significantly.
- If you only need to deploy one app twice a day, and it takes 5 minutes of manual process to intervene, then there is no scaling problem. That is only 10 minutes of your time in a day. However, if you are building an application that will scale, most likely you want to break a monolithic application down into micro services, like what Amazon did. Then you will have a lot more deployments because each microservice has its own deployment pipeline. Amazon deploys to production every 11 seconds. If it takes 5 minutes of manual process to deploy, then they have to hire 28 people just manually kick off deployment (and they don’t have lunch breaks, holidays and do not get sick!) Is this process scalable, or do you see a similar pattern to that of the telephone operators?
- That leads us to the 3 success factors of DevOps Scaling. Consistency has two aspects - environment consistency, and process consistency. Environment consistency refers to your development, test, staging, production environments having the same setup so that the application you deploy will behave the same way across these environments. Process consistency refers to the process for deploying your application is consistent – If the deployment is automated, then most likely it is consistent. If the deployment is manual following a set of instructions, then there is an increased risk of human error. If the deployment is entirely manual with no instructions, then you are inviting trouble. Capacity refers to the infrastructure required to run the devops process, and the ability to acquire more infrastructure when DevOps operations needs to scale. If the DevOps process is manual, then capacity refers to the ability to hire more people. If the process is automated, then it refers to the ability to add more computing power to run more DevOps processes. Connectedness has two aspects. The first is the DevOps process should be automated end-to-end with no manual intervention. As we mentioned previously, the manual steps in between automated steps hinders the scalability of the process. The 2nd aspect is how well people are connected in this process – does dev and ops both know the status of the process and have a common understanding? Does an automated process notify people?
- Docker is an open platform for building distributed applications for developers and system administrators. It enables application development efficiency, making deployment more efficient, eliminating vendor ‘lock-in’ with true portability. Open Software Launched March 2013 500+ million downloads of Docker images Open Contribution 1300+ contributors #2 most popular project 185 community meet-up groups in 58 countries Open Design Contributors include IBM, Red Hat, Google, Microsoft, VMware, AWS, Rackspace, and others Open Governance 12 member governance advisory board selected by the community An engine that enables any payload to be encapsulated as a lightweight, portable, self-sufficient container… …that can be manipulated using standard operations and run consistently on virtually any hardware platform This can potentially solve the consistency problem – imagine encapsulating your application and its dependencies in a container, and running the container on dev, test, staging & production. *Demo showing Dockerfile
- Cloud (IaaS) allows you to scale the running of your containers (chuck them on a cloud VM, don’t need to worry about Infrastructure constraints if you get a lot of users) Monitoring and logging, ability to scale if number of user increases, and the ability to automatically recover failed containers are all desirable when it comes to scaling. *Demo showing how to create a container on Bluemix (in particular features re auto-recovery and scaling group)
- Now you have applications running in containers, and you want to automate the delivery process, and scale DevOps process by leveraging the cloud. Bluemix is the platform for doing both.
- So what is Bluemix? IBM’s Platform for Digital Innovation A cloud-based platform for rapidly building, managing and running applications of all types (web, mobile, big data, social, ... ).
- Bluemix is built on top of IBM’s infrastructure as a service offering – SoftLayer. It allows you to run payloads in containers, VMs, and cloud foundry apps. It provides services that you can leverage to build an app faster, integrate securely with the backend, and DevOps Tooling. Bluemix is available as on premise, IBM hosted private cloud, and public cloud.
- Today we focus on DevOps Services that allows us to build an automated delivery pipeline for containers. Step 1: Build the delivery pipeline for containers on DevOps Services. (approx 6 mins) Step 2: Developer on local workstation forks project from alankan|hello-devops, make changes and commits code to git (DevOps Services). (approx 2 mins) Staging deploys one container, while prod deploys a container group. Groups are configured to auto-recover if one fails. Red/black deployment to ensure availability. Notifications go to slack or HipChat. While waiting for deployment to happen, look at Container GUI on Bluemix re monitoring, bare metal. Also mention ICE CLI available. After deployment, show build or staging log, access node.js of deployed container, and look at Slack or Hipchat. Alternatively use containers already prepared to show these.
- Summary: Today you have seen how I used Docker and Bluemix to create a DevOps process that leverage the cloud to scale. The process provides consistency, capacity and connectedness.