 Cloud Container and DevOps track. Thanks for coming after lunch and not just taking the nap. First up for the afternoon slot, we've got Chris Fantine, a chief technologist at Red Hat, and he's going to be talking about a DevOps state of mind with microservices, containers, and Kubernetes. So without further ado, Chris. All right. Thank you, everyone. Welcome to today's session. First off, talk a little bit about the industry trends and then talk about DevOps and how Kubernetes and containers can enable that. But back in the 90s, Andy Grove talked about how only the paranoid survive. This isn't about security, but it's about strategic inflection points. In a company's lifetime, there are milestones where there's a lot of disruption going on, perhaps in the industry, competitors, new technology, and it causes the executive team to have to make a decision. Do they stay the course and potentially fall by the wayside or pivot, change direction, and potentially thrive? So there are many, many companies having to make those decisions right now across retail, finance, media, transportation, because they're being disrupted by the disruptors. The incumbents are being threatened by those companies embracing technology, and in most cases, software which is providing them a competitive advantage and quickly catching up to the incumbents in the industries. So what is it about these disruptors? The disruptors are typically quick innovators. They're able to deliver new capabilities to the marketplace versus the incumbents who are better at execution. Take a look at Ford, not the fastest innovator in terms of new technology embracing new trends, but they're very good about executing mass producing vehicles across the globe. Then on the other hand, you have Tesla, a new company that wasn't burdened by legacy technology or products and solutions, and they were able to build from the ground up embracing technology at its core in terms of their actual product too with the release of new software updates to rapidly innovate those vehicles well after the initial sale. However, they're struggling to execute at scale as well with their Model 3 production. And so the ideal world is that you're able to quickly innovate but also deploy at scale. And so how do you get there? It's not just an application, a mobile or a web app. As the San Francisco taxi industry found out, in order to catch up to Uber and Lyft, they released a mobile application, but they still, in the terms of a yellow cab, they filed for bankruptcy after ridership plummeted over 65% after Uber and Lyft entered that market. So what is it about the disruptors? I talk with a lot of these in Silicon Valley, and there's certainly some characteristics of these disruptors that help them keep ahead and stay ahead of the competition. And one is that they're empowering their organization. They're taking their accountability with small teams that are diverse in terms of their responsibilities, maybe 68 engineers who are owning the service end to end. They own the site reliability. They own the development of the new features. They get the pager call, and they're able to make quick decisions. They don't have to escalate up to their management change who then talks to the other siloed organization, and it goes down there. Instead, they're able to be quick and nimble from a decision-making process. Also, it's a very collaborative environment. Also, secondly, they're enabling the business to answer questions right away because they have access to the data that they need. They've eliminated these data silos. They're analyzing that data and actually make it actionable. They're getting that quick feedback from the market into the engineering and able to shift and change course. They're also fostering a culture of experimentation. They're able to try things out and immediately see what's the impact to the business by that change. And they're able to do that because they have automated systems that can deploy new capabilities and roll back if they need to, as well as automated systems to provide that feedback loop to the developers and testers. Also, they're able to rapidly innovate, right? Able to take a business idea and then move it into production in a matter of minutes or hours versus a typical enterprise taking maybe weeks or months. And so the traditional company has to decide, do they get disrupted or be the disruptor? And one of the challenges though that they're facing is that typical enterprise takes six to nine months to deploy new innovation out in production, right? And as I talked with enterprises, the reasons are many, but one of the common things is that typically the organizations, the way they're structured, they're very siloed off, dev, QA, and operations, right? And just like in nature, if you evolve on your own island, you're gonna develop your own tools, your own processes, your own languages, and then it becomes very difficult to collaborate and communicate with the other organizations. And as a result, the product quality suffers and it makes it very cumbersome to move that application or that service through the pipeline from dev into production. And so how does IT transform from a cost center into an innovation center? And this is the challenge that the incumbents have to address. And so DevOps is a huge part of enabling organizations to rapidly deliver new capabilities. And DevOps is about culture, process, and technology. From a cultural perspective, it's about collaboration, it's about ownership and responsibility of that service end to end. It's also about transparency and reflective of a lot of the traits of the open source communities is inherent with the culture of DevOps. Also, in terms of process, it's about automating your processes, right? Getting rid of manual processes, making them repeatable, improving quality, and then also improving speed. And then lastly, technology. Many of the early adopters of DevOps are embracing open source, leveraging a variety of tools, whether it's the operating system, the infrastructure or the development tools. And they're able to deploy this across a wide range of infrastructure, whether it's private, public, virtual, or containerized infrastructure. And so the DevOps factory, what it provides is the ability for the developers to do self-provisioning. So it allows you to standardize your environment so that you don't have the repeating of technology on a group by group basis, right? Instead of investing in the infrastructure on a one-off basis, you can free up the developers so that they can focus on the business logic and code. And then also automating that pipeline from dev test into production with a CI CD process. And then having a feedback loop to your organization so that you can quickly pivot and change course and then enabling you to deploy this across any infrastructure. And so the value of DevOps from a business perspective is certainly a faster time to market, more stabling operating environment, improve communication, as well as the ability to innovate because you're freeing up the developers and allowing them to have more time to develop through the efficiencies of DevOps. And you're breaking down the task into a smaller component, allowing you to quickly deploy without betting the whole business every time you do an update. And as a result, you can then respond quicker with automation to an issue in production. And certainly we'll talk about security as well in the second half of this talk, right? So take a look at a case study that made this transformation. And this is pretty typical of customers I work with. You know, they have these types of challenges. It could take six weeks to get a single word changed on the website. It took two years after a competitive startup came out with a competing technology to catch up and release a similar product. Also, they didn't have access to the tools and the process that they needed in order to be very productive. And then it also made it difficult to recruit because they were having the developers build out their own proprietary tooling and infrastructure to develop, for instance, a CI CD pipeline. And so their business vision was actually deploying new innovation into production in a matter of under 30 minutes. And what does that mean? That means the developer checking in their source code into the repository, moving it through the CI continuous integration process, and then putting that into their repo, which is replicated out into the public production environment and being able to scale up and scale down that infrastructure. And so the shift they made change was from a cultural perspective. Some of the changes they did to accomplish this is first off, they brought together the cross-discipline functions in their organization. They brought together the engineers, the testers, and the operations, and then aligned them with the business unit as well. And then in the backend with the developer, so they had them integrating with the security, the DBAs, and the networking teams as well. So this was a single virtual team with the same goal of maintaining that site reliability and then also in terms of deploying new capabilities and being on call for issues. Secondly, they pushed down decision-making in the organization. They flattened out the organization and they enabled and empowered for the team to make day-to-day decisions without escalating. And they had the upper management focus more on the strategy of the organization. And so this is very reflective of the open-source way in terms of collaboration. Open source is all about no one is smarter than everyone. They're able to leverage the power of the community to get innovation. And so organizing the group in this open-source way brought a lot more innovation to the group because everybody could kind of contribute their ideas and felt open, it wasn't siloed off in a kind of a black box. And so they had transparency to the project and folks could contribute in ways that they normally may not have, they weren't siloed off. Right, and then the second thing they did was evolve their process through automation. And they built out a CI CD pipeline that was automated. That included continuous integration so they could check in their source code and get immediate feedback on the overall impact of that application change. And then also continuous build. They were using containers and they were continuously building the container image and getting feedback if there was any issue to the code change. And then also in terms of continuous deployment, they were pushing out these changes at scale with a variety of deployment strategies depending on the particular goal. And they had a feedback loop throughout this process. That was really critical to have a short feedback loop so they could iron out issues early and lower the cost of a bug or a negative impact to the product. And so this is really reflective of the manufacturing industry. Does anybody recognize what this is a photo of? This is the Intel FAB that's being built out in Phoenix, Arizona. And I showed this because back in the 90s, Andy Grove was going through the pinion bug that was a strategic inflection point for that company. And the lesson learned there was, first off, he decided, hey, we need to be more responsive to customer issues. The feedback loop is far too long. That's causing a great expense because we're not catching these issues in software. We're catching them in the actual hardware. And so that's an expensive process. And so he decided to, one was to start designing the chips on their own chips. So they moved over to an X86 base continuous validation farm. And then secondly, they enabled the developers to actually submit their chip design to this large scale Linux farm and get instant feedback about how that change impacted the overall chip design. And so continuous integration here in the Intel FABs. Also, here's a picture of the Tesla automobile factory. And I show this because it's a representation of continuous build and continuous delivery. Continuous build, they're leveraging software in an automated way to produce these vehicles, to improve overall quality and efficiency in terms of the production. And then secondly, continuous delivery. For the first time in the automobile industry, you could actually buy a car and it gets better six, 12, 18 months down the road because they can deliver software updates. Better zero to 60 time, better battery efficiency, better new and improved applications or a security fix for that autonomous driving software as well. Not only are that improving the product and the quality, but they've fundamentally turned the business model upside down from a one time sale to the ability to offer services add-ons that could be a subscription. So IT having a huge impact on the actual business model. And then the second aspect was building out this continuous feedback loop so that developers could quickly pivot and change course. And then thirdly, technology. That was a key part of it. And some of the trends around DevOps was really breaking down the application into microservices. So the company didn't have to bet and risk a complete failure to their business if that particular upgrade didn't work. By breaking it down into a microservice, they can quickly pivot, change course and release new capabilities and lower the risk of that deployment having a negative impact. They can also choose their own technologies and be more diverse in terms of their tooling. Also DevOps key part of that because that's the automated process and the cultural aspect that allows you to move quickly through the CI CD process. And then cloud the ability to deploy across whatever infrastructure you may need for that particular application. And so containers are a good fit for that because a small size application or service fits nicely in a container that can start up and stop quickly. And then DevOps, it fits nicely containers because you can build your application or service once and then deploy anywhere. So you move, build it in dev, you take that artifact, put it in test, put it in production as is. And then containers provide that abstraction so I can deploy it on any cloud provider, public, private or even physical or virtual infrastructure. And so containers allow you to build, ship and run. The basic premise is building your container image with a build file so it has a nice recipe that's reproducible. I can then show that across my dev test and production environment. I can then deploy it across any of my infrastructure similar to the Java world with a standard image format and a standard runtime. But what about containers at scale? There are many challenges as I deploy out into a production environment. I need to schedule my container microservices to a large cluster. I also need to monitor the lifecycle and health of these instances. And I need to be able to automatically discover what services are available and bring them into a low balance for like services. And then also I want to be able to monitor my services. I want to be able to scale them up, scale them down automatically so I'm using my resources efficiently. I also want to provide persistence to my developers without having to go through manual processes. I want to be able to aggregate that application that consists of 10 microservices and be able to ensure high availability across my physical infrastructure. And then of course I want to address my security concerns for the enterprise. And so that's where Kubernetes comes in. It really provides a container application platform to manage and deploy containers at scale. It frees up your developers from having to manually define and write the automation around managing your containers from a networking storage and compute perspective and allows them to focus more on the actual code. That makes a business difference. And so enabling microservices with Kubernetes. First off, a best practice around containerizing your microservice is to really separate the code, the configuration and the data. The code being your application, your maybe your Java, JAR and all the immediate dependencies from a middleware and OS perspective get put into that container image. But you want to separate out the configurations, maybe IP addresses, geographical locations. Those could be put in what Kubernetes provides is called a config map. So that can be mounted at the time of instantiation into the instance as a file or an environment variable. And if it requires a password, it could be put into what's called a secret or a vault in your XED distributed data store. And so that provides an extra layer of security encryption. And then lastly, separate out your data. You can use a data service, remote service, the database or leverage Kubernetes to provide that persistent storage. And so some of the basics for Kubernetes and enabling microservices. First off, it provides the ability to orchestrate the deployment of your application. In this case, I have a web with two front ends and one database backend. And so I want to deploy this application. I can go ahead and define that application. And then Kubernetes, its controller manager will actually store that state in the centralized data store. And then go ahead and orchestrate and deploy. First off, the two front end web instances and it spread those across two nodes and it put it into what's called a pod. A pod is one of more containers. In this case, it's a single web server. And then it pulled out the image from an image registry, whether it's private or public, and it ensured that there were two web front ends. So it's declarative. I state it needs two front ends. It takes care of the rest. And then secondly, it went ahead and deployed the database server. And so you can see there are tags for each pod. And those tags are used to create a front end service or a load balancer in the Kubernetes cluster. And so I can route, in this case, I set up a public IP for the web server. And in the back end, I'm just front ending the database traffic from the web to the database there. And so the controller manager and Kubernetes defined those services and deployed them. And it did the discovery, so it added those to the front end service. It also does health checks. So it'll monitor those instances. If there's an issue, it will take action by actually deploying a replacement instance. And then once it's successfully up, it adds it into rotation and it takes out the failed instance, in this case on the web front end. It also can handle auto scaling for you. So it can actively monitor the utilization of your nodes. And if it exceeds a threshold, in this case, 75%. So it got to 80. It's gonna go ahead and deploy another front end web server. And it put it on the other node there. And so it discovered that new service and added it into the web load balancer. So I have three replicas now. And so that was all managed by the controller manager. Another aspect with Kubernetes and your containerized microservices is it enables rapid innovation experimentation. And so this is important because about a third of ideas improve the metrics they were designed to improve. So you need to enable your developers to try things out, get feedback, and quickly change course. And you do that through a nice feedback loop to your developers and your testers so that they can correct and change course. And then you want the developers to have, for instance, version A and version B. And in this case, they changed the recommendation engine in version B. And you wanna be able to give feedback to the developers. How does that impact the click-through rate of this particular mobile application? And so with Kubernetes, you can do canary deployments. That's where you update, for instance, a single node to the newer version and your environment. And then instead of routing all the traffic to the old version, I can split the traffic, for instance, 50-50. And then I could monitor the conversion rate, whether it goes up or down, based on that change in the recommendation engine. All right, so this is doing some A-B testing with the canary deployment model. In this case, it improved the conversion rate so then I can route all my traffic and proceed forward with that new version. If there was a negative impact, I could revert the traffic back, right? And this is instant switching back and forth, right? You're not suffering downtime of any significance for this particular application, right? And so the impact of making this change to a microservices that are containerized is quite significant. The ability to do more deployments, shorter lead times, and lower change failure rates, and then faster recovery times, all enabled with DevOps, containers, and microservices. And it's not necessarily how often you can make changes, but when that customer or when that business wants some new innovation, IT can deliver. And that's when they become a strategic differentiator for the organization, right? So thank you very much. Here's my information, and I'm gonna move right into part two of this talk, which is actually about continuous security.