VIDEO – Cloud Foundry Explained

5 min read

An overview of Cloud Foundry—an open source Platform-as-a-Service (PaaS).

In this video, I'm excited to give you an overview of Cloud Foundry and how it enables you to build, deploy, test, and scale applications without having to manually configure and manage your servers.

Cloud Foundry is a polyglot environment that is interoperable and open, and it's a truly powerful platform that allows you to focus on cloud native application development.

I hope you enjoy the video, and make sure you subscribe to see more like this!

Learn more:

Video Transcript

Cloud Foundry: An open source Platform-as-a-Service (PaaS)

Hi everyone, my name is Sai Vennam, and I'm with the IBM Cloud team. Today, let's talk about Cloud Foundry—an open source Platform-as-a-Service (PaaS).

Cloud Foundry: An open source Platform-as-a-Service (PaaS)

Now, Cloud Foundry is a platform in the truest sense of the word, in that it enables you to focus on cloud native application development and really puts a focus on developer experience. That's every step of the way, from developing the app, testing it, and moving it all the way into production, and automating all of those flows to make it really easy for a developer to get started.

Cloud native technologies

Now, there are a lot of technologies out there for doing cloud native transformation and modernization, but let's see where Cloud Foundry fits in with some of those other capabilities. 

Physical infrastructure

We've got a few things sketched out here but we'll get started from the bottom with bare-bones physical infrastructure. 

Physical infrastructure

I'd say that most companies that are using physical right now are really just getting started or maybe have legacy applications, so they're looking to move into the cloud.

Virtual machines (VMs), containers, and Kubernetes

Next up, we've got VMs. VMs continue to be very popular—they're a great way to package up applications, but with the growth of container technology, companies are starting to see the advantage and a more agile workflow by taking advantage of containers and something like Kubernetes (K8s) to manage and orchestrate them.

Virtual machines and Kubernetes

Cloud Foundry

Building on top of that, here's where Cloud Foundry comes in.

Cloud Foundry

So, Cloud Foundry, as I mentioned, has a very developer-focused approach. So, from every step of the way, they focus on the developer experience. And, I think one of the biggest detractors or most difficult things for a company to get started with cloud native is changing the culture within their company from the inside out, from the developer level up. With Cloud Foundry, your developers can truly focus on what matters—development—and they can just assume that the infrastructure works.

As important as it is, at the end of the day, developers don't want to focus on infrastructure—they just want to expect that things are running smoothly. 

Serverless

And that same kind of ideology applies to the top of the stack here with serverless technology, where developers focus on writing just functions, even less than just applications.

Serverless technology

Control vs. ease-of-use and speed

Now as we go down in the stack, we have control.

Now as we go down in the stack, we have control.

So, you get more control when you're working with VMs or Kubernetes on exactly how your app is deployed. But what if your developers simply don't care? What if they have applications that they want to run and don't care how the infrastructure looks and they don't care how it's deployed they just want a running application?

Well, that's where you get the advantages of taking advantage of something like Cloud Foundry and serverless. You get ease-of-use as well as speed.

You get ease-of-use as well as speed.

Building out a legacy application

Now let's actually take this—now that we have the understanding of where Cloud Foundry fits in—and say we have a legacy application and let's build that out and see how it fits into broader cloud stack. 

So, we'll say over here that we have a frontend application, and that in turn works with a backend.

So, we'll say over here that we have a frontend application, and that in turn works with a backend.

Let's say there's a legacy application with you know a lot of restrictions on security, networking, and how it runs and that kind of thing—and that's responsible for communicating with an old-school database.

Modernizing the frontend

Now we want to take this application, and let's say we want to make it cloud native—take advantage of a cloud-based platform. So, the first thing our developers will do—without understanding anything about the infrastructure—they'll start with the frontend and modernizing it.

Let's say they want to use something like React—take advantage of Node.js to create an all-new application, taking advantage of that frontend piece and we're going to move that into the cloud.

So, taking advantage of simply the dev tools that are available through Node.js and React and those capabilities, they create a frontend application—say that's version 2. 

Frontend application version 2

Now, so far, along that path, the developers had no reason to have to understand the underlying infrastructure. They created that application and next, let's say they've used a CLI tool. So, this is where Cloud Foundry comes in. 

Cloud Foundry is a polyglot environment

They use the CF tool to deploy that application into the cloud. Now, this is where the first core tenet of Cloud Foundry comes in, and it's the fact that it's a polyglot environment. 

Cloud Foundry is a polyglot environment

This means you can take applications written in a number of different languages, running on any platform, and CF has something called buildpacks that'll take them and automate all of the kind of building and deploying processes. So, using CF and any kind of language, any application, they can now deploy this into the cloud.

