 So hello, everybody. We're in this beautiful afternoon here to talk about Java and DevOps supercharged or live your pipeline with containers. So I'm about to talk about, particularly, of containers technology from developers' standpoint. And I would like to start our discussion with a simple question. If we are developers, I don't know if you are developers, but as developers, when is our job done? When is your job done? Our job done. Because usually, traditional developers believe that your job is done when you just commit your code into the repository. Or if you have a camera on board, you take the post and move it to the done column. It's kind of frustrating for me, at least, to realize that my code, the thing that I'm producing today, is going to take like two, three, four, six months to go to the production. Because I lose that feeling, that empowerment feeling that I have when I get the things to be done. And even more, my lines of code, they are not benefiting anyone before going to production. And as a programmer, I like to believe that software can change the world and software can change the world for the better. So the more code and the better code that I could deliver into production, the faster that I do that, more people can benefit from what I do. So we want to deliver more and even deliver faster. But we usually try to avoid deployments because deployment is a painful thing. Nobody likes to be deploying things because usually we break things into production. And since we try to avoid that, one of the movements that happened the past few years are DevOps, which is basically a contraction of developers and IT operations, a tradition by model IT model, where you have people responsible for developing new features and you have people responsible for maintaining these things into production. And since we have this term DevOps, people like to say that between Dev and Ops, there's a huge wall between them because these people can be friends. They can be friends because developers, they are the ones that are constantly changing things and breaking things into production. And the Ops guys, the IT operation guys, they are the ones that need to keep the status quo. They need to keep the things running. And for you to keep the things running, you have to change the minimum, to change to the minimum. So how can they be friends if the dev guys are the ones that are creating trouble to the Ops guys? Because if developers break things into production, the phone call is gonna be made to the support which is handled by the Ops team and developers don't get that phone. They don't get customers or users complaining about what they're doing. So since they have different goals, they can be friends. And that's one of the things that we're trying to correct with DevOps because it generates a lot of memes in the internet. I like this one very much, The Disaster Girl, Work at Finding Dev, DevOps problem now because we're just delivering our problem to other people. And of course DevOps is much more than that. DevOps requires a cultural change, a process change, but we have a lot of different technologies that may allow us to make this process easier. One of these technologies is containers and containers happen like it's not a new technology, but somehow we are all discussing about containers these days. And I like to use the physical container comparison to explain how software containers work because I think it's very appropriate and we have a lot of different analogies to explain why containers are important today. I like to say that containers are so important for today's words, a seaborne trade that almost 6% of everything that is transported on Earth these days is transported by containers, on shipping containers, and the other 40% is transported, almost 40% is transported also in ships, but it's transported in bulk since we have things like petroleum and soy, so you have specific ships for that. And also, even though almost 6% of everything traded in the world is transported by container, only 13% of the world's ships are shipping containers. So we have a very small amount of ships that are transporting the containers worldwide and we have a very few ships transporting all of these containers. Container technology, the physical container technology has matured so much and is relatively new because it only started after the Second World War. But today, shipping goods inside a physical container is so cheap that when you get a codfish in Norway, it's cheap for you to get the fish inside a container, ship it to China, get people to cut it and send it back to Norway to be sold because the cost of the shipping from Norway to China and back again adds only a few cents per ton of the goods. So shipping containers today is very cheap, is very effective, is relatively fast and you have a standard for that. So containers change the world, change the way we see goods transportation and now it's changing the software world too. So what is so great about containers in software and again we're gonna do some kind of comparisons. First thing about great about containers is resource consolidation because you know you can transport in a shipping container, you can transport a lot of physical containers, that's why it makes so cheap to ship containers in a shipping container. So you have resource consolidation and how does that work in the software world? Traditionally for you to, you know some years ago, maybe more than 10 years ago we're discussing how virtualization can enable resource consolidation because we can do more with less hardware and then in virtualization we needed a server or a physical server then a host OS, then a hypervisor on top of that, then on top of the hyperviruses we need a guest OS, the binaries, the libraries, the software dependencies of our application and then we pack our application. That's a traditional virtualization model and then sometimes when you try to, when you have a very solid infrastructure, you try to minimize the amount of different OSs that you have into production. So usually when you have your own infrastructure, you have the exactly same OS with the same patches, the same versions running into production. So each one of the VMs that you have into production is gonna have the same OS, the same file system, the same files, the same everything. Then we have to stop to think about that. If everything is the same, why can't we use just one instance? Reuse that and just deploy what is different from one another. So that's what containers do from this point of view of resource consolidation because since now that we're using containers, we just need a server. Host OS, we share the libraries and each one of the containers only package the binaries, the dependencies and your application. That's why containers are, we say that containers are lightweight because you don't have to deploy a whole new guest OS in every single VM. You just have to instantiate your new container and when I say container, just to simplify that, imagine that the container is a thin layer insulating your process, in this case your application from the rest of the applications running in the host OS. So that's how containers work. In containers, we're using the same kernel, the same file system, the same services that are running on the host OS for each one of the containers running into production. And a very common question that I've received if we're using containers as in virtualization, we can use different host OSes, different guest OSes running into production. We can have different kernel versions. We can have different versions of the library that have no production. In containers, the answer is no, you can't have different OSes running into containers because all of the containers inside the host OS are sharing the same kernel. So you can run Linux containers in Linux and you can run Windows containers on Windows. And each one of the containers that are running are sharing the same kernel. So you can't have different kernel versions on your containers, so which is a good and a bad thing because you only have to manage a single kernel. And it can be a bad thing if you have a strict requirement of having different kernel versions. But that's another problem to solve. That's not the problem we're trying to solve now. Containers in software also allow default packaging. Container technology is not new. It's arrived at the 70s. And we have a lot of different technologies that provide a different packaging format. But now I think we have reached the point where we standardize the packaging for the container information. You can imagine a container packaging like a big zip file or tar file with some meta information for you to deploy the container. And default packaging is important because it allows you to just move your containers between developers and infrastructure. You can publish a container and other people can use your container because we agreed in a standard format. Just the way that physical containers allow the transportation to become so cheap and popular these days because everybody agreed on the format of a container. Another very good thing about containers is what I call virtual appliances because before that traditional deploy models used to be like, I have a server, I have to install it, I install the dependencies, I install my application server, then the developers generate an artifact like a jar or a year. Deploy that into my application server and that's the release process. Now with containers, again, this is not a new concept but containers allow us to do much better. And now we're talking with containers we're usually talking about virtual appliances. You don't let like, I have this installation and I just change my application artifact. In fact, this is a good practice with container. We just pack everything inside the container, everything that you need and your application. So if you need a JDBC file inside your application server, you just install the application server, JDBC file, the everything else that you need inside your application server and your application on top of that inside a single package. You might want to say that's a waste of resources when unpackaged every time and again the same application server but container technology also has layers. So you can install your application server in a layer and your application in the layer above. So each one of your containers will share the same layer of your application server. So you're not wasting, really wasting resources because it's gonna be shared, okay? So in containers, you have to change the way that you deploy software because you're not only deploying your application, you're going to deploy your application and your environment. And what I like to say is like a turnkey solution for deploying applications. You don't have to worry about installation and configuration everything else. You just have to know the name of the container that you contain an image that you want to run, choose that, run and turnkey, it's into production. That's the way we want to deliver software these days. That's how containers help us a lot. And if I take an analogy with physical containers, that's exactly what happened also to ships in containers because these days, the guy operating the port at the crank, he doesn't care what is inside the container. I just care that this container must go there, this container must go here and there finales because the container knows what is inside and the containers knows how to handle what is inside. In fact, we have some very special cases. If you have a fragile thing inside the container, it's the responsibility of the people, of the person packaging the container to put things to make sure that things don't break. If you're transporting bananas, for instance, you need a specific temperature to carry the bananas over the sea. So the containers know which is the appropriate temperature and it has a built-in freezer. So all of the guy from the port who needs to know is that I need to take this container, put there and plug it to a power outlet. Nobody cares what's inside, it's just written that it requires a power outlet and that's a comparison I like to say about virtual appliances. The container knows how to handle what is inside and the only responsibility for deploying the application is to get which container you need to know and start it. That's what I call turnkey solution. But also that is not enough because these kind of tools and technology, they have been around since the 70s. So what changed in the past like five, six years for container technology to be so popular? Container used to be a very restricted technology because it used to be hard to build containers, almost impossible to publish containers and you had to be built in and run in your containers. What changed in the past six years? Now we have a different set of developer-friendly tools that you don't have to be root to be running these tools. And these developer-friendly tools, they have a very friendly command line. You can just execute a line in your CLI and you get to build a container, to package a container, to publish a container, to download the container for a third party, all with a single command line that I'm gonna show you later. And for me, the most important one thing about container technology in the past five or six years is the container registry. Because the container registry represents four containers, the same thing that the Apple Store represented for mobile applications. It represents a way for you to create your application packaged in a turnkey format and allow this application to be published in a common way that anybody in the world can get your application, install, and run that. You see, now we have a marketplace of applications and this container registry, we have a public container registry like the Docker Hub and we have also private container registry like the one that you want to use in your private infrastructure to publish your internal applications. So it's also a possibility. So container registry, I believe that's the real thing that allow the people to exchange these containers and allow all of the bugs that we're seeing today with DevOps and container technology. But much better than just saying everything that I'm saying, I get to show you a very quick demo in case you've never seen that, of container technology. So here I have my command line and I'm just gonna make it real big so nobody can complain that it's not running. So today's, these days if I want to build a container, I just need to execute a command like Docker builds and pass the folder where my container is, it's gonna build a container. I'm not gonna do that because I don't have enough time to show a complete demo but the greatest thing is not everybody needs to build their own container to package because sometimes if you're not allowed to do to run containers into production yet, even as a developer, I can benefit from containers using third-party containers in my machine. That's one of the things that happened to me two weeks ago. I was testing some stuff with Norco database. So I installed and created a container image file for Norco database and kept running but then I wanted to try some features in the MySQL database but I didn't want to install MySQL database because I would use just for a short time frame. And I know when you install things usually they leave trash and everything else. I just want to do a small thing. I don't want to install MySQL on my machine just for that. Then I remember that I could be using container technology to allow my machine to run a container since containers are usually disposable. I could install MySQL on my machine using a container, use for what I wanted and then just discard it. So I'm just going to show you here how can I run that. And the command line is big because my fonts are big but basically you're doing a Docker run. I'm going to give you a name which is the name of my container. Red hat, Java one. I'm going to set a MySQL root password which MySQL password dash D which is to detach. I want to run that in the background. I want to run that in the foreground. And here I pass the name of the container that I want to run. I want to run MySQL and I can pass a specific version that I want to run. So that's just this. If I push enter, it's going to bring me the hash of the container that I'm running. And if I execute a Docker logs, you can see it's very big but we have a lot of logs here. But basically it says that MySQL is running on port 33 or 6. So it's successfully running inside the container here inside my notebook. So I could get and just use it for development and everything else and it would be all okay. Another very good practical use case for container technology is usually I'm a comedian or master or am I using the latest version of MySQL but I'm developing version 3.0. But one of my customers, they are still using version 2.0 and they're using an older version of MySQL and they hit a bug. I need to fix that but I don't have the exactly same MySQL version. I don't want to uninstall the version that I have to install an older version. Just to fix the bug and then have to install the newer version again. So what can I do? I can, for instance, just as I instantiated a five, six, 32 version of MySQL, I could be choosing like a five, four version or five version of MySQL to be running and it would be both be running inside my machine at the same time. At the moment that I didn't need the container, the MySQL container anymore, I could just dispose that to discard. The container is very easy. I could just need to get the container. Well, fonts are big, but it starts with F4. Docker is top F4. It is top in MySQL container and doc rmf4. Container disposed, nothing rests in my machine. So it's very fast. And if you have a public residence for that, I get the official repository for MySQL database on the hub. And these are the versions that are officially released in support for the moment. I have a five. But if you get to the history, you get older versions too. So you can deploy any of the versions that you want with MySQL database. So that's one of the benefits of container registry. You can publish yourself. You can sell to other people your containers or you can help other developers around the world with your containers. And you can also use container for front party to run your dependencies inside your machine. Of course, the example I gave is just a single container, but you can have multiple dependencies running inside your machine using Docker containers. And each one of them, you're gonna see each other because you have the capabilities of your team in the platform. I also like to announce to you that micro profile 1.0 has just been released and everybody's talking about that. Java 1.0 is a joint community effort from Red Hat, IBM, Payara, Tommy Tribe, London Java Community, Sojava and Hammock, particularly I'm Brazilian too, and I'm part of among the leaders of Sojava, which is the largest user group in the world. So we're all here to provide because we know that Java can do more because we know that Java can improve in the world of microservices. That's why we're trying to push forward the technology to allow developers worldwide using Java to deliver microservices even better and faster. And if you want to know more about that, I recommend you, there is a special event on Thursday, 11.30 on the microprofilelaunch.com. There is a limited amount of seats, so you might want to register if it is still available. If you want to know more about micro profile, I suggest you to check microprofile.io. And if you want to know even more about DevOps, microservices and lots of different things that we're doing, particularly writing a book about a very special subject, which is how to break monolithic database into a microservice database, relational database. And so I've been standing this topic for almost a year now and I hope to finish the book to publish that. It will be available at developers.redhead.com together with lots of articles, tutorials, videos, and many other orally books that you can download for free once you register at developers.redhead.com. And also you have all of the Red Hat software available for free for development. And if you want to know more, please join us. And I'm also available on Twitter at Yanaga. If you want to ask some questions, feel free, I'm here. But I'm also available on Twitter, okay? And that's what I had to say. Thank you very much. Thank you.