 All right, so good afternoon to everybody. Thank you for being here. This talk is not a technical talk. You're not going to learn lots of technical stuff about Cloud Foundry. So if you're expecting difficult things, you're going to learn that it's not actually that difficult. Probably it's the main topic of the talk. So do you know the Cloud Foundry Foundation? Of course, this beautiful entity that actually allows us to use Cloud Foundry for free to work around the services, to create products, to actually live and somehow struggle with Cloud Foundry a little bit. So if you take a quick approach on this and you identify the companies that actually are part of the Cloud Foundry Foundation, you will see that 26% of those companies appears in the global Fortune 500 ranking. So it means that 26% of the companies that forms the Cloud Foundry Foundation, they have quite a huge amount of money, huge amount of incomes. And you're probably identifying them as really big companies. Actually, they are. So the problem is that if you take a look at a number of companies around the world, this is an estimated number. Of course, there is almost no way to know exactly how many companies are around the world. You will see that Fortune 500 is only the 0.0002% of the companies that are in the world. So the rest, probably the rest of us, belongs to the 99.99% 8%. OK. So before going forward, who am I? My name is Juan Pablo. I am from Argentina. I live in Buenos Aires. In the community, they know me mostly for my initials. JP is easier than Juan Pablo. So if anyone calls me JP, that's just perfect. I have been working in IT for 19 years, since I was 17. I have worked with S390, yes, Kabul, yes. I like dancing tango. I teach tango. I play guitar. I sing. I love working with Cloud Foundry, enabling companies to this new cloud native world. Please stay in touch. If you want to follow me on Twitter, I don't tweet that much. But when I tweet, it's not important, but maybe interesting. Or you can add me in LinkedIn. I stay there a little bit much in Twitter. Moving forward. So probably you're going to see this picture, right? You identify the monsters. This is a Clover from Cloverfield. And here we have Chucky, right? So it's a scale of monsters. If we take a look, if we put it in perspective, this is 0.002%. If you identify a small, medium business, if you have a small, medium business, probably you're going to be here. You're going to be working really hard to have your product done between Chucky and the depressed T-Rex because he cannot reach the beer, right? You're probably going to be around there. A small, medium business has very specific limitations. A system is defined by its limitations. So a small, medium business, you want to have a product as fast as possible in the streets. You want to have that product. You want to have that application running so your potential customers or even your customers can start trying it, can start building things with it, can start saying, OK, so this product is really good. You want to start getting revenue as fast as possible as well because your money is limited. I don't know if you're going to have startup funding or not. Probably not if you're a self-funded company. Your budget is going to be really limited. So you have to have a very, very fast feature to cycle, a feature to production cycle. I mean, you have to be very quick to adapt, very quick to fix, very quick. You have to spend your money very smartly. Your time, too. And of course, time is money. A small, medium business has these characteristics, right? And the last one is probably one of the most important of all, stay small until you can't. Growing is extremely easy. I mean, everybody can hire people. Everybody can build more infrastructure. Everybody can build by services. Stay small until you can't. Downsizing is the problem. So this is the main feature, stay in budget. A small, medium business stay in budget, right? How can Cloud Foundry help with this? Cloud Foundry actually puts developer first. The only thing that the developers has to do is focus in developing the product that you are building, OK? You can focus on your ideas. You can focus on your business development. You don't have to worry about infrastructure. You just worry about how your product can make an impact. It has this beautiful way of forcing good practices in cloud-native environments, 12-factor apps. If you're not familiar with the 12-factor apps, you should take a look. There's a very beautiful website. You can take a look at it. If not, please ask me. I will be happy to guide you through them. Cloud Foundry provides a really, really easy, really fast way to provide a product feedback cycle. You can push applications so easily to Cloud Foundry that it can be up and running in seconds. So the stakes holders are going to be up to date with the product, and even you, if you're working yourself only, you will be able to see your application up and running very easily. Cloud Foundry is ideally coupled with continuous integration software, whatever likes you want. And the community will love concourse as you probably have seen. But if you use Jenkins, that's perfect. If you use any other CI software, that's all right. So if you use a CI system plus a good test suite, you are done. That's a really killer combination. Cloud Foundry is quite secure and stable. You can have, I mean, in our company, we have had really big and small Cloud Foundry deployment in our customers for a long time without any single problem, no VM down, everything working perfectly. And this is one of my favorite parts, the community. Community is amazing. Dev list, the mailing list, the Cloud Foundry Slack channel, all the releases, security fixes, everything is provided by the community and the community is absolutely fantastic. Okay, so let's say that you are very small business and you have a very small budget, right? So like, I mean, in the range of, maybe you can spend 100, 200 bucks per month, no problem. You can still use Cloud Foundry using one of the public offerings out there. You have People Talk Web Services, you have Swisscom, IBM Bluemix, Centrelink, NTT, Ankara, Predix. You have your choices. You can choose one of them and start basically with this almost for free. You can actually start for free using Cloud Foundry. You don't have to pay anything. I don't care if you're using Open Source or one of these public offerings you're using Cloud Foundry that makes the community grow and makes the community even great than what it is actually. But if you have enough budget, I seriously recommend to go with Open Source, right? I am a huge proponent of Open Source. I love Open Source. So if you want to use Open Source, it's better. The problem is that this might be somehow familiar for you. So you do a botched deploy, it doesn't work. Why? Then you do a botched deploy and it works. Why? I think that's quite, it happens to you a lot, right? It's like, why, why, why? All right, so in this case, companies like us, like Altorus, that's when we come to help. We in Altorus, we have been part of the CF Foundation from the very beginning. We have lots of experience with Cloud Foundry. We are vendor agnostic. We don't sell any kind of distribution, whatever, we just provide services around Cloud Foundry. These are some of our customers. New customers are actually coming to us every day. We provide services from integration to trainings, from creating service brokers, build packs, whatever you need around Cloud Foundry. And yes, we are sponsors, called the sponsors. So we are very, very proud of it. Okay, enough with the commercial pitch. So what are we aiming at with this presentation? What I'm going to try to do is to have a Cloud Foundry deployment that is good for development, that is good for testing and demoing applications, that is suitable for very light production use, okay? Internal applications and first stages of the product release, like alphas and betas. This is not going to be like real heavy, heavy production usage, but it can work for the first stage of releasing applications or even using internal applications. It has to be very easy to manage. Very easy to manage is basically upgrading and disaster recovery and uses the best possible resources in your infrastructure as a service. Of course, cost less possible amount of money. We are cheap. We don't have that much money, so we have to shrink down the deployment. Has some HA, in this case, self-healing. It will have self-healing. We will have that functionality working, but this is what we are not going to have and this is actually why it's not suitable for large production usage. We are not going to have redundancy. This part of HA that is very important, we are not going to have it and we are not going to have true load balancing. Okay, so these are the limits of the system. This is what we are aiming at. Having this in mind, we have some options, right? If you don't have your internal data center that you may use VMware or OpenStack, you have these three options out of the box with Bosch. You can deploy a Cloud Foundry with Bosch in one of these three options. You have Amazon Web Services, you have Microsoft Azure, and you have Google Cloud Platform. For the sake of simplicity and that probably every one of us here played with AWS at some point, I choose Amazon Web Services for this like Ethereum or however you want to call it and because it's actually very widely used. To deploy Cloud Foundry, actually you have many different ways, but the preferred way in the community is using Bosch. Actually, you have the new releases are prepared for Bosch. You can upgrade Cloud Foundry very easily using Bosch. So you have two flavors. You have full Bosch, that's why it's in bold typeface, and you have Micro Bosch. The two differences between one of them is that Bosch is highly distributed. It uses many different virtual machines and Micro Bosch is only one virtual machine, right? So, and since we are trying to shrink everything, we are going to use Micro Bosch. So you have a killer combo that actually Dumbledore is very happy with that you use Amazon Web Services, Micro Bosch and Open Source Cloud Foundry. The problem is that when you deploy Cloud Foundry in Amazon, the size of it can be quite shocking because you have Micro Bosch, only one instance. Cloud Foundry takes 18 VMs, 18 VMs, one per each process, right? At that, you have to sum some sort of AWS services, like Elastic IPs and whatnot. This sums about 1300 USD per month. Yeah, power ranges are not really happy with this. So that can be a quite high number. So this is per hour usage, okay? You can save money if you pay upfront, but let's say that we don't want to pay upfront because we don't know if our business is going to be successful. So we want to go month by month. The deployment, the deployment is going to have lots of different processes. Each one of these little boxes is one VM, right? So you have console, HAProxy, NAT, ZCD, stats, NFS, Blobstore, UA, you have all the different components of a Cloud Foundry deployment, one per VM. That's highly costly. So we have to start trimming this. How do we do it? We start by using the right resources in our infrastructure as a service. So the Blobstore, we can easily replace it with S3. And S3 doesn't have a fixed cost. It's pay by usage. So if you use a very low amount of S3, you're going to have a very low bill in it. HAProxy can be replaced with elastic load balancer very easily. That's not a huge problem. Postgres can be replaced with RDS, right? And then you have three processes that are not essential for Cloud Foundry. That's the Cloud Global, the stats, and NFS. Those three can go just like that. It's not much of a problem. Then you have, this is the new layout of your deployment. How is it going to look? So we have these processes. We still have lots of VMs that are going to be up and running all the time, like 11. So we keep thinking, how can we shrink this even more? Even more, right? This is where Bosch comes to our rescue. Bosch has this fantastic feature that's called job colocation. So you can actually put two or three different jobs in one VM, right? If you configure it correctly, it's not a small task, but you can do it. So we can put two or three different jobs in each one of the VMs. The important thing is identifying the roommates, right? Who can live with another process? And that's kind of the key to the question. So the important process here is the runner. The runner is where your applications are going to be living. It's where the containers are created, are destroyed. When you push your application, where you restate your application, that's going to happen in the runner. So the runner has to be left alone. He likes to live alone. Nobody bothering him, the runner is kind of antisocial. So then you have other processes that actually likes living together because, for example, NAT is network intensive, but the API and the API worker, not so much. It's not that they're not network intensive. And you have the router that is network intensive, and it's also process intensive. So these can actually live together. They will compensate. Then you have, for example, the UAA and the health manager. As you notice, this is a regular co-fundry without Diego, right? I wanted to simplify this. This is without Diego running. You have the UAA and the health manager. This can be another VM, right? The UAA in a development environment where you have a small team of developers, it's not going to be very intensive. And the health manager also is not going to have lots of jobs running because there are not going to be so many containers. And then you have what I like to call the log VM that has logger, gate or Doppler and the traffic controller all together. This is very network intensive VM. We can size it, we will size it later, but all of these three can live together in one VM. And of course, you got console and HCD. And the thing with console and HCD is that HCD is very disk intensive. It's very disk intensive. HCD is right into the disk constantly. In fact, for one of our customers, we had to make HCD right to a RAM disk because it was killing actually the disks. That's something that can happen. So have it in mind. Console is not that disk intensive. Console is for service query and keeping some secrets. That's okay, that's good. It's not really intensive. So they can coexist. So right now we have reduced those 18 VMs to four or five, actually with the runner being on one VM. This is actually very nice, okay? So what we're going to do, we're going to size it. And this is one of the key parts of this exercise. So the first VM, let's put it in a C4. Why C4? C4 is AWS category, actually C is AWS category for processor intensive virtual machines. This will also, C4 has enhanced network capabilities. So the VM one that has two processes that are processor intensive and network intensive will have enough room to work with the API and the API worker. Then you have the VM two that is UAA and the health manager. You can easily fit it into an M3 medium. That is not really expensive machine. Actually, if you take the manifest from default Cloud Foundry deployment and you take a look at the Bosch manifest and all the machines, like basically an 80% of them are M3 medium with a couple of larges there. Then you have the Logregator machine that is also a C4. Why? Because they're mostly processor intensive and C4 has enhanced networking capabilities. And then you have the VM four that's an M3 medium. You don't have to have lots of processing power there. And for the runner, we live it alone. We have an M4 large. Okay, so M4 large, it only has eight gigabytes of memory. That's about 16 containers running without any issue. But for a small medium business, 16 containers is okay. It's not a small medium business. Maybe you can have eight instances of your application running according to different environments. That's okay, it's not that much. I mean, we're talking about small and medium businesses. We're not talking about big companies running hundreds of containers, okay? If you want to double that, you just use an M4 extra large that has 16 gigabytes of memory. You can have up to easily 32 containers running without any problem. So the number, this is the really important part. Number, if we take two C4 large, two M3 medium, one M4 large, we add 16 gigabytes of storage in S3. We add about 50 gigabytes per month of elastic load balancer. And we add 10 gigabytes of RDS and 10 gigabytes is a lot for Cloud Foundry, really. 10 gigabytes is like a huge amount. This, with this approach, we can get to USD 400 and Khaleesi said that it's okay. So the cool thing about this is that you can actually shrink it just a little bit more. How do you do it? Instead of using a C4 large, you use one M3 medium, three T2 mediums and one M4 large for the runner. These, with eight gigabytes of storage in S3, 25 gigabytes a month on ELB and five gigabytes on RDS, you can have it for 300 and Chuck Norris says it's okay. So that's fantastic. So this leader exercise, okay, shows us that we can have, like, instead of a huge 18 instances, Cloud Foundry deployment, we can shrink it to five. Actually, we can cut up to 75% of the cost of the original cost. And Dumbledore is really parting hard because he's really happy. Okay, so this is actually a very quick exercise. This talk is not long. And I really want to have your questions. Who has some questions? Nobody? Okay, that's the story. Okay, hey. I was looking at the implications of running it on GCP with that, like, per-maniflicing and the extra bits like that. Actually, no, I would love, actually it's one of the things that I wanted to do afterwards. What I'm going to do afterwards is with my company, we're going to develop a small Terraform script with a Bosch manifest that actually will provide this deployment in AWS. So what we wanted to do is we want to deploy the same configuration in Azure, the same configuration in GCP and we want to stress test it. We want to know what are the limitations of it. We have done this for small development groups, right? But they didn't do any kind of stress testing, but we want to do it. We want to know how much pounding can CloudFundry resist in different infrastructure as a service providers on this configuration. That's what we want to do. Actually, I tried to make it before the conference because I wanted to have it ready, but work constraints were impossible for me. But it's going to be a very interesting exercise. Just following through and Twitter, I'm going to be posting the results of this exercise because I really do believe that is CloudFundry is much more accessible than people think. I mean, so many times it's like, oh, CloudFundry, yeah, only big companies use that. Okay, no, it's not only big companies. You have so many options and maybe choosing your infrastructure as a service correctly can help you cut costs and whatever. So I don't have the same exercise for GCP, but we're going to do it, actually. We're going to do it, no problem. Any other questions? Yes, absolutely. That's the thing. And this is the principle that I pointed out before. It's very easy to grow. It's extremely easy to grow. You can, let's go back just a little bit. Dumbledore parting, yeah, yeah, yeah, yeah. With the help of Bosch, actually, you could, instead of co-locating jobs, you can say that one job belongs to only one virtual machine. So let's say that you start having lots of traffic in your application, right? So the first component that is going to be affected is the router. The Go router is the first component that's going to be affected. So very easily you can change your Bosch manifest to have the router on its own virtual machine. You can redeploy and you're going to be having your router working in a single virtual machine. This is one of the key elements of this configuration. You can scale very easily. You can scale very easily. But what happens if you have to shrink? Shrinking is so much complicated. Everybody who works with auto-scaling knows that creating new instances is very easy, but how do you shrink it back? What are the constraints? How do I reroute the traffic? How do I work with that? So this principle stays small until you can't. It's extremely important. It's extremely important, both for business and for application development. So yes, you can scale it very easily. Very easily. Questions, questions, questions. Wells? Nothing else? Okay, nice. So I have been very clear or too confusing. Okay, oh, there. Sorry. I did. I actually did. The thing is that Diego right now is not, lots of people knows this configuration, right? And Diego is kind of a newcomer and you still have to install it separately and it's bigger. You have even more jobs and processes running. So I wanted to keep it as simple as possible and lots of people are familiar with this configuration. So that was the rationale before this. But what we are going to do in the company, we're actually going to take Cloud Foundry even with Diego and we're going to apply the same rational process behind this approach. So we're going to do the exercise with Diego too. That's going to be very interesting, actually. Yeah, yeah, I consider Diego, but since Cloud Foundry has been working for so long with this configuration, for me, it was like more familiar to work with this configuration and that pretty much everybody will know what I'm talking about, is that I'm talking Diego, Diego Brain and all the components. But yes, I consider that. I consider that. Cool. Anybody else? Okay, sir. For all of this somewhere, we have a lot of you there. Not yet, not yet, but in our company, we're working on actually doing this and open source it. We're going to open source Terraform script to create all the resources in AWS with a bootstrap that will create the Cloud Foundry deployment and the Bosch manifest and the deployment manifest with this configuration. It's not yet, but it will. Good question. Actually, I don't really know. It all depends on our availability, but I think that before the end of October, we'll have everything ready. That's, we will have that ready. The next step for us is going to be, like I was telling before, stress test it, see how much it can take. But yes, I will make it available. I will make it available. Just follow me on Twitter. This is the thing here. It's not easy, but it's my nickname. Probably if I go to the start of the presentation, it's going to be, wow, takes time. Okay, so that's my, my nickname on Twitter. But yes, we'll make it available, absolutely. We are very interesting in people to be able to deploy Cloud Foundry in a small environment. Of course, I mean, if you're going to develop on your computer in a very, very small environment, you have PCF, PCF Dev. PCF Dev is absolutely fantastic, but it's only if you're working in your computer and you cannot install many more services. But PCF Dev is absolutely fantastic. I love it. I have it, I use it. But this is for mostly for teams that are working together on the same environment. Any other questions? Think that we're up with the time, right? We're pretty much done. Wrapping up, yeah? Sure, okay. All right, so thank you, everybody. Thank you so much. See you. Thank you.