 Cool. Awesome. Hi, Shedrack. Let's see. Can you hear me? Hi, everyone. Let's see if we can get Shedrack on board. Just one second. Cool. Hey, man. Hey, can you hear me? Loud and clear. We can. Okay. Awesome. Awesome. Sorry, I don't know what happened. It's fine. Cool. So, Shedrack, the floor is yours. Okay. Sure thing. Sure thing. Can you see my screen? Yes. Okay. Okay. Yeah. So, hi, everybody. My name is Shedrack Akintaro. I'm a developer advocate at the Cloud Foundry Foundation. And today, I'm basically going to talk about painless Kubernetes with Cloud Foundry. So, I mean, this talk is basically me trying to talk about the Cloud Foundry project with an open source project and how it leverages Kubernetes, how it abstracts about Kubernetes is to make life easier for developers that want to have their stuff or have their projects deployed on Kubernetes. So, a little bit about me is, like I said, I'm a developer advocate at the Cloud Foundry Foundation. I'm also a technical writer. I write for everything for blogs like Smashing Magazine, Logrockets, opensource.com, even Container Journal. So, I'm a very big fan of thinking character, and I'm always open to sharing my knowledge with the community. I'm also an open source advocate. So, I try my best to talk about open source software generally in various parts of the world, generally. So, let's just get started. I'm not about to waste anybody's time. And I want to make sure that we have time for Christians and there's time for everybody to really share their thoughts on presentation generally. So, Cloud Foundry, whenever you think Cloud Foundry, basically, Cloud Foundry is an open source platform that allows applications, application development teams to build, test, and deploy, and scale applications. So, to make this even simpler, if you're thinking Cloud Foundry, you probably should think Hiroku, but open source generally. Cloud Foundry was the idea of Cloud Foundry basically came about when you came out and people wanted to be, the VM were generally wanted to make sure that there is an open source version of Hiroku. That's how Cloud Foundry came about generally. Now, Cloud Foundry has been leveraging on Kubernetes for a while now. And I'm just really excited to talk about how Cloud Foundry leverages Kubernetes and abstracts over it to make deployments to Kubernetes even much more friendly than what we are currently used to. So, basically, the selling point of Cloud Foundry generally, I wouldn't use selling point because sorry for that, because it's an open source project. But what's the most interesting part of Cloud Foundry and what it really brings to your developer experience is how you deploy your application with just a single command. So, all you need to do is just to do a CF push and in the root folder of your application and it gets deployed to a Cloud Foundry close down any infrastructure of your choice. So, it gives you the flexibility of running your own infrastructure and having many Kubernetes on your own infrastructure and having the awesome developer experience that comes with Cloud Foundry. Now, next is code to Kubernetes in one command. Now, Cloud Foundry has now evolved over a couple of years. Cloud Foundry has been assisting for a while, but as of last year, Cloud Foundry evolves to allow developers leverage Kubernetes and developers that want to really, really have the flexibility that Cloud Foundry provides in general on Kubernetes. So, we still have the same experience that comes to that Cloud Foundry originally have to be bought this time for the four Kubernetes. So, the same CF push you use for just deploying to Cloud Foundry generally, you can also do the same for Kubernetes, which is the Cloud Foundry for Kubernetes project. I will talk about that ahead in the presentation. So, like I said, Cloud Foundry is just like a root code. It's on your own infrastructure. So, you can install Cloud Foundry on your infrastructure and manage it by yourself. And it could be on AWS, it could be on Google Cloud, it could be on wherever you really want to host your Cloud Foundry. It's basically on your infrastructure. So, think about the possibilities and the flexibilities that it gives you. And when it comes to scaling, it also provides that very easy support for you to scale your application or for your users with basically a single command, CF scale. So, the whole concept of Cloud Foundry is making developers or DevOps engineering teams even have sort of a very, very easy way to get the application from testing to deployments generally. So, it's one of the often part of Cloud Foundry that I'm going to be talking about. Now, the next is support all languages and frameworks. So, irrespective of whatever type of way you build your application, whatever language you use to build your application, Cloud Foundry produces, gives developers, teams generally the support for most of these languages. It could be Java, it could be JavaScript, it could be Ruby, to Python, depending on whatever team you're, whatever language that your team is using, Cloud Foundry has support for that. And it's always very, very easy for you to deploy your applications to Kubernetes. Now, let's talk about the Cloud Foundry for Kubernetes project. So, this is basically an abstract, bringing the Cloud Foundry, original Cloud Foundry developer experience to Kubernetes. I know like a bunch of us have faced a various number of issues when we are trying to test there with Kubernetes, trying to learn Kubernetes generally. So, Cloud Foundry has an open source project. The team came together to like, okay, why don't we bring the CF push experience that already exists in Cloud Foundry to Kubernetes. I mean, this is two open source projects coming together to like, work as one, which is always very, very exciting. Now, let's see how the CFOK project can really, really make this life easier for us, right? So, let's just give you a quick run through of how the components of a cloud application with CF looks like. Now, from your phone, from your browser, wherever it is, it is pushed to Cloud Foundry to any infrastructure that Cloud Foundry has been installed on through the CF API. So, CF API basically connects, gives you a movement of interaction between your cluster and you or the receiving end. So, from there, you can also connect, when you deploy to infrastructure, you can also connect to database, which is also known as a service in Cloud Foundry. We have like, Cloud Foundry has support for various on database, depending on your broker, from Postgres to MySQL to MongoDB. Basically, most of the popular database services are actually available on Cloud Foundry. So, this is how it is really structured. It's a very simple, it has a very, very simple architecture, generally for you, for you to easily deploy applications on Kubernetes. Now, the next thing is, like I said, it supports all language on frameworks, even on Kubernetes. So, I mean, if you have a kind of person that knows to like, I don't know, deploy something like a Gatsby application on Cloud Foundry or a Strapi application on Kubernetes, sorry. Cloud Foundry for Kubernetes actually gives you that power to be able to use those hipster JavaScript frameworks that maybe your front end is built with and deployed on Kubernetes. So, you don't necessarily have to be a very full, a large application, but if you for, let's say you want to try out or you want to learn how to deploy stuff to Kubernetes with all these hipster JavaScript frameworks. Cloud Foundry for Kubernetes generally allows you to do that and you respect the kind of language of frameworks that you're using. Now, how does the whole process happen? How does each really, really work in layman terms? So, the whole process is actually about four stages, right? When you are on your terminal or wherever you choose to make a command, when you run the CF push command, where the Cloud Foundry CLI is installed, it's basically what we, it has a build trigger. So, when this build has been triggered, it uses what we call build packs. We provide this in a runtime environment for your application. I'll talk about build packs after this slide a little bit. So, we basically use build packs. Build packs basically gives your application, in respect of whatever application you use, it gives your application its place for all, generally with a series of steps that already be specified for each build pack that is very specific to your language. So, if your application is a Node.js application, whenever a build is pushed, the build triggers actually help detect the type of build pack that has been the kind of application that will be built and assign it to a respective build pack. So, now that build pack could provide some stuff like MPM, could provide stuff like Yarn, depending on what your application really uses, then whenever the build pack is really has finished this job of allowing your application and installing your application and installing the various dependencies needed for your application to run, then it really just happens. And this really is generally created into an image. So, an image of your application is then deployed to Kubernetes on whatever infrastructure your application has been. You've basically installed CloudFarming for Kubernetes on. So, it basically takes your image of your application and then deployed to Kubernetes as just a single command. So, you do need to worry about the stress of doing those configurations yourself. You really, really need to know need to write Yarn for most of the time, except you have very specific configurations that you need to do. But you really don't need to have to write Yarn to be able to deploy your application to Kubernetes with CloudFarming. You all just need to do a safe push and leave the rest to the build pack and... Now, let's talk about build packs in the history of build packs. So, build packs, the first place is basically the CloudNative board heard about build pack was on Heroku. I mean, Heroku really did the love. Like Heroku really brought that change when it comes to CloudNative community. It brought what we called build pack. Now, the first version of build pack was created by Heroku, which was then taken by VMware, basically by Kibbutel, sorry. And it made their own version of the build pack, which is what CloudFarming did. The first version of CloudFarming was using. And then Heroku also created another version of a build pack, maybe trying to increase their range and also trying to make build packs even better. Then the CloudNative community came together and said, okay, why do we have to, let's say two different entities is trying to specify what kind of build pack is created and what not is created. Then, what now came about was the CloudNative build pack. Now, this is a specification that other people, other open source projects, other companies can basically use to create their build pack. So, Pivotal and Heroku came together to form the CloudNative build pack. And you basically, CloudFarming used the specification of the CloudBidpack, which I'm going to talk about after this slide. So that's how build pack really came into existence. Now, CF push. Now, when on CloudFarming for Kubernetes on basically, when you do a CF push, AppSource is taking through a phase with packet of build packs. Now, packet of build packs is a specification of CloudNative build pack. Like I said, it's built by, it's a project that we offer to the CloudFarming Foundation by VMware and it's currently being maintained by the CloudFarming community. So, this basically, this packet of build pack is basically an abstraction over the CloudNative build pack. It uses the CloudNative build pack specification. So, anybody can take out of the CloudNative with their specification and make a version of their own build pack because this is like the standard. So, the spec has been created and what VMware did with packet to build pack is to create a specification for it for the CloudFarming project. Now, packet of build pack makes it very, very easy for you to deploy whatever type of application you want to deploy on Kubernetes, basically. So, it does the recognizing of your application. You don't need to tell it that, okay, this application is in node. It scans through your application folder and sets it for very specific things. Now, for a project like a JavaScript project, for example, when you push, when you do a CF push, packet of build pack goes through the point of scanning, searching for a package audition, JSON in node models folder or a package log audition, which is very, very specific to the JavaScript community. Here and also for other languages, it searches for various very specific files to understand that, okay, this language, this particular project is just for, this is a Python project, this is a Node.js project and assigns it to the specified group pack. You can check it by going through your own time, installing the needed dependencies for that application to run. Then also, at the end of the day, everything becomes an image, which is then up to the deployed on Kubernetes. So, it still, if containerization process happens, and the result of the containerization to the which is an image is then deployed to Kubernetes. So, you really don't need to worry about stressing yourself of going through this process yourself. With build packs, with the packet of build packs, build packs generally help you in dictating your application language and then specify a list of commands that are needed for the application to run. So, let's go over the process again to make it even much more easier. So, you have your app source, when you do a CF push, to a cluster that has been, that has a Kubernetes cluster that has been created for you, with Cloud Platform for Kubernetes, it's then converts your app to an image and is then deployed to Kubernetes. That's how simple it is with just a single command, which CF push, which does the developer experience Cloud Platform really, really brings to Kubernetes and makes it even easier for developers to leverage the power of Kubernetes in an easier way. For example, before, let me just give you a personal experience. For example, before I even got into the cloud native space, I did not know anything about Kubernetes, even till now I'm still struggling in Kubernetes, but understanding how the Cloud Platform for Kubernetes really works made me really, really deploy applications on Kubernetes without having so much of the technical know-how. So, that's the experience, that's the developer experience that Cloud Platform really, really brings to Kubernetes. For Kubernetes, it's a really, really great solution for basically having an infrastructure for Kubernetes. So, a lot of teams is always at back, I want to scale to what is deployed to Kubernetes, it's really, really interesting. Now, Cloud Platform basically just brought the CF experience, the existing original Cloud Platform experience to Kubernetes and then make it easier for developers to just plug and play. So, just install the Cloud Platform, say like install Cloud Platform for Kubernetes on any infrastructure of your choice. I personally enjoy using Google Kubernetes engine, so install on any of those and you are good to go. So, just log in and you are good to go, that's how the Google Cloud Platform process works. Now, for example, now let's, this is a very simple process. Now, imagine you have a Node.js application that you want to deploy to Kubernetes, and that's how the Cloud Platform makes that process even easier for you. When you do a safe push, when you do a safe push and your project uses, you can deploy it back as detected that this Node.js application, these steps actually happen. Now, it looks for a Node, a Node modules folder. If there's no Node modules folder, it looks for a package of this own folder. Now, when this package, if I have this on file, now it runs an NPM install which will automatically create a Node modules folder and install all the dependencies that is needed for your application to actually work. Right? You, of course, use this in Node runtime. Then from there, when all these processes have been done, when all the required dependencies for the application based on what is in the package of this whole file, it then containerize the entire application and creates an image. Now, this image is just basically what is going to be deployed to Kubernetes. You do not really need to worry about how this whole process really, really happens, all you just need to do is to push your Node.js application and you are good to go. This is what happens underneath and you really, really don't need to worry about it. All things to build parts, the cloud-integer user and package-to-build parts and cloud-furnished for Kubernetes. Now, so now just, not just application code, but there's tools as well. So cloud-furnished basically makes it really, really easy for you to add other development tools through your whole process of deployments to Kubernetes. So I mean, a lot of us, I mean, we use Kubernetes as an infrastructure, but we need to, we like to always plug extra things to it and to the entire and the existing workflow. So things like GitHub Action and Secure CI, Travis, for monitoring Grafana permissions, you can really, really add these things to your existing workflow and to your existing deployments to Kubernetes's workflow. I mean, for much more things like track monitoring and CICT. So a lot of modern software development teams really, really likes to include these things in their entire process, which is really, really exciting. Now cloud-furnished brings that experience to Kubernetes and also allows you to plug in all these things wherever you want and as easy as possible. Now, how do you really get started with this with cloud-furnished for Kubernetes? It's really, really easy. You can check out these tutorials on CF website, on the cloud-furnished website. You always assume that you already have sort of like an existing knowledge of Kubernetes of how containerization works. And then we have a medium-pager, we do a lot of experiments with various other open source projects and frameworks. Then you can also check the YouTube video more with visual pressing on how cloud-furnished is really, really mixed your existing deployments to Kubernetes even easier. Yeah, so that's pretty much it. And we also have the cloud-furnished summit coming up very soon, which is also part of the Linux Foundation. And you can easily go to this link and register if you want to know exactly how cloud-furnished is really, really, if you want to see exciting talks from people that have used cloud-furnished for Kubernetes and want to share their experience with it, you can always go... This is happening in June. I think you can register and join the events, which is really, really going to be exciting DevOps-related events. So if you are really a big fan of DevOps too, you can also, I mean, most of us, I mean, you cannot be here if you're not a fan of DevOps, you cannot be here. So, but then, yeah, so if you are a fan of DevOps and Kubernetes, then you can always come to the CF summit. And so, yeah, that's pretty much how you can really, really have the pinnest Kubernetes deployment solution to what is currently your existing infrastructure. So if you want to reach out to me, you can always reach out to me at putdown.blog or Twitter. If you want to have specific questions you need to ask personally, instead of on here, I don't know, but advice you to ask all the questions you have here. Then at Cloud Foundry, of course, on Twitter, then if you want to join the Cloud Foundry community and really connect with other people that are using Cloud Foundry for Kubernetes, then Slack.cloud.org. So, yeah, that's pretty much it. Thank you so much for being here. And I hope I did not bore you. I hope I didn't talk too much. So, yeah, that's pretty much it. Thank you so much everybody for coming to this particular presentation. And, yeah, looking forward to hearing any questions. So is there any question that I should answer? If you have any questions, just quickly drop it in the chat section and I will do well to answer it. So I do not see any question currently. Uche, sorry, could you come on? Do you have any specific questions for me? Okay, so Uche is having the course on muting himself and coming on the call. I think we should probably wait for it to open. Okay, I think there's a little bit of technical difficulties and I'm sort of left in here. Yeah, so I think it's all asked, how do you want to connect with social media? Yeah, so you can reach out to me at CUDA on the scope of BNVCK on Twitter or just go to CUDA. Yeah, yeah, so I'm finally asked when I deploy to CUDA. When I deploy to Cloud Foundry, sorry, when I deploy to Cloud Foundry, do I have full access to the infrastructure? Essentially, yes, you do have access to infrastructure. Yes, every single thing you need to do, you have access to the infrastructure. Yes, you do. Essentially, I want to make Cloud Foundry like a pass for Kubernetes. Yes and no, but generally, okay, I would say yes. So Cloud Foundry being so, I saw it, it was someone said, you do not need Kubernetes, you need a pass. Cloud Foundry basically brings both experience. It brings a pass experience and also gives you access to Kubernetes. So it's generally a pass for Kubernetes. So I agree with you that it's a platform for service for Kubernetes. It's basically an abstraction over Kubernetes. So it's a pass for Kubernetes. Hi, I'm Boba Curve. I think which is having issues coming in. If you have any more questions, please do let me know. Cool, yeah, I'm sorry for the inconveniences or the inconsistencies, actually, I just... Yeah, shorty, shorty. Yeah, so yeah, it takes a lot of Shadrack. I think the session was really insightful and I know that was also the case for the attendees as well. Please feel free to drop your questions in chat sections. I hope for sure Shadrack would be more than happy to answer any questions you might have. Yeah, we still have a lot of time left. I mean, like 15 minutes, system is lost. Well, yeah, I'm just going to the YouTube live to see if we have any questions or if you two want to... Okay, cool, so it takes a lot of Shadrack. Of course, I do. If you are in Japan or if you are in Africa, you should know Shadrack please. And if you don't know him, please feel free to put him on Twitter. I think he just shared his Twitter handle as well on the chats. We could have luck Twitter to get information. So, anything just for me. Thank you so much for having me. This is really a very, very good initiative. Thank you the CNCF for doing this for Africa. Thank you Albuacca for, you know, I'm calling this, thank you Uche for being my cool presenter, I guess. Thank you everybody. Thank you everybody for coming on for this something. This is really, really exciting to see Africa embrace the cloud-netic space and also DevOps. It's really, really interesting and very, very exciting. And we only have the skies, really our limit, I guess. It's the limit we have. So, yeah, thank you everybody. Bye and stay safe.