 Good afternoon, everyone, and thank you for attending today's session on DevOps. My name is Chris Vantyne, Chief Technologist for the Western Region at Red Hat. I've been with Red Hat for about 10 years, working with strategic partners and customers who are adopting Red Hat's emerging technologies. Red Hat has certainly moved well beyond Linux, in the middleware, software-defined storage, virtualization, and cloud management. And one of the hot topics around those technologies with our customers is around DevOps. DevOps is all about eliminating that wall that sits between operations and developers and doing things faster. Our customers are asking us questions like, how can we enable IT to be more efficient and reduce costs? How can we enable developers to be more productive and have access to the tools and platforms that they need? But ultimately, how can we enable the business to roll out products sooner and as they go? And so in today's session, I'm going to talk about the how, what, and why around DevOps, as well as a brief overview of some of the enabling technologies, such as Docker and Kubernetes, and wrap it up with a customer case study. And if we have time, I'll have some Q&A session. If not, I'll be outside and we can certainly follow up with any questions you have. So certainly, enterprise IT is an inflection point in terms of its history. With the movement to cloud and mobile applications, the how, what, and where of application development, architecture, and the underlying infrastructure is changing as well. There's a shift from waterfall development model to DevOps, from monolithic applications or interior applications to microservices with APIs, and a shift away from physical and virtual machines to containers running on physical or virtual infrastructure. And this is all happening to accelerate application delivery for the business, as well as improve overall product quality. And at a macro level, what's changing in the industry? A few short years ago, Mark Andreessen stated that software is changing the world. And for any of you travelers out in the audience, I'm sure you can relate how the travel industry is being transformed with software, whether it's mobile flight notifications so you can minimize your time at the airport, or whether it's the alerts that you get in terms of being able to sign up and get your notification and your mobile boarding pass to actually board the airplane, as well as your ability to hail a uber cab to get to the airport, or even cloud-based applications to do your expense reports, whether it's digital receipts or linking up with your credit card. As I made my way up from Los Angeles to Vancouver, I actually had to change my flight, so I logged into the website, and I was able to go in and request a flight change, and I got an error, and it said, call an 800 number, the dreaded 800 number, right? And so I got on my phone, called the 800 number, and it knew exactly who I was. It said, hey, Chris, thanks for calling, and it said, hey, I see that you tried changing your flight on the website, and you received an error. Let me connect you with an agent right away to resolve that issue. So it was quite amazing, and so software, just in a few short years, has really changed the travel industry and the customer experience, but it's not just the travel industry, right? There are other industries being transformed as well. The entertainment industry, DreamWorks Animation, looking to expand their brand, moving into mobile and online gaming with software. Cisco, seeing private and public cloud adoption really transform the requirements for networking. Seeing a shift of their customer base from desktop and laptop installed software to online, and this is really creating new service possibilities and the ability to quickly introduce new services to their customers. Likewise, Union Bank, representative of many banks across the globe, seeing a shift of their customer base from physical to online and mobile banking, and with this, they're able to rapidly introduce new services to their customers as well. But what is the impact to companies that fail to innovate and rest on their laurels? The San Francisco taxi industry is a perfect example of how software is disrupting existing businesses. Several years ago, Uber and Lyft entered the San Francisco market with their innovative use of software applications, and the impact that they're having on the industry is quite alarming. In 2012, a taxi driver averaged just over 1,400 rides per month. This has since plummeted by 65% to just over 500 rides per month now as of last summer, and I'm sure it's gotten worse. So these innovative startups are leveraging software mobile applications to transform that experience. From a taxi perspective, when I request a cab, I no longer have to wonder when will it show up? Or will I miss my flight because the cab doesn't show up? Because the mobile app will tell me. Likewise, when I'm going in the cab, I no longer have to wonder are they taking the long way or the wrong way to my destination because I'm able to specify the destination and they get turned by turn directions. And I no longer have to jowl with the taxi driver about whether I can pay with credit card when I arrive at the destination and hear the excuse that the credit card machine doesn't work or I need to pay by cash. Because it will automatically deduct from my electronic account. And when it comes time to expense reports, I don't have to look for a receipt because it's been emailed to me. And it's just not the customer experience that's evolving and transforming with software. But it's also enabling the business to rapidly introduce new features based on customer feedback and changing market conditions. And so as businesses rely more on software to innovate, there's significant pressure on IT to not become the bottleneck. IT departments have better figured this out, how to do things better, faster, and cheaper because if they don't, the employees will simply not rely on them. How many of you bring your own phone or mobile laptop to work today? Companies and business units are already going to public cloud services and going around internal IT as well. And so shadow IT, you're seeing this rise up in companies. Spoke with one bank, they came to us and said, hey, can you help us out? We're having a real challenge with our business units. They're going directly to public cloud providers, buying it on their credit, corporate credit card, and they have a seven-figure bill. And so this is the challenge for IT and this is the promise of these new technologies, whether it's OpenStack, DevOps, Open Hybrid Cloud, which embraces both public and private cloud and allows internal IT to differentiate by providing that access to both services. But as businesses rely more on software, it has its own set of challenges. How do you deliver software on budget, on time, and realize the full value when the data shows that software projects are typically over budget by 45%. They're delayed by 7%. And they don't achieve the real value, the full value, because one of two reasons. One is they have to strip out features to meet that deadline. Or by the time it's delivered, it's irrelevant and it's missed its window of opportunity and I don't achieve the full value. And so with the rise of cloud and mobile applications, the days of multi-year release cycles is long gone. Can you imagine releasing new features to a social website every 12 to 18 months? It simply would be dead on arrival. And so this is given rise to new development models such as Agile, with frequent releases and short development cycles. However, the problem is if you still rely on the traditional deployment processes and infrastructure, developers spend more time on deployment. And this doesn't make any sense. You want your developers developing business logic application code. You're testers testing that. And ideally your operations folks keeping the lights on and keeping the uptime and in troubleshooting issues as they run into them. And so a common issue within the corporation is that you have the old agile throw it over the wall from development to operations. The dev test and operations folks are all operating in silos. There's a lack of automation and standards. Each group has its own set of tools, own language and they're reinventing the wheel. It's very inefficient and it slows down the business, right? And so ultimately software quality and uptime suffer. So what can IT do from an IT perspective? They can turn to DevOps, right? DevOps is all about software development method that stretches collaboration, communication, integration between the developers and operations. And applying many of the principles of agile to the full application life cycle along with automation and monitoring. Gene Kim, renowned expert around DevOps, really talks about three enablers for DevOps, the author of the Phoenix Project. And the first one around configuration and code. This is all about standard environments, having the developers use production like environments early. So they get issues out of the way quickly. Also using like a single repo for your code, maybe GitHub, and also putting your operational artifacts in a repository, perhaps like Nexus or version control. Secondly, Linux containers. Linux containers enable DevOps by being able to package it once and deploy anywhere. And then also automated provisioning. Automated provisioning, being able to automatically provision the OS, the app platform, the application, and all the configurations. No reason to reinvent the wheel as the application moves from dev test and production every time. One of the key concepts here around DevOps is to be able to fail fast and recover versus never fail. Total different mindset in terms of how you approach this. Secondly, another enabler around DevOps, CICD, continuous integration, continuous delivery. Continuous integration is all about catching and detecting issues early. The longer you wait in the life cycle, the larger the technical debt you have to pay to resolve an issue. So you want to catch those early and often. Continuous delivery is all about enabling the business to get product to production quickly. Many organizations that I talk with in Silicon Valley, there's something on common for them to take days, or even weeks, six weeks. To get code, maybe even changing a single word on a website. Can use to delivery is all about getting that down to minutes. When you have that power, you have a lot of ability for the business to think creatively and innovate rapidly. And then thirdly, continuous innovation. Enabling your development organization, getting out of the way, eliminating that bottleneck, and providing self-service to your developers. Providing them access to the tools and platforms that they need. And then also enabling them to do rapid prototyping, right? Being able to provision out the environments they need to test things out. The key concept here around cultural change, right? Acceptance of failure. It's okay to fail because we're gonna test it early, catch it quickly. We're gonna have automated processes to recover quickly. And we're gonna be developing, and microservice is small change. So the risk of that having negative impact is much lower and you can recover quickly. So that's all great, but who's actually using this and doing it and has implemented, has been successful? Where are the proof points? So Amazon is certainly one of the leaders around DevOps. They have the ability to do 10,000 updates per hour. And you would think, wow, that many updates, your site must go down all the time because of these updates. But the data shows that only 0.001% of the outages are attributed to software updates. And they're not alone. Other kind of leaders around DevOps, Etsy, LinkedIn. Etsy does up to 30 updates a day. Some having millions of dollars of top line impact on their revenue. LinkedIn moved from one month release cycle to multiple times a day. And it's not about how many times can you update your site in a day. It's about enabling the business to rapidly respond to changing market conditions, customer feedback, and get that product into production quickly. And when you have that, IT really becomes a competitive advantage and a differentiator for their overall business. And so if you're out in the audience and you're looking in your organization to adopt DevOps, what are the questions you should be asking internally at your organization? The how, what, and where, really around DevOps? How to quickly and reliably deliver new capabilities? What kinds of new apps and services to deliver and support? And where to create and run these new apps and services? And so the shift in this transformation is more than just DevOps alone. DevOps, about bringing the organization together, working in a different way, improving processes, collaborating. Also deploying your application in containers to make it easy. But also having applications that can web scale in infrastructure that can rapidly be provision, scale up, and keep up with the rapid release of applications. These three things go similar together, just like in the Automated Industry as an analogy, right? Back in the, before industrialization, you had cars being developed in workshops, using craft work like processes. But as it was industrialized and moved to a factory, they switched the manufacturing processes to take full advantage of that new factory. Likewise, as you're deploying OpenStack, are you gonna keep the same processes and produce the same applications? You're not taking full advantage of that shiny new object factory that you have around OpenStack. Likewise, what you're gonna produce out of that factory isn't the same type of application. Those monolithic applications don't make sense in this type of environment. But moving more to a cloud application takes full advantage. And so let's dig a little bit deeper into the how, what, and where. And first with new cloud applications around microservices. Microservice applications, some of the characteristics, these are lightweight, small applications that enable rapid release and minimize the risk. Typically APIs driven, you connect them together. They're fault tolerant, so they can withstand failure in the underlying infrastructure. They're scalable, so they won't crumble on their own weight. Elastic, so they can grow and shrink based on demand. And multi-tenant, they no longer demand that they have their own dedicated cluster. And for the most part, they're stateless. If there needs to be state, you need to be careful of latency, throughput, and durability. Also, how is the operating system evolving to enable DevOps? And cloud applications, so Red Hat Enterprise Linux Atomic is a lightweight container-optimized OS where we've packaged in Linux containers, enabling you to package once your application, deliver anywhere, enabling continuous delivery. And then also, a lot of momentum was achieved once Docker came on board, standardized API, a standardized image format, and a sharing an image delivery model of your applications. But the issue with containers on its own is, how do you manage it at scale? How do you schedule these containers? How do you orchestrate the containers? That's really where Google's Kubernetes technology, which is integrated in Relatomic. It's a cluster manager for containers and provides a way of orchestrating the containers, deciding where they go, how they're connected, and making sure that they stay alive. And so containers really enabled accelerated application delivery by packaging all the dependencies within the container, whether it's the libraries or the runtime, while still allowing the operations folks to enforce security and compliance at the host level, as well as a container level, without interfering with application developers. In Docker, its workflow really enables DevOps as well with a rapid release of applications. In a typical Docker workflow, you have the developer defining a Docker file, the OSSUs, the applications, libraries, etc. Packaging that in a container, building it, taking that container and pushing it to a registry, usually an enterprise that's gonna be a private registry, so you have a trusted source, and you know where that container is coming from, whether it's patched. And then that becomes your sharing model, so that in your environment, whether it's dev test or production, you can pull those images and reuse that in all those environments rather than rebuilding or recreating the wheel and introducing the risk for failure. Likewise, Kubernetes is the container manager. So as you're looking to deploy into a production or even a test environment, how do I utilize my environment and deploy containers? How do I orchestrate it? And Kubernetes is all about being able to manage containers. So from a Kubernetes perspective, what you can do is create a JSON file. You can define your application as a set of services. You can also define declarative statements like the desired state. So for instance, in this example, I'm doing a Redis service, key value for connection management. And I'm stating, hey, I want at least three running. I want to use the PHP Redis container. And I can define the resource limitations on this container, CPU, memory, and the port that it'll listen on. And then Kubernetes will take that as the input and make that happen. So it'll build out that environment. In this case, it went out and created three containers. Now if there's an issue with one of the containers, after a short while, Kubernetes will detect that and then find a new location in your cluster to create an additional container to replace the broken one, and then do self-healing. So no longer do I get a page, it will automatically recover from that failure and ensure that the desired state is met in my container cluster. So deploying a new application is very easy. Next step is, hey, I want to upgrade that application. So maybe I want to move from version one to version 1.2, right? I want to be able to, in a DevOps world, I want to quickly introduce new change. And Kubernetes is certainly an enabler technology for that. And so the recommended approach here is that you actually go out and build your 1.2 container, put it out there side by side, while version one is still taking all the traffic. I then complete my continuous integration testing on 1.2, while one is still taking the traffic. Once it's successful, I can flip the switch and immediately switch the traffic over to 1.2. This is very useful for applications. Sometimes maybe I've had customers say it takes 30 minutes to upgrade from one version to another in their production environment, right? That's very costly and slow changing. And so this model allows you to do that flip of the switch. Not only that, but if there's an issue, something's broken, I can do a rollback and move back to the old version without bringing in developers and the rest of the team to root cause and house that issue and recover. Likewise, from an IT perspective, what are the other ecosystem parts that I need to really enable DevOps? So here we're at OpenStack for certain on the IIS layer. But what about above that? You have a PaaS layer as well to enable rapid provisioning of the development environments. But also you may want to have a service catalog to your developers so they can do self-service. And also having a centralized repository that has trusted content, whether it's a registry for your images or RPMs. And so that's where PaaS really comes in. PaaS integrates containers, schedule, orchestration, and it hides all that complexity from the developer so they can focus on coding. An example like OpenShift from Red Hat is a PaaS. It allows you to manage the lifecycle of your images from DevTest production, provides self-provisioning of complete application stacks. So NeoJS, JBoss, Ruby, Python, et cetera. Also provides a way to standardize these environments and provide it to multiple development teams. So you have a consistent application stack in your environment that's trusted and patched, provides self-provisioning. Another key thing, like in test environments or in production, is to have auto-scaling up and down. So it can monitor the application, the load, and automatically adjust and leverage that scaling capability even at the IAS layer. And then also the ability for the developer to focus on the code and just push the code, let the PaaS handle the containerization if they like, and actually go ahead and deploy that. So the customer, being the developer, doesn't have to worry about storage, networking, compute. And then lastly, you want to be able to deploy your applications wherever they're needed. Sometimes it makes economical sense to deploy it on a physical infrastructure, maybe virtual container or even public or private cloud. So you want to have that flexibility as an IT service to your business unit to be able to deploy your applications anywhere. And that's where a CMP, called Management Platform, would come into play, enabling you to abstract yourself from the APIs and the tools and processes of a public cloud provider, or even a private cloud provider, or a virtualization provider, and be able to have a consistent flow across the multiple providers. And in terms of the workflow, how does this all fit in to a DevOps workflow, right? So first off, you have IT, providing IAS, PaaS type environment, the developers are coding, maybe on their laptop, or they can use a centralized PaaS. A PaaS enables really the developers to focus on their business logic. A lot of organizations today, you have developers manually coding, writing custom scripts to manage the pipeline from DevTest to production. A PaaS colonizes that and automates that for you. So you freeze up your developers to really focus on business logic code rather than infrastructure scripts to manage the pipeline. So that's really key to success, too, is aligning the tools from DevTest and production, so you're all using the same tools, and the PaaS really enables that. With the PaaS, once the developer codes their microservice, they can check it in and push it to the PaaS, build the container, run its CI test, and then you're using Jenkins. Once the Jenkins build is successful, the artifact can be moved into a test instance. The testers then can automatically run their test cases without actually having to reproduce and reinvent the wheel of creating an environment. It's dynamically created for you. And then once testing is successful, that artifact can then be continuously deployed, if desired, into the production environment. And so from end to end, I can quickly move that same container from DevTest to production without rebuilding. And the key thing with DevOps is then having that feedback loop from a monitoring perspective, so the developers and the operations folks can detect issues early and often and resolve them. And so lastly, I want to go through an example of a case study of a customer who transformed their organization with DevOps and some of the enabling technologies I just spoke of. So here's some of the pain points that this particular company was having. It's a rather large internet company, Financial Services, and it took them six weeks to actually change a single word on a website. It's kind of alarming, actually. And it also took two years after a competitive startup to launch a competing product. And previously, they didn't have access to newer development tools. There was a lot of tight control over what was provided internally from a security perspective and just took a long time to move. So being able to provide new development tools like Node.js enabled their developers to move quickly. And the key thing in Silicon Valley is attracting talent, retaining talent. And if you're inventing your own technologies, not many people really want to learn those and not be able to use those elsewhere. So providing access to your developers of standard platforms. And so they had significant challenges. They weren't growing as a business, having challenges there, had a lot of strong competition, not only from startups, but large companies were starting to get in their territory. It certainly had a hard time moving quickly. And the key thing also was the predictability. Sometimes it took one week to provision the infrastructure. Sometimes it took six weeks. So as a business, how do I plan around that? Well, I have to choose the longest timeline. How do I market and advertise new product offerings? How do I predict revenue stream when there's such a variance in delivering infrastructure? Likewise, recruiting was very difficult. And so what they decided to do was adopt a solution built around a platform as a service, along with DevOps process, and implement a continuous integration around Jenkins and a continuous delivery model. And they did this by building on top of their IAS open stack in their legacy virtualization, and putting a Paz on top of that, which provided access and standardized development environments around NodeJS, JBoss, also had Jenkins built into the Paz, so each developer could have their own instance. Paz integrated with their hardware, Low Balancer, their F5, so as new applications were added or deleted, the Low Balancer was automatically updated. And also, they could leverage their existing database. They didn't move that into the Paz. They wanted real-time access to the database. And then they were able to integrate the Paz into their existing GitHub and their Nexus repository for the artifacts. And so one of the key accomplishments here was that they were able to go from six weeks, four to six weeks of delivering applications into production to under 30 minutes consistently. And the way this worked is you had the developer on the left side pushing their source code into GitHub, checking in, and then it would go into the Paz. That code would be built in the Jenkins server running on top of the Paz. Once it was successful, the artifacts went into their Nexus repo, it was promoted from release to production. And then operations wanted to control the rollout of continuous delivery. And so they had a tool which enabled them to push out binaries in the production rather than source code. And it gave them new capabilities they didn't have before, such as the ability to roll out a gradual update into production. So rather than flipping the switch from 0% to 100% on the new version, they were able to gradually roll out a new version to 10%, 20% as they gained more confidence, they could build their way up to 100%. If there was an issue, they were able to roll back. They're also in this model, they're able to support multiple versions, as I showed earlier with Kubernetes. And for the first time, they were actually able to scale up, scale down in automated fashion without submitting tickets to the network to open the firewall, et cetera, with long lead times. And so when you look at the return on investment for their DevOps, they improved their business agility by shortening the time to market. They reduced app provisioning to under 30 minutes. And they enabled improved productivity for their developers by providing self-service, CICD. They also reduced dev and QA iteration on bugs from hours to minutes because they were quickly able to launch an environment in the past to reproduce the issue, even if it was on a different version than they were currently developing. And they had a consistent set of tooling across dev and QA and production for the first time. So everyone was talking the same language. They were all able to collaborate and break down those walls that were creating silos in the organization. Likewise, they were able to improve business predictability by having that predictable release pipeline from dev test to production. And they improved the overall operational efficiency just with the improved processes. They were able to also move from a model of one application per virtual machine to 10x number of containers per VM. So they got much greater density, able to reduce their costs. And then they were able to automate and scale their application based on load. So they were wasting resources by over provisioning. Likewise, for the first time, they were able to replicate issues in development that mirrored their production environment. Before, they had a production standby environment, which was totally change control. So if they wanted to test something out in a production like environment, they had to submit tickets, wait for networking to change, wait for that environment to be provisioned. And now you empower the developer. If they want a production like environment, they could instantly create that with the pads. So very powerful. So thank you for attending today's session. Open up for any Q&A. If we don't have enough time, I'll certainly answer questions you can stop by in the back. And I'll be happy to answer those as well. But if you have a question, please step up in the microphone so the whole audience can hear it. Hi. When adopting DevOps, does it need to come from the top, the bottom, or the combination of both? Sure. So in the context of this discussion, DevOps, you have the DevOps, the process. You have the DevOps enabler in terms of cloud-based applications, so microservices. And then you also have the infrastructure. And so as you move forward to the Nirvana, it would be going all three. But you could start with either one of them. So the first step could be adopting OpenStack. Next step could be re-architecting the microservices, enabling DevOps Flow. And so I don't think you need to start from the top necessarily. Yeah, organizationally. You could start either three areas, and it could be certainly top down to get that whole DevOps Flow. It's the cross-organizations. You're going to have to eliminate those silos. You have to structure the organization to be efficient, so maybe having your developers with your operations and your testers combined on a single team, rather being individual teams, to really foster that communication. So I think that needs to come top down, but there are other parts that certainly could be the ground up in terms of transforming the infrastructure, adopting containers, adopting APAS, et cetera. Any other questions? Great, well, thank you so much for attending today's session. And if you do have another question, feel free to stop by. You have my contact information on the slide. Feel free to reach out. I'm also on LinkedIn. And I look forward to connecting.