So, let's say that over here, this is the cloud side. They've taken CF, and now they have an application running for that frontend app. 

cf11

Building the infrastructure from the ground up

Let's take it a step back and build out that infrastructure from the ground up to see exactly what happened to take that application and to get it running.

So, at the bottom here, we have the cloud infrastructure. Building on top of that, we have the Cloud Foundry technology that actually is able to take this app and run it as a container in one of these—say they're VMs.

So here, we have Diego the Cloud Foundry tech, as well as Garden, which is remarkably similar to something like Docker or container runtimes. It's the container technology that Cloud Foundry used long before Docker was popular, back in 2011.

So here, we have Diego the Cloud Foundry tech, as well as Garden, which is remarkably similar to something like Docker or container runtimes. It's the container technology that Cloud Foundry used long before Docker was popular, back in 2011.

So using these technologies, Cloud Foundry takes this app and runs it and schedules it within a VM. 

So here we have our, let's call it the CFAR (Cloud Foundry Application Runtime environment) that Diego and Garden are kind of responsible for scheduling and managing.

cf13

Using Kubernetes with the backend app

So we've managed to figure out half of the puzzle here. Let's take it a step further—that backend app with those networking and security considerations. Let's say that we care about how it's deployed, we don't want it to be automatic, we do care about the networking and storage considerations, we want to run it in a containerized way, we don't want to go in there and change any code.

So we want to use something like Kubernetes. So let's say we take this backend application and containerize it. 

So we want to use something like Kubernetes. So let's say we take this backend application and containerize it.

So now it's running as a container—maybe in a container image. So we want to deploy this application to Kubernetes, right? So, we'll use a CF tool, or rather a CLI tool, and this time it's going to be kubectl. And we want to deploy this into the same cloud. 

So we want to deploy this application to Kubernetes, right? So, we'll use a CF tool, or rather a CLI tool, and this time it's going to be Kubectl. And we want to deploy this into the same cloud. 

Now, you might think we're out of luck because we're taking advantage of CF and Diego and Garden, but actually there's a new project that Cloud Foundry released called Project Eirini that enables you to swap out that underlying infrastructure—the Diego and Garden portion—and instead take advantage of Kubernetes. 

there's a new project that Cloud Foundry released called Project Eirini that enables you to swap out that underlying infrastructure—the Diego and Garden portion—and instead take advantage of Kubernetes

That means that we can continue to use those tools like kubectl and CF together in the same environment. Your operations teams would manage this side of the puzzle to make sure everything works seamlessly but your dev team has no impact for their CF apps because they don't really need to care about what's powering it. And for the apps that need to be run in Kubernetes, they can continue to use that same architecture.

So, using kubectl here, we can take that backend application and run it as a container within the same environment. 

So, using kubectl here, we can take that backend application and run it as a container within the same environment. 

And so essentially what we end up with here is the ability to do not only CF application runtime-based environment, but also Kubernetes together.

cf18

Cloud Foundry is interoperable

And that actually brings me to my second point here—the fact that Cloud Foundry is interoperable. 

So, using kubectl here, we can take that backend application and run it as a container within the same environment. 

Now, this is very important because, essentially, the fact that it's interoperable means that although the newest fad and technologies are changing over the years—growth of things like Docker and Kubernetes—Cloud Foundry keeps the same familiar developer experience for their users. But, at the same time, due to their open nature and open source and the fact that they're keeping up with the latest technologies, they have support for Kubernetes underneath the covers. This is very core for enabling our users to avoid vendor lock-in, to take advantage of the latest and greatest technologies.

Cloud Foundry is open

And that kind of brings me to my last point: Cloud Foundry is open.

Cloud Foundry is open.

It's open source and it has an open governance model. It's actually the CF Foundation; IBM is a core part of it and we do make contributions to CF, and it's a core part of our cloud strategy as well.

So we have kind of a lot of contributions that we make to help make this run smoothly in our cloud as well. Let's say that it's a core part of the open philosophy that powers Cloud Foundry—the fact that anyone can make contributions and features, it's completely open source. 

And the second thing I want to mention on that front is the fact that there's an open service broker API, meaning third-party services from any kind of contributor can be listed in something called a marketplace, allowing Cloud Foundry users to very easily integrate with those third-party services, taking advantage of an open service broker API.

So let's say that with these three core tenets and what we talked about today, Cloud Foundry is truly one of those really powerful platforms enabling you to focus on cloud native application development. And, it allows you to avoid things like vendor lock-in and stay up-to-date with the latest technologies, with things like Project Eirini allowing you to base all of these familiar applications on Kubernetes technology.

Be the first to hear about news, product updates, and innovation from IBM Cloud