PurePerformance - 040 101 Series: Cloud Foundry

Episode Date: July 17, 2017

What is Cloud Foundry? And why does Alois Mayr (@mayralois) say that Cloud Foundry is the most opinionated PaaS Platform in the world? Listen to this 101 show to get a good overview of what Cloud Foundry (CF) is, how it started and what offerings are available right now. Also learn what the main use cases are for CF Cloud Operators as well as for Developers that use the platform to push their applications and services.If you want to learn more or see Alois in action make sure to watch his Full Stack Monitoring on Cloud Foundry PurePerformance Clinic. ( https://www.youtube.com/watch?v=vsQHtdeizXQ&index=65&list=PLqt2rd0eew1bmDn54E2_M2uvbhm_WxY_6&t=1237s )

It's time for Pure Performance! Get your stopwatches ready, it's of our Pure Performance podcasts, the 101 series. Andy, today my head is in the clouds. Do you know why my head is in the clouds today, Andy? Well, it feels like your head is always in the cloud, a little bit clouded. Probably because the topic is Cloud Foundry. Yes. How did you know? Well, I just looked at my calendar and it says we're recording a session today, actually with our colleague, Alois Meyer.

Alois. Hopefully be connected with us through the cloud. In this case, probably the Skype cloud, and enlighten us on Cloud Foundry. Alois, are you there? Yes, I'm there. Hi, Andy. Hi, Brian.

Hello, Alois. Nice to join you here. Nice to have you. So, Alois, we brought you in because you are the technical lead, the evangelist, the key evangelist on Cloud Foundry technology out of our innovation lab. And I know you are doing a lot of work on it. Also, Mike Villager is another colleague of ours who is driving these efforts. But we wanted to use this one-on-one session today to really give the audience an overview of,

you know, what is cloud-founded? What do they need to know? What is, you know, why do we need to care about it? How does monitoring work there? And I think you have a lot of things to share. So it would be great if we can actually get started and say, hey, what is Cloud Foundry? Well, yes, Cloud Foundry probably is like a very well-known platform as a service offering in the US, but also over here in Europe. And it allows basically application teams to just push their applications to the platform

and the platform basically will take care of everything else. So it's really designed to give application developers the freedom to just focus on developing software and pushing software to production, and the platform will care about failover, scaling, orchestration, and all that stuff. So it's designed to help, you know, customers to bring new features, new microservices into production faster.

And just touching on, you mentioned platform as a service, since we are kind of trying to take this as a bit of more of a 101 series, you know, people might have heard of infrastructure as a service. And Andy, I'm not sure if we covered a platform as a service yet or not. I can't recall off the top of my head, but yeah, the idea going back of platform as a service is they have the, uh, the, uh, they have the machines, they have the operating systems, uh, they have the containers, uh, not containers as in Docker containers,

but they have those as well. But meaning the JVMs, the, whatever you're running in, you're just bringing your code, right? And putting in your code onto those components so that they take care of everything else in terms of what the difference is between like IaaS, PaaS, all these other kinds of differences are, right? Yeah. And I think we had a session with Mike Villager actually a while ago.

So people that want to go back, we did a session on what is IaaS and what is PaaS. And I think this was something that people can go back to. That's an excellent point, Andy. Cool. So Alois, now understanding what Cloud Foundry is, where did it come from? And I know there's some open source parts of it,

but then there's also commercial offerings on top. Can you just give us a quick overview on that? So Cloud Foundry basically is all open source so you can find all the cloud foundry components and all the important stuff on at github basically and it was initially invented somehow by vmware so when vmware like the large infrastructure as a service or on-premise infrastructure as a service company out there, worked on also targeting application developers and then making it easy for application developers to push applications

and not just to provision virtual machines. So the very first version of Cloud Foundry came from VMware. And then they decided to source it and basically, yeah, now runs under the hoods of Pivotal, which is like a kind of spin-off or joint venture between VMware and EMC. And yes, so Cloud Foundry still is open source. The main contributors to Cloud Foundry are employed at Pivotal. So Pivotal is like one large player in the Cloud Foundry community, and they're contributing the most pieces and parts to Cloud Foundry. But on top of that, then for enterprise, right? Pivotal, again, not to advertise for Pivotal or anything,

but they then offer the Pivotal version of Cloud Foundry that you can download, install, and run with their support. And also I believe they have like the Pivotal Cloud Foundry web services that you can use their infrastructure for as well. So there's a full-on open source version that you can run, manage and maintain yourself, and then there's the supported versions that Pivotal offers. Is that correct as well? Yes, correct.

That's correct. So the burden of open source software usually is always if you have lots of different components, you need to run simultaneously with different versions of every component. It sometimes can be really hard to have like a setting up and running which will really work and is production ready. And this is why Pivotal also offers what they call Pivotal Cloud Foundry, which is like a fully tested, streamlined distribution of Cloud Foundry where all the components basically

work together nicely and also support or provide enterprise level support for their customers. And they also have like additional components they offer on top of open source Cloud Foundry, which makes the life easier for operators and then application teams. Now, besides Pivotal, what other major commercial vendors do we have? I think there are a few. Yeah, so there are a couple there. One other very well-known proprietary solution out there is IBM Bluemix, where IBM

runs a Cloud Foundry cluster for you on their data centers. So this is like one. There's also like deployments out there from GE, General Electrics, like the Predix environment. There is like in SAP, they have their own environment. Also like HPE, Centrelink provides their own cloud foundry service. So there are a couple of companies out there actually running cloud foundry and providing and offering cloud foundry services to their customers.

Great. Cool. Now, a quick overview. If I want to install a typical CF installation, Cloud Foundry installation, how does this look like and what do I actually install? So with almost every platform as a service, you always need different components to actually run and maintain the cluster because the cluster is doing lots of different jobs and lots of different functions

in order to run the application team's applications, right? And in case of Cloud Foundry, you will need some virtual machines which all run different components from within this cluster. For example, you have components which are related to streaming logs from your applications or from other Cloud Foundry components. You also have components which are just for scheduling and orchestrating your containers. So whenever an application team pushes an application, which are just for scheduling and orchestrating your containers. So whenever an application team pushes an application, you have specific components to schedule those containers and apps.

Yeah, so there are a couple of different virtual machines needed to actually run a cluster and for this uh Cloud Foundry the Cloud Foundry Community invented their own um deployment tool so they they built Bosch uh Bosch is like the deployment tool to to orchestrate and and roll out Cloud Foundry clusters. And this is a pretty nice deployment tool because this allows you to actually run Cloud Foundry clusters on different infrastructure as a service vendors or layers. For example, on AWS, Google, Azure, I don't know, VMware, so OpenStack. So you can deploy your Cloud Foundry cluster on almost every infrastructure as a service layer.

Sorry, I was just saying, because you were mentioning the infrastructure as a service team, but you can also run it on your own hardware if you chose to do that, correct? Yes. But Bosch provides what they call a cloud provider interface. So it's kind of an abstraction layer between how they want to roll out Cloud Foundry and the underlying infrastructure layer. So there is a CPI for AWS, for OpenStack, for VMware. So if you run your own VMware cluster in-house or an OpenStack cluster,

you can use Bosch for OpenStack or Bosch for VMware to roll out your Cloud Foundry cluster. Perfect. And just what I wanted to say, so Bosch basically is then an equivalent to an Ansible or to a Puppet or Chef. That means it's a deployment tool that was specifically developed for the Cloud Foundry environment.

Yes, so it's more than Ansible and Puppet, but actually it's designed to roll out software, but it also has configuration management in there, so you can have different versions of different components and having Bosch roll them out. But you also have things like what would be Ansible Tower, where Bosch will monitor all the Cloud Foundry components.

And when Bosch detects that a Cloud Foundry component is not working anymore, it will just recreate the virtual machine and deploy the component from scratch and kind of have like a resurrection mechanism in there. Cool. So I assume you have stood up your own Cloud Foundry environment and you have installed all of these components? Yes, I did. I did it a couple of times.

So my very first test was running, I was really brave running Cloud Foundry, the open source version on my own. It took me about a week to roll it out on AWS because this way I really needed to care about everything in Cloud Foundry because all the different components in all the different versions.

But then I've seen I can just use Pivotal Cloud Foundry where everything is, you know, pre-packaged. And then it just took me like half a day to roll out the Pivotal Cloud Foundry cluster at AWS. And I also run a very small baby Cloud Foundry cluster on OpenStack in my office here. So it means if everything is stood up, well, let's actually before I ask that question, are there any terminology that we should know about some of the components uh that you are installing is there you know some names that

the the audience should should at least be familiar with because they may hear it so we already heard bosch um any any other terminology that you want to throw out there uh yes so um every let's say cloud operator who is you is in charge of running a Cloud Foundry cluster will not only know about Bosch, but the operator will also know about Diego Cells. So Diego is the runtime architecture in Cloud Foundry. So when application teams push their microservices and their applications, these applications will end up on Diego Cells. So Diego Cell is a very important component in Cloud Foundry where actually the applications from the teams will run on.

And yeah, so and on Diego's cells, in order to separate different environments, different applications, and isolate applications on the same virtual machine, on the same Diego cell, Cloud Foundry is making use of garden containers. So they usually package everything they want to run everything you know an application engineer or developer wants to run in garden containers so it's somehow

comparable to to docker containers but they build like their own rep around Run-C. So Run-C is also something that you probably should know when you deal with Cloud Foundry from the point of view of an operator. Right, but as a developer, you don't need to know any of that, right? Yes, as a developer, you don't really care about that. As a developer, you just push care about that as a developer you just push the application and you know have cloud found we do the rest so it's really just for the operators and so sticking on the operator then um so we have diego uh do they have to

so on the management side of things you know we know there's like the the logger gator and some of these other components how much do they have have to be aware of those or interact with those? Or are they really just, once they have it stood up, are they really kind of maintaining Diego at that point and watching that side of things? So what operators usually do is, so they have like their knowledge about how a working Cloud Foundry environment can look like. So a Cloud Foundry environment can just be like 20 machines or something, or 25 machines, but it can also be like running 500 machines, right? And the larger the environment gets, the more instances of every component I will need.

For instance, there is a component called the router. The router basically will route requests from the internet to application instances, but also will route traffic from within cloud foundry to other to other application instances and the operator basically would need to know what is like the best sizing for all of those components and how many instances of all of these components are needed basically okay so basically to ensure also the health of of the environment so that's interesting because you so it's like also it's a capacity planning

of all of these different components so that in the end the developers get a fast responding cloud founder environment where they can deploy their apps or microservices correct absolutely yeah yeah it's not like if you want to run a million Diego cells, well, you have to have the router and the other components that can support scaling up those Diego cells, it sounds, right? Yes. So if you really want to run tons of applications in CloudFoundry, you will need to have enough Diego cells available

to actually have the resources available to run those applications in garden containers and the more diego cells you're using the more routers you need you you will need so so as in from the point of view of a cloud operator they really are just you know in charge of you know running the cloud platform, the Cloud Foundry platform in a healthy way. Great. Right?

So, and maybe last question on this one, because then I want to switch over to the developer side, but is there any support within Cloud Foundry to help with this type of orchestration of the platform itself so is there information on hey you are running short of resources you need to do this so this is something that the cloud operator really need to judge and do by themselves yes so usually the cloud operator will need to monitor and track some basic metrics on every VM in there. And with Cloud Foundry or with Bosch, when Bosch deploys the Cloud Foundry components, it also deploys a process for every VM, which is called a monit.

And monit is, as you can probably expect, monitors on a very basic way all those components. And based on those metrics the cloud operator will get, the cloud operator can decide whether there will be demand or there will be place for more Diego cells or whatever. And once the cloud operator decided to, you know, spin up new instances or increase the number of Diego cells or routers or whatever, just need to change the Bosch deployment manifest file and do a Bosch deploy. And then Bosch will spin up new instances and whatever the Cloud Foundry operator wanted to do. So now switching gears over from the cloud operator to the developer.

As a developer, as Brian said earlier, I don't care about most of this stuff because the only thing I really care is that I can push my app or my service. And so what is it that a developer really does with Cloud Foundry? What is kind of the integration or the interaction point? And what types of apps have you seen people actually pushing on Cloud Foundry? For a developer, the only integration point with Cloud Foundry basically is that he needs to have a Cloud Foundry CLI or any way to push applications to a cluster. Usually this is done by a CLI or there are also integrations with CI tools or CD tools like Jenkins, where you can have a Jenkins job deploying a deployment artifact to Cloud Foundry.

But what happens under the covers basically is that you just push your source code, your Node.js app, your WAR file or whatever to Cloud Foundry, and then Cloud Foundry picks a proper build pack and downloads all the required dependencies in order to run the application. These are not libraries because the libraries, of course, need to be shipped with the application already, but the build pack will download, for example, a proper JDK, a proper Tomcat version and stuff, and then package everything into an ultimate deployment artifact, which is called Droplet in Cloud Foundry. And this Droplet basically is the source for,

or the image for the garden containers, right? Yeah, and going to the build pack for a minute, because I had the pleasure of getting some training in here, so I was fascinated by the idea of the build pack. When the developer is uploading their code or their packages, right? Cloud Foundry is looking at that and determining, you know, do I need Tomcat? Do I maybe need JBoss? Or the developer doesn't even pick which, you know, which technology, you know, which technology that they're running on. I think they can override possibly, right? But the general

idea is Cloud Foundry works this out for you and you don't even have to think that far. You're just packaging your code and deploying it. Is that, would you, am I remembering that correctly? Yeah, yeah, yeah, that's right. So the application teams do not need to specify a specific build pack to be used. They can specify a build pack.

But if they just push their source code or whatever, Cloud Foundry will pick up the right build pack based on heuristics and some checks. And yeah, so if Cloud Foundry detects that you pushed a Node.js application, Cloud Foundry will use the Node.js build pack. If you push PHP code, it will pick the PHP build pack and so on and so forth. And coming back to the question from Andy regarding what kind of technologies I have seen out there already um almost everything um i've seen most of the time i see like java applications and node.js applications but they're also like php um also like static html content delivered uh by an nginx uh out there I've also seen Go apps out there, but also .NET apps running on Windows machines.

So you can also run .NET applications with a full .NET on Windows in CloudFoundry. And are these, I assume though, I mean, because that's the beauty of platform as a service and the containerization underneath, I assume most people are building services, whether you call them microservices or whatever you call them.

But are most people building new apps using some new architectural patterns? Or have you also seen people trying to lift and shift their existing enterprise apps into Cloud Foundry than basically just using Cloud Foundry as a very, let's say, expensive infrastructure as a service provider? No. So people usually do not, you know, ship existing applications into Cloud Foundry or like their old stack. When you want to use Cloud Foundry and run Cloud Foundry clusters and leverage Cloud Foundry for your application environment, then you usually also need to re-architect your applications because Cloud Foundry is designed to run stateless application containers, stateless apps, or stateless microservices. And Cloud Foundry is designed that you always need to persist state into either like a message queue or any sort of database, Redis or whatever. So it's really designed to have like a stateless architecture of your microservices. And this way allows Cloud Foundry or the operator or whoever to, you know,

spin up or scale applications in cloud foundry pretty easily because they just need to to spin up new instances of the same application or the same microservice and and because since they are stateless you know and the state is persistent they can easily spin up new instances for every application and this way deal with load and stuff. So it's really designed for stateless microservices. And this is probably also like a differentiator to other past platforms because Cloud Foundry basically is an opinionated platform. So it really gives you like some kind of guidance on how applications should look like in order to best, you know, work with Cloud Foundry environments.

So promoting the 12-factor app concept, I would assume, right? Because in other PaaS environments, whether you are, I would assume, right? So that's perfect. Because in other past environments, whether you are, I don't know, talking about OpenShift or others, you basically have, I guess, more freedom, which allows you to do more things. But then the more freedom you have, and we've seen this in the past, the more you may diverge from how you should build an application. And so Cloud Foundry, even though it seems like it narrows me down a little bit, but actually it narrows me down in a way that I really build applications with an architecture that can actually scale cloud in a really large web scale.

And that's great. That's right. So it's designed to run 12-factor apps, and it's really just designed to run application containers in Cloud Foundry. And it really helps a lot in running and operating those applications with automated failover mechanisms, automated routing, everything you would expect from a platform as a service offering. But once you want to deploy your own databases,

you can use Bosch to spin up virtual machines right next to Cloud Foundry, but they will not be part of Cloud Foundry. However, you can connect your application instances with these databases then. If you want to connect a Cloud Foundry app with a database because you want to persist data, then you will need to make use of so-called cloud foundry services, where a service basically is the payload on how to connect an application instance with an external service like, I don't know, MySQL database or Redis instance.

And similar to everything else, they have a lot of those services built, correct? Or you can customize your own, but the general idea is there are a lot of these connectors already pre-built that you'll just say hey spin this up i'll give it my endpoints and attach it to my uh my cell and off it goes and runs right yeah so when you run like proprietary cloud foundry um installations you usually have like kind of a marketplace in there and in the marketplaces there you can just select different external services like databases or whatever to

to be used if you run your own cluster your open source cluster you will need to take care of spinning up those services on your own. Cool. So if I can quickly summarize what I learned so far, and I want to switch over to another big topic, but what I learned so far is on the one side, the cloud operators that need to take care of the cloud founder infrastructure itself and making sure that all the resources are available, scaling the infrastructure. We learned a lot about the individual key terminology within Cloud Foundry.

So that was interesting hearing about Diego, hearing about sales and knowing that you are building an application which can get combined with the build pack into a droplet, and the droplet is then deployed into Cloud Foundry, and then Cloud Foundry takes care of scaling for me. But as a developer, it really seems the only thing I need to do is I build my app and have multiple different technology choices. I package it up, and through the CLI, the command line interface, I can do a CF push, I believe it's called, and just push the app out there. And then magic happens and my application is available and hopefully automatically scales thanks to Cloud Foundry. Right. Yes. That's the way how everything looks like. Alex, I don't know if you knew this, but Andy is the awesome summerator. That's his nickname.

He's got quite a skill in that. And I don't even say, you know, I'm not even making fun of you at this point anymore, Andy. It's really amazing how you do this. So it's more of praise at this point. But thanks for telling me they're not making jokes that I understand that it's not sarcastic, but actually. Well, people don't know when I'm sarcastic or not anymore because it's just so ingrained in my speech.

So the last big topic for us, obviously, so we learned about Cloud Foundry. What about monitoring? And we heard a little bit about monitoring already. You mentioned that the cloud operators need to obviously monitor and there is some monitoring built in. But what does this really mean? And especially now from a perspective where what is not covered by Cloud Foundry and why do companies like Dynatrace actually provide monitoring for Cloud Foundry?

Which gaps are we filling? So when it comes to Cloud Foundry? Which gaps are we filling? So when it comes to Cloud Foundry or when it comes to monitoring for Cloud Foundry, you always have different use cases to cover. So there's always the use case of monitoring the applications or the microservices that have been pushed from the application teams, right? So usually when an application team wants to push new features into production, they are mainly interested in whether their service still runs smoothly, right?

So about the microservice health, actually, and whether there is some room for improvement regarding performance. So if it's really running fast enough, what is the response time? Do I have failure rates in my service? But also application teams usually are also interested in whether their service actually also runs smoothly with other services because microservices talk to each other and you need to make sure that your service consumes other services in the right way or your service actually is consumed by other services in the right way. So these are like things where monitoring helps a lot in order to understand whether services run smoothly in production.

And this is also where it becomes difficult for most of the monitoring solutions out there because, you know, tracking services and the quality of services on a platform that independently scales up or down application instances, moves application instances, you know, from one Diego cell to another Diego cell can be hard because you have so many moving components in there. And this is something monitoring providers need to tackle. And Dynatrace solved that problem, of course, to really track microservice performance

and how the microservice performance of each individual application instance can look like. So basically what's missing, it seems, is really abstracting the monitoring from the individual instances, the physical instances in these cells to the service level. So understanding what is the throughput, the performance, the failure rate, and the overall resource consumption of that logical service. Because to the outside world, the service is an endpoint or maybe multiple endpoints. And I don't care if there's one or 50 instances behind supporting that.

But from a monitoring perspective, this is what you really need to figure out. How do you monitor your endpoints? And then, I guess, giving feedback back to the engineers and also, I guess, the cloud operators so they know how are they really scaling. And did you just introduce a code change that is consuming too many cpu cycles and therefore in order to sustain the same performance you now need twice as many diego cells to actually run your service than before the code change and as a developer i may not care because i just make a cf push and it still magically runs but whoever has to pay the bill in the end i guess cares and the cloud operator also cares yeah so this is something

monitoring needs to um it's probably provide value in here uh and usually the the way on how to to you know get monitoring into your microserviceservices is done by building integrations into buildpacks. So since we already know that a buildpack is a very central component of Cloud Foundry where the buildpacks package the ultimate deployment artifact, there is usually the integration point where monitoring vendors can integrate and provide their agents to the microservices or to the application instances.

Now, we talk a lot about full-stack monitoring. And you just told us about the build packs i mean so i understand the build packs we can we can inject any monitoring tool into the build packs how would what is full stack monitoring then then mean is this an additional approach so so with the approach of the build packs as i've mentioned you will provide value and monitoring insights for your application teams. You will know how your microservices are doing. But what you miss basically is whether your cluster, whether the Cloud Foundry cluster itself, the platform, is in a healthy state or not.

And this is the other value and the other approach we always talk about. Full stack is where we deploy an agent on every Cloud Foundry component. So on every virtual machine which is rolled out by Bosch. And this way we can not only monitor the application instances, but also like the boxes and let's say the platform itself and provide answers to cloud ops, whether they need to increase the number of Diego cells, whether the platform actually runs smoothly or not. So this is what we see as full stack, having not only the applications instrumented, but also

the underlying platform providing value for both worlds, basically. And just from my understanding, does this still mean I deploy monitoring agents, obviously through Bosch, on the underlying Cloud its cloud foundry architecture but additionally i still need to inject the agents also through the build packs or is this something that can be automated so what our approach on that is that you no longer need to to integrate with build packs because once the agent is deployed on every Cloud Foundry VM

and also on the Diego cells, the agent will automatically inject the agent bits into the garden containers, which means whenever application teams deploy applications, they will be automatically monitored on that Cloud Foundry cluster without requiring them to add monitoring somehow to their build packs or connect services to their applications to enable monitoring. So they no longer need to do that. They just need to push applications as is and um you know dynatrace uh one agent will automatically inject into the garden containers and this is pretty nice because uh this way

it allows you to provide monitoring as a platform feature and and have everything automatically monitored because in a microservice environment or in a cloud-native environment where you have lots of different application instances and instances of microservices, you have Diego cells, like the compute VMs, basically, lots of different components. You have an orchestration layer, in this case, Diego. Everything is moving. The only way to really have insights what's running on your machine, whether you need to increase application instances or Diego cells or whatever, to find the root cause of any problem.

The only way to do that is basically to run the agents on the Cloud Foundry components and to get the full insight into everything in Cloud Foundry. Right. And taking that back, I guess, several months or I don't know how long ago, when you're saying once you have it on the cell, it automatically injects into each of the Garden C containers, this is as opposed to in the past where you'd have to do the bind service for the agent, right? This is the whole idea again, as you were mentioning, is it just spins up and it's going. That extra step of having to bind service for every cell that you're spinning up

or every container you're spinning up is gone, right? Yeah. Awesome. That's great. As an application team, you just deploy your application and you will immediately see monitoring results and monitoring data information in the Dynatrace UI about your application instances and your microservices. So it's really part of the platform. So I think I learned a lot about Cloud Foundry for CloudOps and developers.

Thanks for the monitoring intro and kind of seeing that even though Cloud Foundry itself provides some type of monitoring, there is a good reason why monitoring tools exist in that space because of the full stack approach, but also because of monitoring microservices, which always bring a new challenge to monitoring. It's no longer necessary or no longer enough to monitor the individual instances, but with the service itself from an endpoint perspective. The last question that I want to throw out there, because I've just heard it, I hear it more and more, and people say, well, Cloud Foundry is nice, but there are also other platforms as service providers.

And I know you touched based on this a little bit and liked the term that you used, Cloud Foundry is an opinionated platform. And maybe that's one of the differentiators that Cloud Foundry has as compared to others. But maybe as a last statement, what do you see out there from a competitive landscape? And how does Cloud Foundry relate to other initiatives that are going on in the industry? It always depends. So I see a lot of Cloud Foundry installations out there,

lots of pivotal Cloud Foundry installations, but also Bluemix initiatives are out there. Another very popular past platform is Red Hat's OpenShift, which is based on Kubernetes. So it's like a Docker-based PaaS platform where Kubernetes is the core and is somehow comparable to Diego, to the Diego brain for like orchestrating Docker containers on different nodes. But Kubernetes and of course, OpenShift is not an opinionated platform, which means you can't deploy almost everything in there. And it's up to you how to best scale and how to best persist data in those kinds of environments. So you can actually also deploy database instances in Docker containers on OpenShift. I'm not sure if this makes sense because a database is not something

you want just to scale, right? If you have not enough performance on the database side, you don't just want to, you know, spin up like three more MySQL instances because they need to be connected something. So scaling is good or works for application instances but not really

for for databases but of course with docker you can really push also like very large instances you can also like push your monolithic applications in containers and and use like your existing kubernetes open shift environment to run like your monolithic applications in in a jboss right so this is something that is is nice and and and open shift or in kubernetes but uh when you really want to run a microservice environment, you most likely also need to re-architect your environment. And then at least Cloud Foundry is, in my opinion, the platform to go because it's like a grown-up PaaS environment, right? Right.

Now, you mentioned the Docker containers and one point of clarification, and we mentioned this before we started recording, is I believe that you can, although it's running GardenC within Cloud Foundry, you could still deploy a Docker image within Cloud Foundry. Is that correct? So if you're already using Docker, you don't have to be like, well, I can't go to Cloud Foundry because we're using Docker. You can still push your images to Cloud Foundry. Is that correct? So if you're already using Docker, you don't have to be like, well, I can't go to Cloud Foundry because we're using Docker. You can still push your images to Cloud Foundry. Yeah. So if your teams already build Docker images because they want to build Docker images as their deployment artifact, right? Or when it comes out of their CI, you can also use that Docker image and push the image to Cloud Foundry. And then Cloud Foundry will bypass the build packs and immediately run the Docker images as Garden Run C containers. So this is also something you could do. a docker images radio uh then you just push it to cloud foundry and cloud findry will deal with uh running uh docker images as um garden run c containers right right excellent

all right um that was an amazing overview um you know for for my point um you know i i've known i've been looking into and had some training on the Pivotal Cloud Foundry side, but I think what I learned a lot more today is just more about the standard open source Cloud Foundry side that's not enterprise-related or packaged around by another company's offering. So I think there's a lot of interesting things in here. And I really just want to thank you for taking the time to enlighten us all much more on Cloud Foundry and how this all runs together and how it compares to some of the other components out there and other PaaS offerings. So I just want to take a moment. And I know Andy's going to probably have another summer reader component here in a second. But I just want to take the opportunity to thank you for coming on and explaining all this, because this has just been very, very, very invaluable

to me, at least. So hopefully it's valuable to our listeners as well. Yeah. Thanks, Brian. Thanks for having me. Yeah. From my side, I think I summarized enough already. The only thing that I want to say, this is great that we have these one-on-one sessions because there's so much new technology coming. It seems, you know, every day almost. And getting insight and an overview like this helps a lot for people that need to at can look at in case they want to know more whether it is on cloud foundry as the open source project or whether it's around monitoring use cases is there anything you can point us to and maybe links that we can also put on the website

basically there is a website something like dynatrace.com slash cloud foundry or something where you will get some information about cloudfoundry and how to best monitor cloudfoundry environments with dynatrace. But there's also a recording of our past Pew Performance Clinic where we also, you know, covered some of those questions we had today, but also have done like a live demo on how to work with Cloud Foundry

and actually to monitor Cloud Foundry clusters and applications using our full stack approach. So there is a YouTube video out there. Andy, you should know about where to find it because actually you recorded it. Yeah, we'll put that out there. That's a good reminder because we saw it in action. And Andy, I think Alois just renamed your performance clinics to the Pure Performance Clinics. So that's awesome.

Thank you, Alois. I like it too. Cool. All right. I think that's it from my side. Thank you so much. Brian, any last question that you have? No, but I guess I'll see if Alois does. Otherwise we'll do our little wrap up. Alois, any, any last words, any grand advice that'll help somebody, you know,

succeed in life or any, or just even at least for the rest of the day um i would be happy if you can see more people using our bosch add-on to run full stack monitoring for cloud foundry because we just recently added uh windows support there and would be happy to see people out there using that so So then this add-on again, this is for getting the agent out into the entire stack, right? Excellent. All right, so if you are a Dynatrace user and you're on Cloud Foundry, do as Alo's commands and use that Bosh add-on.

Excellent. Well, thank you once again. Really loved having this. And if anybody has any feedback or ideas or any other one-on-one topics they would like us to discuss, please go ahead and either email us at pureperformanceatdynatrace.com or you can tweet it over at pure underscore DT. And that's it for me.

Alos, do you do the Twitters or anything like that that you want to maybe see if people get more followers? Yeah, so I'm on Twitter as well. So Maya Alois, it's pretty hard to understand for non-German speaking folks. So it's M-A-Y-R-A-L-O-I-S is my Twitter handle. Would love to see some more followers in the next few days. Excellent. Well, thank you very much. Goodbye, everybody.

Goodbye. Thank you. Thanks, Andy. Thanks, Brian. Thanks for listening.