 Hello. Oh, hi. Hello, everyone. Thanks very much for coming along. Welcome to Cloud Foundry 101, an introduction for developers. So over the next half hour or so, we're going to go and look what it's like to use Cloud Foundry, but from an application developer's perspective. So we're going to look at some main concepts and some commands to help you get started when you're first playing with Cloud Foundry. We're also going to look at what type of applications you can deploy using Cloud Foundry, how you manage services and databases, and also we're going to have a look at logging and debugging. We're not going to go very much into great detail of the internals and how the components work together with each other. We're just going to stay up developers for the next half hour. So before we crack on, who are these two strange people who have come here to talk to you for half an hour? So my name is Maria. I work for Pivotal. I'm a developer for Cloud Foundry, and I'm currently on the team that provides Redis as a service for the platform. And I'm Jatin. I work for Pivotal as well. So I work on a team which is trying to solve the problem of backing up and restoring Cloud Foundry as a platform. All right, so what is Cloud Foundry and why should you care? In a nutshell, Cloud Foundry is a platform or a tool that takes your code and does whatever it needs to do to make it a running application somewhere on the cloud or somewhere in a server. There's a famous haiku that you might have heard of which goes, here's my code, render on the cloud. I don't care how. And that pretty much describes it quite well. It's obviously a lot more involved than that in the background. But as far as we are concerned, it solves a couple of very important problems that developers face quite often. The first of them is that it gives you complete flexibility on how elastic you want your application to be. So you can have more instances of your application quite easily. You can have more memory or more disk on your server if you see that your application needs it. And that's quite straightforward to do. A second point is that it makes it really easy for a developer to have a complete replication of their environment. So a problem that I've had in the past is that I would be developing my code against a development environment, and then the production one would have a slightly different setup. And I would run into issues that had to do with the configuration, the setup of the environment, not so much with the code itself. So Cloud Foundry makes it really easy to just have exact replication between your development and your staging environment, your CI, and your production or whatever else makes sense for you. So how does the Cloud Foundry ecosystem look like? So Cloud Foundry itself, as you might have heard, is an open source software. You, as a developer, would never have to install Cloud Foundry. That should be done by someone in your ops team in the organization. You, normally, there are different flavors of Cloud Foundry that people install. So you could potentially just download the release, open source releases, and the operator can install Cloud Foundry open source. People also go for a different flavor of Cloud Foundry made by nearly all of these companies, which essentially provide support and their add-ons on top of Cloud Foundry and top of the open source Cloud Foundry. And that is deployed on-premise. So that is deployed on hardware that you own in your company. So the other option is to use Cloud Foundry as a service. So there are certain sites in which you can go to and sign up for a Cloud Foundry account. And then you will receive credentials through which you can deploy applications on their environment. This is really useful if you are just starting out and you don't have that many applications to push on Cloud Foundry, or you just want to try out Cloud Foundry. So the other scenario is that, how can you use Cloud Foundry on your workstations? Or if you would like to work with Cloud Foundry offline? So there is this tool developed by a pivotal called PCFDep, which you can essentially download and run on your local machine. So this will give you a condensed version of Cloud Foundry. So this is not Cloud Foundry as it runs on a server. So what we have done is taken all the components and put them on one machine. They will give you around the same interface as your application would have when it runs in the cloud. So we are also going to be using this tool for all of our demos. It takes around 15 minutes to install. It's pretty easy. So now we come to the next part of our talk, which is how a day looks like in the life of a Cloud Foundry developer. Maria? Oh, wow. Yeah, so I like trying to imagine that for a moment. You come into work in the morning at 9ish. You've had your favorite cafe-native drink. And you've gone to your desk. And your beloved project manager comes in and tells you that the assignment for that week is to create a web application somewhere on the internet that lists beers to its visitors. So you go away. You have a quick chat with your teammates. And you decide to deploy it as a simple Ruby web application. So let's have a look at the first step, which is, how do we deploy an app onto Cloud Foundry? So we've checked out the first step here. You'll see that we just have one endpoint. And that endpoint renders an HTML page, which aesthetically displays a list of beers to anybody that visits it. And if we wanted, we can go ahead and deploy that web application. That's exactly what we're going to do. The only thing that we'll have to change is that the instruction, the startup instruction, we will change the hard-coded 8080 port into an environment variable called port. Now, this environment variable is populated by Cloud Foundry. And it's important to use it like that for two reasons. First of all, it's the port where Cloud Foundry will redirect traffic. So we don't want to lose that. And secondly, it's a port against which it will run any health checks. It exposes it to us through this variable. So now we're ready to go with CF push and the name of the application. And this will go away and do stuff. So what's happening in the background? The first thing that happens is that the command line tool that we're targeting to talk to Cloud Foundry, which is called the CFCLI, will create a zip of all of our code and pass that on to Cloud Foundry. Once Cloud Foundry has our code, it needs, first of all, to determine what it's written in. So it comes equipped with a set of diagnostic scripts, if you like, which are called buildpacks. And their responsibility is to go through the code and see, is it a Ruby application? Is it a Java project? What is it? Once it finds that out, it knows how to build it. And that's exactly what it does. It builds it into an executable package, which in CFlingo is called a droplet. It takes that droplet and deploys it into a container and attempts to start the application in the way that we have instructed it. In the first seconds after it has attempted to start, it will perform some checks against the port. And if everything is up and running, it will consider the deployment successful. And it will give us back a route through which we can go ahead and access that application. So let's have a look at what our application looks like at this point, like nothing. All right, brilliant. Okay, so yeah, it's pretty much what we were expecting. Yeah, we have a static table and a little image on the top. So what feature are we adding next? Yeah, so what I would like to do, like when I deploy applications to the internet, the next step that I do is try to add some tracking on. So to figure out who is visiting my website and how many visitors I'm getting per day. So I normally do that with a tool called Google Analytics in which you can insert some JavaScript on your page and it will track visitors for you. So like we have done just that in our sample application. So in our sample application, we have a script tag from Google Analytics injected. Now this script tag needs some configuration. This configuration that it needs is my account ID essentially on Google Analytics and that is injected into this tag. So traditionally you would inject this configuration through different means. So the first option is you could just keep it in this inside the code or you could have a configuration file. What CloudFormerly asks you to do is keep all the configuration for your application in environment variables. So, and you can pull the configuration from your environment variable in your application. So the reason for that is your app code is then separate from your configuration code. So you could deploy the same app artifact onto different environments like Dev and Prod. So what we have done over here is we have said like the configuration for the account will come from an environment variable called GA tag and we can use Cloud Foundry to set that environment. So the way that you do that is you use a CLI command called cfsetn and give the app name and the environment variable that you wanna set. And if you restart the application, what will happen is that environment variable will be injected to Cloud Foundry and it will be replaced inside our tag there. So if you can go to the source. Yeah, so by magic we have our code injected over there. So what's next? So the other thing that you can do is you can see the environment variables set on an application. So the way that you do that is you have a command called cfn and application name that would give you a list of all the user provided environment variables or configuration that you have set up for that application. So this is the way you can access that. You can also see that there are some system provided variables and we'll come to those later. So now what's next? So our project manager is back and like apparently our amazing application has gone viral on the internet and how can we possibly cope with so much traffic? Yeah, I don't know. I mean it's a really good problem to have I think struggling for resources. I guess it means you have a lot of visitors. There's generally, as you may or may not know, two ways that you can provide more to your applications. You can either provide more resources to the servers more RAM or more disk, which is also known as scaling up. Or you can simply have more instances of that app serving requests, which is also known as scaling out. We can try and figure out what exactly the problem is by looking at CF apps or CF app beer as well. We'll give it for that specific one. So you can see next to, where am I? Over here we have how much CPU utilization we have and how much memory and disk we're using. So if we try and imagine a very high CPU load, for example, that would indicate high traffic. And in such a situation, we would probably think of simply having more instances of the application. Now Cloud Foundry makes it really easy for us to replicate our code. And we just do that with a command called CF scale. And then with a flag minus I, we can provide the number of instances that we want to run. So if we say that we wanted five in total. And that's pretty much all of the work that we have to do. We don't need to do any discovery or any load balancing or anything like that. Cloud Foundry will do it for us and then we'll start giving traffic to all of these five instances equally. To see it in action, if we go back to our page, I think we have added a little line at the bottom. It eventually comes up. Yes, which tell us which server is, which instance is currently serving our request. And if we refresh enough times, we should see it changing incredibly slow. And that was about it. If we had it, if we preferred to give more memory to our applications, for example, we use exactly the same commands, CF scale just with different plugs, minus M for memory, for example. Next step is that we need to drive engagement. And that's a very good point because until now we've had this static HTML table. So that's not very interesting. And our project manager wants us to enable users to add their own beer. Yeah, yeah. So as you saw, our application is extremely static. And the reason is because we don't really receive any data from the end user. And we don't save it anywhere and we don't push it out to the user again. So as we mentioned, in Cloud Foundry, the applications run inside containers. So it won't be a good idea to like write a file in the container that the application is running in to retrieve the data back. One reason is that container, like that data will only remain with that container and won't be shared across all the containers. And the other reason is more importantly, container is ephemeral. So you're supposed to assume that they can be destroyed and recreated anytime. So the encapsulation through which you can save data in Cloud Foundry is called a data service. An example of a data service is like MySQL or Redis or a Blobstore. So the way that you interact with a data service is you get a certain set of credentials through your environment. You connect to that database and save data into it. So you can look at the services, data services available to you on your Cloud Foundry installation by creating a firing of a command called CF Marketplace. So this will give you a list of services that are available. Like on the CF Dev installation, it comes with MySQL, Rabbit, and Redis and all of them have certain plans. So for our application, we can bind it to say a MySQL. So we create a service of MySQL and choose a plan. So this has now given us, like this is an automated way of creating a data store. So we have a usable database instance. So let's just take a moment to acknowledge what has happened here. So when I was working at my last company, it took quite some time to do this process. So what I had to do to create a database was create a ticket and then follow up with our administrator to fulfill my request. So that is self-served now and you can do CF, like create service if the operator has automated his workflow. You can get a database that you could use. So the next thing that we do is essentially like use this database in our application. So the concept or the lingo for like attaching a database to your application is called bind. So if you bind a service to, so we will bind our application to this service. So what this will do essentially is get the credentials for the service and give it or inject it into the application's environment. So if you look at the code changes that we have done, we have some very preliminary database connections. So we're just creating a table and we have some post request handle which will insert records into the database. The important thing to note here is like on line number four, we are connecting to the database using an environment variable called database URL. So this is injected in by our bind service. So this is specific to Ruby. So the Ruby build pack will construct the database URL from VCAP services which we will talk about more in a bit. So after we have bound and pushed our applications, you can see that all of our applications have started again and all of our applications are bound to that database that we created. So if we go to our app again and add some more data, the other DMS lookup is taken down. So now you can see the application can connect to the database as well and store data inside a data store. If you go back to the environment, we can see that in the application's environment, Cloud Foundry has injected a special variable called VCAP services. So this is common across all languages that you use on Cloud Foundry. And this essentially contains the credentials to connect to that database. So if you are like debugging something, you can essentially take that URL and use MySQL Client to hop onto the database and see what is going wrong. Yeah, and just an additional point that I think is quite interesting is that when you're running with five instances of the same application, they can also immediately see that one database. Cloud Foundry gives you that for free as well, which is quite cool. All right, so I think we've got a pretty mature version of our application. It's time to start thinking about a bit of our long-term strategy. How do we manage logs for it? How do we, what's our strategy if things start going wrong? So a typical approach to do logs in an application would be this one, for example, you have a log file that you open at the beginning of your code and then when something noteworthy happens, you might want to log some lines inside at those points and say, oh, this happened here, this happened here. For the reason mainly that Jatin mentioned before, which is that containers are fairly ephemeral, so you can't really depend on their permanent storage being available at all times, there's a better approach that Cloud Foundry adopts. And that is that you, all you need to do for Cloud Foundry to register the logs for you is to just put out any logs that you want in standard out stream. And that's pretty much it. So anything that touches the log file will just go and be replaced with the puts for Ruby. And that does a couple of things for us. So first of all, it mitigates that risk of permanent storage flying away and now still losing our logs. Secondly, which is also quite a cool addition, is if we have multiple instances of the application running, with a traditional approach, we would have to somehow be able to concatenate them into one or somehow coordinate them amongst themselves to find out what's happening where Cloud Foundry does that log aggregation for us. And it also gives you the capability of forwarding these logs to an external log drain if you so want to do. Brilliant, so we have the new version of the application pushed and we can run a command called CF Logs and the application name, I think. And this will give us a tail link of the logs at real time. We've added lines every time somebody loads the screen and every time somebody adds a beer, that's not a beer. So if we make a few requests, we're going to see in the other screen that logs are going to start streaming in, which is quite a good tool if you'd like to see how your application is performing. I think that's about it. And then the last step that we might want to look at at the last minute as all panics happen is what happens when we want to debug something. And for that, let's have a look at the last version of the application which introduces a random bug as bugs usually are. So yes, you'll notice that just on line five we have an exception, oops, we have an exception that checks for something and explodes if it's not there. So we'll just give that a moment to be deployed. So this is the point where it attempts to start the instances and we'll see that sadly it failed. Badly, actually. So it gives us a hint of look at the recent logs and this is the command. So we can have a look at that and this will probably give us an indication that, oh, oh, but as we forgot to say that must exist environment variable. So that is fairly straightforward to fix. We can simply see if set to end in that environment variable and that should have them start. That'll have them start. Imagine though that you had a more kind of obscure bug, something like a networking issue that you assume that you're able, for example, to ping Google.com, but you're not able to. This is something that you can't necessarily see from your logs. As in you can't very much see what the setup of the container is like. So things like interface configuration or what the local file system looks like. So for that, Cloud Foundry provides you with quite handy command, which is CF SSH, the name of the application and optionally the idea of the container that you want to SSH into. And it will open an SSH session on that container and you can do your troubleshooting there if you so wish to. Brilliant. So with that, I think it's time to go home. That's the end of the day. All right, so to summarize, we looked at, we explained to you what Cloud Foundry is and like the different flavors of Cloud Foundry. We took you through the basic Cloud Foundry journey for an application developer, so which is CF push for taking your code and giving it to Cloud Foundry to run. CF environment to set your configuration through environments. CF scale to add more compute capacity to your application. CF marketplace to see the available services. CF create service to create new services that you could use in your application with the bind and some debugging tools like logs and SSH. So I think with this, we hope to have given you enough information to go and try out Cloud Foundry for yourself. You can download it from PCF Dev. I think that is a really nice point to start with to download and just to try it out on your local. Thank you. Are there any questions or? Yeah, so the applications that we described are called 12 factor applications. So these are essentially stateless applications that you need to push to Cloud Foundry. So if your application relies on some state being there on local disk, that won't work. We have to encapsulate that state out into a service so that your application remains stateless and then you can scale services separately than the application code. No, so the question is, is there any way to scale the services? So I think that is a really service specific thing. So different services will handle it differently. So what is a binding, right? Like so in data stores like Redis, a binding is like they cannot create a separate binding for each app that joins Redis. It will give you the same credentials back. And for example, a data store like MySQL, it might create a new user for every time you bind to a different app, right? So that problem is really service specific and different services do it in a different way. The encapsulation that Cloud Foundry provides to you is just create a service and attach to it. So the operators of that service can scale it independently of your applications in Cloud Foundry. Does that make sense? However, if you have, for example, like we did five instances, is that what you meant? And you want each one to bind to different services? Okay, I see what you mean. So the binding is between the application and the service. So if you have multiple instances of the application, they're still the same thing if that makes sense. For them to be able to look at different instances, correct me if I'm wrong, but I believe they have to be deployed as different apps. Which you can do. You can simply, we did CF push clear. If we did from the same code directory, CF push clear too, they would be completely different entities at that point. Does that answer your question? Yeah. Yes. Yeah. Yeah, so that workflow really remains outside of Cloud Foundry. And so what you could do in, for example, if you would like more shards on a MongoDB cluster, you could update the service with the shard ID, for example, how many shards you would like, but it's up to the service author to actually like take in your variables and respond to your request. So Cloud Foundry does not have any inherent way of scaling services that is like, so what it does is publishes a service broker API through which people can implement it and host their services for Cloud Foundry. So the marketplace that you see is just a way to attach to a service. Cloud Foundry itself does not have any services inside of it. The CF Dev, the PCF Dev application that we showed you, comes pre-installed with like those three services, but that is specific to PCF Dev, not Cloud Foundry in general. Cloud Foundry is a platform for pushing applications and services, it allows you to take service data and attach it to an application, all right? Thank you very much. Thanks very much.