 So, hello everyone. My name is Kevin Yutton. I've worked at Triumph on Cyclotrons, Texon and McKesson Medical Devices, found Vuby, which was an incredible language, worked for a long time for Engine Yard, and then found Cloud Foundry and started going to Stark and Wayne. So, Stark and Wayne is the leading Cloud Foundry community support company that helps all sizes of companies build out their Cloud Foundry. Everyone at Stark and Wayne loves Bosch, loves Cloud Foundry, loves the community, and we want to make things incredible. Dr. Nix quote is, everybody deserves nice things. So, what is CF Tiny? Well, it started off last year as codenamed CloudCal. So, it targeted AWS, it used Terraform to build up infrastructure, Bosch and Nits to put a director on there with a jump box in front and created all the correct YAML files, pulling values from Terraform automatically. So, why? Setting up Cloud Foundry can be daunting. It's getting better every year, but it can still be a bit of a headache. So, we all know there's some giants and some literally puttons in the Cloud Foundry. You have the giants like Pivotal Web Services and certified Cloud Foundry providers and they have teams of sysadmins and they do their upgrades with hundreds and hundreds of machines and most of us are doing some of our stuff on Bosch Lite, single vagrant image. Sometimes it feels like that when you're using Bosch Lite. It's not very practical. It's only six gigabytes. You have to add routes. It doesn't handle a laptop sleeping very well. So, what's in the space in between? So, we had Bosch Lite free. We have small PCF from the PCF Sizer, a couple thousand dollars a month, six dollars a day, and we were kind of targeting, we could get down to six p.m. plus Bosch and a jump box, you know, twelve dollars a day, eight dollars if you had reserved instances, and this was actually a full Cloud Foundry on AWS. But who are we targeting? Developers, production. It was a good question to ask because they have like a bit different needs. So, we started rethinking CF Tiny and just making Cloud Foundry boot easier shouldn't be the goal. Plus, we kind of wanted to change the logo. This one wasn't really working for us. So, what is the definition of production? Well, I think some of us here are sysadmins and we know that there is a lot involved in keeping a system up and running. You know, with backups and redundancies and midnight pager calls. So, first thing, of course, you want to have backup recovery. You're going to have credentials coming out, you're going to have secrets, you're going to have your initial database imports when you set it up, and from day one, from the moment you get started, you want to know you can back build up. Because if you don't, if something goes wrong, a little bit down the road, you're going to have to start all over again. You also want to have maintainability. How easy is it to change and work with what you're doing? And you want to have it automated and scalable. How easy is it to repeat actions? If it's not automated, it's not repeatable. And you want to make sure you can do upgrades and you want to have high availability. But why do I have high availability last? Well, one of the common things I've seen is people, when they first start sending a cloud foundry, they're for the uptime, uptime, uptime. Everything else doesn't matter. Can we get 10 routers, multiple Diego cells going, and that's great until you have your first problem. So what's worse? A site that is up for a year that goes down and loses all its contents, or something that maybe fails once or twice a year, but you get back up and running in a few minutes. So we started looking at this list and we had solutions for some of them. Shield for back home recoveries. There was a talk just 10 minutes ago by the fantastic Dr. Nick. Maintainability, we have Genesis. And for automation and scalability, you want to do it with pipeline. You want to use concourse for that. Upgrading, most people right now have a test environment and a pre-prod environment and a production environment. They do their testing, make sure everything goes green, do some QA, move it along. And high availability is just more VMs, more money, and some smart architecture. Right now, it's getting better, but setting up cloud foundry is still a very daunting task. And setting up cloud foundry and backups and pipelines. Your kid's going to be in college, maybe in university, maybe to have grandkids before you're done, in some cases. So tiny cloud foundry basically asks you for a few things here. Some IMA keys, an SSH key that's in Amazon, the region you want. And you give it a domain name. And since, you know, it's developer friendly, you can give it one of the XIP or NetIP ones that were basically wildcards, and you run make all. 30 minutes later, 40, 50 minutes, depending on how fast compiling happens, you've got the infrastructure, the jump box, the Bosch director, cloud foundry all up and running, you can log in, start working with it. And you can also start playing around with Shield. So Shield, I mentioned backup and recovery, it stands alone. So you can actually use it to backup and restore the Bosch director after the fact. It has retention policies, plugins, it can output to S3, local file systems, wherever you want. We have lots of plugins. And we have multiple definitions. That's backwards. So we can also talk to Postgres, MySQL, Rabbit, Redis. So one of the nice features is, I have to thank Dr. Nick for the slide, you have your backups, you can also restore. Well, you don't want to restore to pre-prod or prod very often. But you want to test your databases. Tiny cloud foundry is great. Build it up, load it with some data, do your backups, do your restores, test the downtime, test the recovery. Do you want to have a disaster recovery story? Well, now you have a place to test it, to work on it, to develop it. So we use Genesis to help us with maintainability. So normally you just have one big manifest, a little bit unwieldy. Genesis will help basically separate some information out. So you have some root information for your infrastructure, and then you have some specific domain names and number of instances for, let's say, staging. But now they're separated out like that. You can have shared files and different ones here. And Genesis will basically let you deploy staging, pre-prod and prod. And Genesis v2, which came out actually on Friday, has kits that basically wrap up all the common stuff. So what would be in CF release and CF deployment or in Shield, all the global stuff that everyone needs. Makes maintaining your app very simple. You want to scale up, you just edit the environment file and do a Genesis deploy. And then you add a few pieces of information to a YAML file. So a Git repo, your Slack information, Vault credentials, do a Genesis re-pipe. You now have a pipeline. And this works for basically anything that Genesis will deploy. Makes pipelining very simple. And you can have it then, gate, so you have your testing, pre-prod, pre-prod, east, pre-prod, west, prod, west, prod, east. And you can choose the way you're going to release stuff. So we use Vault because it's used by Shield, by Genesis, by concourse, by your apps, by anything else. It's basically ubiquitous for credentials in a lot of places. And tiny CF is a wonderful playground because you can boot up a temporary Vault, put some creds in there, boot up the real Vault, and all you have to do, target both of them, run the safe target export, secrets, pipe it into safe target import. And you've just migrated your entire credentials database to a new location. Backing up and restoring it is actually quite simple with the safe tool. I have to put a thumbs up to James and the Starter Wayne team for making safe because it basically makes Vault fun to use. So boom, your credentials have now been moved to a new location. Nothing safe to disk. Your security people are really happy. Even though it's a Tory environment, they're thrilled. Well, it's a Tory environment. It's got credential management. It's got Bosch. It's all the pieces of production. Now you have basically a nice workspace, a nice playground for you to do all your testing, development, and you can scale it up. Put more instances in, you have your full environment. So there are some challenges. Cloud Foundry is constantly evolving. We went from DA to Diego, Bosch to Bosch 2 with Cread Hub and Cloud Config. They now are pushing the CF deployments, which is brilliant because now they can package up all the binaries. And when you're going, the 260 haven't known issue, where 261 fixed it, but now breaks a loss changes. So also when you go from Bosch to Bosch 2, the blob stores change. So tiny CF actually is great for this because now you have a place to play with. I have an old Cloud Foundry. I want to upgrade to a new Cloud Foundry. I have an old Bosch director. I want to switch to a new Bosch director. I want to make these changes to my ML. So these are challenges. But now we have a safe place that you can boot up very quickly to play with it. AWS is evolving. How many people have been using AWS? And some tool they ran last year stopped working this year because the API changed likely. New AMIs. They're no longer allowing you to boot these instances in this region anymore. Or new regions. So again, you know, you want to be able to play with your environment. And you have a Terraform plan. You know works. You boot it up. You just go in there, make a few edits or pull the latest version from us. And keep going. Terraform is evolving. They actually in 070 changed the way all variables are referenced. Broke all our scripts. So tiny CF is more of a guideline than a product. Because things are all changing. But that's actually part of its charm. It boots. We owe Cloud Foundry. There's no warden boxes. It's not a vagrant VM. It's following best practices. We wrote a document called the Codex, which we are trying to put down things like Buddha credentials store first, put your credentials in there, then boot Cloud Foundry. Let you play with manifests and the configs. But updates are the challenging part still. So what are the successes we had? It worked. It was a fantastic introduction to Cloud Foundry for anybody who was new that came in. Make all. And they have a fully working program. Any of you done software development and your teacher says, write this program. It gives you a blank screen. And you're like struggling, what's the first line? Do I import something? Is it main? Versus a teacher that says, here's the program. Make a line change in here so that the ball bounces twice as high. It's a lot easier for people to start learning if they have a working copy to play with. They can tweak stuff, see what breaks, revert, go back to when it works. So it's also great for testing and development. It's real world configuration. It's Bosch init. It is the Cloud Foundry release. When you're working with Bosch Lite, things don't always work the same way as they do in the real world. And it's actually production ready for lack of a better term. You just scale up the instances. This is the way you boot up Cloud Foundry if you're booting up production. Maybe you'll change the load balancers. But there's nothing in here that's really not. We are using in our default the T2 micros and T2 minis and T2 larges. The UUA instance you probably want to make, an M4 extra large because UAA is written in Java. And in production does balloon up to like a gig. At the same time, you want to have an environment for your people to work in. When someone shows up at your company, you want to be able to say, here's an IMA key, boot up your Cloud Foundry. Don't touch production. I don't know if any of you saw this tweet a month or two ago. Someone started a company, went through the documentation. They had the real production keys in the documentation. And he blew away the production database and they got mad at him. And I think all of us can agree that he should have been mad at them for that. So this is a work in progress. We have version one released and on GitHub. And we have the codecs, which is basically a manual walkthrough of version two as all the instructions for how to boot everything, how to run the Terraform, how to get the releases and the configurations and put them together. And we're making some changes right now for Bosch two. But we already have support for AWS and we have partial support for vSphere, OpenStack, Azure, Google Cloud. Depending on the release you're looking at, we haven't got them all off and running. There was a talk on Wednesday about Bosch multi CPI. And I'm having a look at that right now to see if there's a way of maybe using that to help shrink down Cloud Foundry for testing and development. Bosch uses large VMs and then maybe uses garden or some other Diego type deployment to compressing down because a lot of the VMs aren't going to be fully utilized. So we love Shield. And today, actually, two hours ago, the Bosch Backup and Restore talk happened. And we love that too. They're actually different domains, right? So they don't do scheduling, they don't do retention policies, they don't right now, they mostly save the local disk. And so my understanding is the Shield team and the BBR team are having some talks. And we're going to see if we can get a Shield plugin for BBR. So we can do all the scheduling. And BBR now is a framework to call all the backup and restore functions. So there was a keynote yesterday burned down the house. And if you're interested in BBR, you can have a look at that. So on the app calls, there's also Unicronls. And this is kind of an interesting thing to play with. You're not going to play with this in production. Tiny CF is a great place to boot up an environment and start playing with these Unicronls. They have the advantage of VMs and containers. Maybe we can use it to squeeze Cloud Foundry into like a smaller box to get some costs down. Tiny CF is a playground for stuff like this. I have a side project that's still in alpha stage to actually boot up a tiny concourse. I think everybody needs to have concourse pipelines. But you don't really want to have workers running 24 hours a day, seven days a week if you go on vacation on weekends. So I'm looking at having concourse boot workers on demand when a job comes in. And there's no workers available. It'll actually boot one up, do the job, and then shut down. So this is part of the tiny to try and keep costs minimal. We have in one of the repos Redis, but we're actually redoing some of the Genesis templates for Postgres, Redis, and other stores. So that's actually coming soon. So now probably the elephant in the room, if you were at the Bosch to talk, you probably are going, well, hold on a second, isn't Bosch to doing Terraform and building a Bosch director and putting up Cloud Foundry? Yep. So they're basically doing the same thing we were doing about half a year ago. And what they're doing is fantastic. And so we're right now looking at what parts of what they do can we put into ours. Now we still are looking at the day two part, booting up Cloud Foundry. Great. First day. But you still want to have backups. You still want to have pipelines. You still want to have all the other pieces. And that's what Tiny Cloud Foundry is aiming to do is go a step or two past the just booting up Cloud Foundry. Maybe another way to explain it is once ours is designed and written so that we're calling these commands in a very simple way with some bash grips. So once the environment is up and running, we want you to go into the jump box and we want you to play with all the pieces. So there's very little magic. So you go on there and you can modify the manifest and you can push up more releases. That's the whole goal is to give you a very quick to start environment to experiment with to learn on. So I might have gone through my slides a bit quick because I'm already thanking my colleagues because Dark and Wayne is incredible. They see a problem and they go after solving it. And the Cloud Foundry Foundation. And that's the reason we're all here. Cloud Foundry is incredible. And everyone who contributes to the Cloud Foundry community. So part of the reason I called this Gulliver's travel is because I'm standing on the shoulder of giants. And this is built on terraform and Cloud Foundry and Bosch and Bosch 2 and Genesis. And so I kind of see this or hope this will be kind of a stepping stool to help everyone else climb onto the shoulders and build what they want. So here are some of the GitHub repository where you can have a look. So the codex is basically a book that is a tutorial that tells you how to install Cloud Foundry with terraform with shield all the stuff that we're automating the manual way. And it does it for AWS and Azure and other platforms. So if you just want to sit down and read and say, how do I do all this? We have it in print for you. If you want to do the make all, the AWS NAT Bastion Bosch CF, which was the name before Cloud Cal, it's available. It's got the latest Bosch release. It's running an older Cloud Foundry because we're trying to move to the Genesis kits. But you can do a make all and it comes up. And that's actually what we're using to play with all the new features we've been making. Or at least the ones I'm using. Because it's kind of hard to get lots of infrastructure. And Genesis and Shield are on GitHub as well. So if you have any interest in them, there have been talks about them earlier today. So I think now any questions? Thank you everyone for your time.