 Hi again Red Hat Developers. This is Jason with the Red Hat Developers Program. I'm here with Hugo Rivera from Red Hat who's going to talk to us about Linux, Linux are containers and containers are Linux. Thanks Hugo. Hi, good morning. My name is Hugo Rivera and I'm going to talk about Linux and containers which are closely related topics on part of Red Hat's global ecosystem team. You have heard plenty about containers in this event. They're revolutionary technology and they're bringing changes mainly around three dimensions. So if you're embracing containers, there are changes in the way that applications are built and deployed. There are changes in the infrastructure needed to run these applications and there are changes in the processes that you need to have in order to deploy and maintain these applications in production. Now let's take a step back and look at how applications are evolving. If you look at how applications were built a few years ago, they were done in somewhat monolithic fashion. So the application provider would define the limits of the application and how the environment was configured for deployment was kind of the responsibility for the application. The employer usually a system admin. The application often had some runt on the penises. They could be libraries from the operating system or they could be the penises coming from some of the sources. And at the end, at the bottom of the stack, an operating system most likely Linux and of course in the case of Red Hat, this is Red Hat Enterprise Linux. The problem with this configuration, aside from the monolithic approach, is that the employer may make some changes to the environment for the application that is incompatible with what the application needs to run. Maybe the sysadmin needs to make some trade-offs about how to configure the application. They need to host other applications as well. So we have the risk of some environment drift. Now we'll look at what containers are bringing about in terms of evolution. You can still see the same pieces. You have the application, you have the runt on the penises. Something interesting to notice here is that the operating system is now segmented into two domains. We have at the very bottom the kernel and some basic services that allow you to run containers. This is what we refer to as container host. And then the libraries are included in the container itself. And only those libraries that the application needs to operate. And everything above it is seen as layers. So the application provider builds an application layer. It may include some runt on the penises in the form of another layer and then the operating system or Linux libraries that it needs to use to operate. And all of this is packaged in a single image. The advantage is that this is a fairly lightweight model. Containers can run at scale on the same host. They are integral part of Linux. This is why we call our session containers are Linux. They use isolation in the form of C groups and main spaces so you can run this at a high volume. And the developer or package defines the application configuration. So the person that knows the most about the application gets to define what are the dependencies that the application needs to operate. This leads to a more predictable environment because there's no drift from what I developed and tested on. Now this gives a lot of power to the developer. You may even see that developer is skiing with containers because that the person knows what the application uses and they know what it needs to run. But with great power comes great responsibility. If you're an application provider, you now are in charge of collecting these sources for all the layers and dependencies. And by this I mean not just those things that you need to make your application work, but those components that the application needs to run in a production environment. Which sets a higher bar. You're also responsible for the life cycle management of your components. Not just of your application pieces but all of the libraries and even the operating system elements that are included in that image. And finally, because this is packaged as a unit you now responsible for integrated end-to-end testing. So this could seem like a daunting task for developers. We're shifting some of the responsibilities that used to be with the deployers to the application developers because they have the knowledge about their application and they're in the best position to do this. But we know that this increases some of the work on the application provider and Reha is doing some things to help here. We are launching a Reha container certification and this is the way Reha collaborates with commercial software providers to check that things are ready to be run in a production environment. So I'm going to talk about the things that we check for. By the way this is a free service for software partners and we try to help you build and maintain containers that can be trusted in a production environment. The first thing that we check and we do this through both tooling and a container is that there's compatibility between the host and the container-based layer. As I mentioned before, these two are closely related. They are part of the same product. We at Red Hat had years of experience in maintaining compatibility between the libraries and the kernel so this part is important. You typically would not mix G-Lipsy from one distribution with a kernel for another distribution and there's no reason to do it with container either. What we check for is that the libraries that are included from the operating system as well as possibly other dependencies coming from Red Hat are both supported and they're up to date. We know and monitor all of the potential vulnerabilities that can go into the operating system libraries so we can detect when a container is to be updated and notify the vendor to do so. The last thing you want as an application provider is for your container to be a container for risk into your customers. So we help them with those checks. And finally, we check for the packaging of the whole image. We look to make sure that the image is packaged with the right tooling and the right versions. We check that the container image has adequate documentation to let the end user know how it's supposed to be operated. And we check for the right metadata in the forms of labels to make sure that the container can be inspected and managed accordingly. So all of these is something that we offer as a service to commercial software providers. And our goal is to get these containers ready for enterprise consumption. You might have seen announcements of our Red Hat container catalog. This is a Red Hat property we have on our customer portal. In fact, yesterday we just announced the inclusion of a health index, a container health index, which is a score we assign to containers to analyze how trusted they can be and the number of criteria. So I encourage you to both look at the announcement and look at our container catalog. We will be adding partner images here so all of the software that goes to this container certification will be published in the Red Hat container catalog. Our goal is to give you containers that can be trusted to be deployed in a physical environment, in a virtual environment, in a private cloud and in a public cloud without having to make any changes to them. So the same container because we checked that it's compatible with the underlying host, we know that that can be portable across a hybrid cloud. More importantly, these containers are ready to be used in our enterprise container platform, which is OpenShift. So to summarize, if you are a commercial software developer, we encourage you to join our program. This is the program through which we offer certification. We have resources to help you with architectural review of your application and we encourage you to build a container using the Red Hat Enterprise Linux Foundation and OpenShift as a build environment. And with that, you can submit your container for validation we will make use of our services as I described and help you get your containers published for enterprise customers. Connect.redhat.com is the URL for our program and if you're a consumer of containers, if you're an end customer, we encourage you to talk to your software providers and let them know about this program and about Red Hat container certifications so that you can consume containers that are trusted. Thank you very much and have a wonderful day.