 Welcome to the essential getting started guide to Cloud Foundry. Thank you for joining us this morning. Let's get started. I'm Tyler Poland. I'm a technical director at Stark and Wayne. I help to ensure customer success and by leading our Cloud engineers like Tyler here. Yeah, and I'm Tyler Bird. As a Cloud engineer, I help to enable teams to build and maintain Cloud Foundries all across the nation. I'm also part of a larger team at Stark and Wayne that does Cloud Native enablement all around the world. Today, we're going to give you a broad overview on getting started with the exciting world of Cloud Foundry. Each of these topics will be covered in more depth throughout the conference. For the moment, our goal is to give you a template that will help you make sense of all that's going on these days in Cloud Foundry. We're going to cover a lot of ground, but we will try to leave some room at the end for some questions. If you don't catch us now, follow us on Twitter, catch us in the hallway, or track us down at booth B4. Before what? No, booth B4. Ah, Bazinga, so. Okay, we'd like to take you on a journey through the eyes of our three main characters, the developer, operator, and owner. We'll point out the benefits of each of them get from using Cloud Foundry. So let's set the scene. It's the 24th century. Where the explorers from the planet Earth roam the known and unknown galaxy to seek out new life. Wait, Tyler, what does this have to do with Cloud Foundry? You'll see. Okay. You guys came for a talk about enterprise software, right? So how about we have a little fun and talk about Cloud Foundry for the enterprise, right? Oh no, what have you done to the slides? So for our developer, let's use Wesley Crusher, right? He's just getting started and he shows some promise. You know, he just needs a little experience. Okay, I get it. How about we use Jordy as an operator? Basically, he's got to keep things running for everyone. Okay, sure. And, you know, he has to do it while the entire ship's about to explode. So who would be our project owner? Probably Commander Riker because he'd coordinate things across all departments of the ship and he has an awesome approach to sitting in chairs. It's true, it's true. Before we get started, though, we've got a quick way to show you on which slides, which role matters the most. Like the owner or an operator or developer. But first, let's get started about talking about a platform as a service. For the developer, simply put, a platform as a service provides developers the ability to self-provision their own applications, resources and services. For an operator, there is no longer a need to manually provision VMs for apps and services. Instead, they can focus on site reliability engineering improvements. And the owner can sell the platform to the business because the return on investment is the savings of time of no longer having to be concerned with developing and managing a platform as well as an application, faster time to market, and so on. Therefore, as a platform as a service, Cloud Foundry already helps everyone out. As that sinks in a little, let's look at it with an illustration. In the traditional model, our development and operation teams both need to be concerned with the entire stack. A new application often means provisioning new systems, a process which can take weeks or even months to complete. Scaling up an architecture also often includes these same long lead times because resources just aren't sitting around waiting to be put into service. And failure on one component or multiple components in this model becomes a big concern, often requiring next or same-day business support contracts from hardware vendors or significant redundancies for critical systems. The operations team needs Geordi, along with a fistful of data just to keep everything running. And then when we talk about infrastructure as a service, it creates the architecture that allows virtualized components to be adapted to and fits the needs of a given application. Workloads can be shifted across the virtualization layer if a system fails and extra resources are easier to build. Beforehand, since hardware is no longer available to be dedicated to one specific purpose. Developers deploying applications in this model still have to have some idea about the underlying infrastructure and how to work with the storage and other supporting services like databases. The components available and the methods needed to connect to those components will be infrastructure-specific, preventing a lift and shift of the application to the new infrastructure and resulting in vendor lock-in. Operators would still have to manage their service requests and maintain the application stack manually and manage security, et cetera. A cloud-native platform as a service, such as Cloud Foundry, abstracts away the details of working with the underlying infrastructure. Connections to backing components like databases are provided in a standardized fashion. Community-supporsed application run times are packaged with the application to ensure that applications run the same locally as they would in production. Applications are deployed with manifests that tell the platform important things about the application, such as what services are needed, what build packs are in use, how much physical storage is needed, or how many instances should be started. Applications can readily be ported to any Cloud Foundry that has been configured with the same version, services and rules, regardless of the infrastructure that it ultimately runs on. You mean I don't have to run my Trekkie blog on my laptop anymore? Yep. With a switch to Cloud Foundry, you'll be ready for development at warp speed. Bazinga. So the magic of Cloud Foundry is driven primarily by a few key concepts that we want to highlight here. Bosch is a powerful purpose-built tool for managing the life cycle of cloud software and cloud VMs. Cloud Foundry itself is just one of the many software packages that Bosch can deploy. Most importantly, Bosch is capable of monitoring the state of VMs it starts and provide for automatic failure recovery and a canary mechanism for safe software upgrades. The true power of Bosch lives in its cloud provider interface, or CPI. The CPI is an API that abstracts infrastructure differences from Bosch, enabling it to manage resources on an ever-growing number of infrastructures. The Cloud Controller is responsible for orchestrating the application life cycle and balancing demand across the cluster. When an application is first deployed, the stem cell application runtime and application are packaged into a droplet and uploaded to the Cloud Foundry storage called the Blob Store. To scale up an application, this droplet is simply executed as many times as needed. The router knows where all the VMs actively running any given application are located. Its job is to route inbound traffic requests to the VMs running the applications those requests are intended for. When an application scales up, the router knows how to direct traffic to those new resources. So what happens when something goes kaboom? The cold hard reality is that systems sometimes fail. Rather than trying to prevent those failures, the Cloud Foundry has been designed with the mindset of embracing them and being ready to respond when they occur. Let's take the example of a server failure. Within the infrastructure layer, the Cloud Controller is going to recognize that the applications that we're running on that host no longer have the proper number of active processes. And the controller will then fetch the necessary droplets from these applications and schedule them on the remaining available VMs assigned to Cloud Foundry. The router will first redirect traffic for the missing service instances to other process nodes for that same application. When the additional VMs are brought online, that load will be spread back out to all of the available instances. And finally, Bosch will automatically work at the infrastructure layer to allocate a replacement VM to take the place of the one that failed. Restoring your Cloud Foundry to its full capacity. To learn more, we recommend that you look at some of these additional resources. You know, we can't do a really deep dive into all the internals here. So these are some of the good starting points. Both Bosch and Cloud Foundry maintain excellent online documentation, which is also open for community collaboration. As a result, the documentation is current and thorough and keeps pace with the ever-changing face of Cloud Foundry. EDX offers an introduction to Cloud Foundry and Cloud Native Software Architecture as part of their massive open online courseware program. The ultimate guide to Bosch is a deeper dive into the power of Bosch and will walk you through various exercises on your local system. To run a Cloud Foundry locally, your best bet is probably CFDev. It's a bit of a resource-intensive program. It requires two cores and eight gig of memory, but it will give you your own space to explore with minimal time investment. There's also PCFDev, if you're interested in trying Pivotal Cloud Foundry. On a high-speed connection, CFDev takes around 45 minutes to install. The Cloud Foundry Foundation keeps a list of certified platforms running Cloud Foundry, which will explain what options are available on a subscription basis if you're not ready to build your own Cloud Foundry. Many of these services also offer free trials that let you experiment with deploying your application on a real production Cloud Foundry. Finally, if you find yourself stuck or just want to get to know more of the community, the Cloud Foundry Foundation runs an open Slack organization that you can sign up for. Now that you know a little bit more about Cloud Foundry, how about we just see a little bit of a demo and learn more about that? As we mentioned, Cloud Foundry Foundation has certified platforms. These platforms use the same Cloud Foundry that you'd use if you installed it yourself. Let's use the Pivotal Web Services platform as an example today and show you how simple it is to wrench your own Cloud Foundry in a matter of minutes. Of course, I've jumped over a couple of account verification steps here to show the best parts. Yet in over just a minute, I went from one click to sign up to a deployed example app and Cloud Foundry was ready and waiting for me to join. At this point, I've pushed the app and click on the link and it's running and it took less than a minute. So now we're going to take a minute to talk about proof of concept. For the proof of concept, focus on a quick, simple environment. Keep in mind that this is meant to be used to learn from and then thrown away. Typically, self-signed certificate will be adequate at this early stage. You'll want to be aware of what that certificate request process ultimately looks like in your organization and understand the turnaround time associated with it. But it shouldn't be a blocker. This environment is only going to be around for a short time. You don't need to be crisp at this point, but you do want to take a lot of notes and that will help you out when you get in future phases. So we also recommend that you identify a cross-section of employees to work on this project from the development, operations, infrastructure, security, and compliance teams. These early discussions and exploration will help when you're putting together the proof of concept. Gather early feedback from then your stakeholders so that the concerns and issues can be planned for at future stages. And when you're ready to build a real thing. Try to keep this to a small lean team. Like we mentioned, four or five people is great. Start with minimal architecture. You shouldn't need to install more than five or ten applications and typically won't need more than ten to twenty application instances. Even if you are ultimately going to deploy to private in-house infrastructure, consider using a public cloud during this phase. This avoids the long lead times of acquisition and install and minimizes the size of the team needed to prove that cloud foundry will be the right choice for your enterprise. And many people may think that the next logical step to jump right in after they've done a proof of concept is that they have to own a cloud foundry at this point. As a general rule, as a general rule it takes around 120 application instances or AIs to reach an economy of scale where it starts to make sense to operate your own cloud foundry. This can of course be influenced by application complexity, instance size, and security and compliance rules. So keep certified platforms in mind for that. Another alternative are managed services which can fill in or augment your existing operations team and provide the deep technical expertise and experience you need to hit the ground running. So how do you safely transition from your current version to the new hotness? I personally like the Galaxy class, although the saucer separation was admittedly a bit impractical. One of the key differences in cloud foundry community is that we use infrastructure as code. And with infrastructure defined by code in your repository you can start to build a CI CD pipeline to manage your platform and to do upgrades and installs. When doing so, keep in mind that it's usually important to have a separate delivery channel for the platform. Whoops, skipped ahead. I put a click in there, but it's not the right one. And the application teams. Concourse fits well into this ecosystem and is designed to help deploy and manage cloud foundry. When it comes to the application channel if you've got something already like Jenkins, Travis, CI, or TeamCity by all means keep using those tools. Otherwise, concourse is great at deploying applications too. Stark and Wayne hosts an excellent guide at concoursetutorial.com that you can check out. Of course, there are still some things to watch out for. One of the most overlooked topics in cloud foundry but information technology in general is somehow, still, backups are ignored. Make sure you have them. Make sure you know how to use them. Make sure they work and back up the right things to actually enable a complete restore. Another common pain point is keeping up with the updates as the community releases updated stem cells and build packs for applications. Once you fall behind in applying updates it becomes more difficult to define the maintenance events that will help you catch up while also ensuring minimal impact to your application deployments. Then with certificates that you use in production you first need to research and find out the right one that you need to use especially for wildcards so that might be a SAN and all those different requirements for your certificates. You need to stay on top of renewing them because certificates expire, right? And then we also put in our link here to our blog because when we find pain points at clients we like to share the results that we find on our blog. So we recommend checking out our blog for the things that we like to share back to the community because a lot of times we share things in code but we also like to share things in blog articles that help other people out. So in this episode of Star Trek we have two captains stranded on a foreign world who are forced to work together and learn to communicate before a common foe can overpower and destroy them both. What we are talking about here is culture. Not only within your team's interpersonal relationships but also within your established business practices. Make sure you are speaking the same language. At this level we are all technical but our various disciplines have a tendency to reuse terms which can make it seem like we are talking in metaphor. Cloud Foundry will help you to adopt rapid delivery practices but they won't automatically create that culture for you. As an organization you need to be willing to adapt your processes and controls to maximize the advantage of new agility. Above all, keep in mind you are all on the same side. You are here to look for things. Things to make your business go. Thank you for joining us today. Live long and prosper. Anyone have any questions that we didn't go over? I imagine with people who are getting started you have a lot of questions. So that's fine. We do definitely recommend you come see us in the booth. We can answer a lot of questions but if anybody has any specific questions they would like to talk about so we would be happy to talk about those there. Yes they will. So some of your experience, what are some of the common pitfalls or things that can go wrong when folks are getting started? You had a couple of bits of wisdom for people just getting started, what would those be? The only way to share them is slides. Right. When we were talking about the cost of ownership or we're talking about ownership in general I would say that people really need to be committed to wanting to run Cloud Foundry. Just like let's say you think about getting a dog and you think it's going to be so fun to have a puppy take care of it. Do the research ahead of time and find out whether it sheds how much activity it's going to have how much time you're going to have to spend walking it and doing all that. If that's an analogy of you don't know how big it's going to get and how much time you're going to have to spend walking it and doing those type of things I think sometimes people are not, they just think oh this is going to solve all my problems and so that's one caution that I see that sometimes they're not knowing that it does take maintenance and care and it needs people who are committed and interested and committed to sticking to it. Yeah. Similar question. So the question is what are the gotchas to deploying your own proof of concept? Is that kind of a summary? Okay. So to try to refine the question is it that setting up a long-term playground for people or to just set up a proof of concept? Okay. So because in me the pitfall sometimes with just a proof of concept let's separate that question into two parts. The proof of concept can sometimes be you don't have time and fear of like I don't think I can finish this or I don't know what I'm doing kind of stuff and lack of knowledge. Setting up a proof of concept is just try to figure it out. But setting up long-term and having something to really sandbox in and learn is something that sometimes you just got to bite the bullet and build the proof of concept or do that. And the sandbox I think that having something to really learn from over a long period of time is this from an operator perspective or from a developer perspective? Or a little both? Okay. As a developer if you want to do that I would recommend being able to go to one of the certified providers and just because then you don't have to stand up a foundation. You can just use what's already there. I would just add that if you want to have a stable development environment that you want to keep you have to maintain some of the same discipline in order to make sure is it documented effectively? If this thing blew up tomorrow could I rebuild it? Does the data matter that lives there? And if so what am I doing to protect that? Am I doing the right things to monitor capacity within that environment? And am I shutting it down? Because probably unless you have a lab in your closet you're probably using GCP or AWS which means people are deploying stuff, it gets bigger, it gets bigger, it gets bigger and before you know it you're spending $10,000 on a month for 30 applications that aren't running and two that are. Yeah. Thanks. Any other questions? Alright any other questions offline please come and see us. Thank you for your time. Thank you.