Well, hey, why don't you introduce yourself? Sure. Hey, everyone. My name is Ram Iyengar. I am currently serving as the chief evangelist at the Cloud Foundry Foundation. What that means is lots of free t-shirts and opportunities to speak with tons and tons of folks and get all the applause for the great work that the community has been doing so far. So what do you do week to week in that role? So there's a whole bunch of stuff, which is kind of boring in terms of governing the community and keeping the calls running and making sure that folks have the information that they want. They're not blocked by some GitHub workflows not working and the right repos not being archived and all of that stuff. But there's also the opportunity to keep pushing the boundaries on what the community is working on and experiment with the stuff that's coming out every week. So right now, I'm working with one of our newer projects known as Cloud Foundry Corifi, and I'm getting that to work on different infrastructure providers based on the documentation that the community members have given. So some of the stuff that we discover along the way are stuff that's undocumented and stuff that's new and stuff that might trip people up. So a lot of that also happens during the week. Yeah, that sounds like something that one of my friends, this guy Matt Ray, ends up doing at a lot of companies he works at, which is, you know, it often goes under the name of like community management or like you're saying, you know, advocate. But it involves this mixture of, as you're saying, you know, pointing out awesome stuff, right, and helping with that. And then also like some like taking care of like the infrastructure of the community and a little bit of like partner channel stuff here and there as we would use our lingo for it.
2:10And then, you know, whatever else comes around, as far as like helping out with that, with an open source project that has a lot of, you know, a lot of people working on it. But they're usually more focused on their actual like technical task rather than making sure that the whole sphere of things is working out well, which takes a special kind of person to like doing all those things. Yeah, I like to often refer to myself as user number zero for whatever projects that the community is working on. So it's, you know, always a pleasure to start working on some stuff and be the first person to do it on a lot of occasions outside from the contributors themselves. Yeah. So I should know this number. You probably know, but like Cloud Foundry has been around for a while now. And, and, and, uh, like it's been through many like phases in, in, uh, well, I mean, like anything that's been a while, it's, it's, it's had an interesting life. And like, like, like, how do you think of like the identity of Cloud Foundry now? Like, like beyond like, what is it, but like, what, what, like, if you were to meet Cloud Foundry somewhere, like, what would it be like? What, what would it like to talk about? And, you know, would it, would it, uh, would it be cheery? Would it dress nice? Would it, uh, be into gardening? Like, like, like how, what's the identity of it that, that you think of it? So the way the community and the way that the project itself has, uh, meandered is it's looking at a lot of active contributions. There's a lot of folks who still swear by Cloud Foundry for whatever, uh, they do. It's seeing a lot of success in the industries that it's being put to use it.
4:12And if I were to, you know, create an, uh, uh, a human, give a human form, uh, to Cloud Foundry, it would be a middle-aged, uh, person wearing a nice suit in the middle of a street in Switzerland or something like that. Okay, not quite retired, very professional still, uh, very functional still, um, I dare say anybody meet me and use the word legacy when referring to Cloud Foundry, uh, that would drive me mad. But, uh, yeah, it's, um, there's, there's some parts of the project that, uh, seem, uh, slightly older, um, and not as relevant. To folks in this era of orchestrated containers, um, in, in, in Kubernetes and with like the Docker wave, uh, there was a whole push for folks to move away from what Cloud Foundry was doing. And then with Kubernetes, yet another push drew a lot of users away from, uh, Cloud Foundry. And so there's been like a couple of waves, uh, that we've seen where, uh, folks have been drawn away from it, but we're also seeing growth from our big consumers like the Tanzu, uh, the people who work on the Tanzu portfolio come back to us and saying there's a lot more users who are getting on board. And there's a lot more users who are putting more applications on board to our Foundry. And so they, they have very positive things to say in those terms. Um, but then what we are not seeing is the kind of adoption that we saw, say five or eight years ago. Right. So, um, that's why I say slightly aging person. Sure. Sort of, sort of, sort of, but yeah, it is what it is in their career.
6:13Yeah. With, with, with some of the newer projects, we are seeing a lot of, um, adoption from like smaller teams as well. And, um, there's, there's, there's many reasons for it. We can probably go through it, uh, during the course of the chat, but yeah, that's what it is. Yeah. And to your point, right? Like I was just, uh, uh, reviewing, refreshing my memory. There was, there was, uh, uh, like there was this platform con the second one last week. And I was watching the, uh, the talk that the Mercedes Benz people who run cloud foundry given like, you know, I mean, they, they've been using it for quite some time and they run like 300 applications in, in production and, you know, 1500 services and on and on and on. And, uh, I think, I think they said they have about eight people who support it. Right. And so it is like, it is, it is, it is well-dressed and in control of its destiny and it's, and it's life. Right. And, uh, you know, there's, there's plenty of other, uh, organizations like that, uh, who are, are, uh, running their actual businesses on it or significant parts of their businesses, which is great. And like, so what, what did like, you know, you're, you're, you're mentioning at the beginning, right? Like working with, uh, with various people to get like cloud foundry running with Kubernetes on top of like, uh, various cloud providers out there. Like what's, what's like the goal with, with getting cloud foundry and Kubernetes working with each other? Like what's, what's up with that? So cloud foundry was meant always to take a. code base and return a URL for that code running as an application. And it was meant to obfuscate whatever the infrastructure was, this is running on. So, um, obviously the big success was to run these on VMs. And so if a majority of the developer audience want to work with Kubernetes right now for reasons
8:21unknown, cloud foundry should be able to provide that exact same experience on Kubernetes based infrastructure. And so that's the vision for trying something like this. People want a lot of the advantages of what Kubernetes can provide. Cloud foundry was already providing all of these advantages with a Diego, its runtime and with a lot of its own homegrown, um, orchestration layers and things like that. And so it was essentially giving developers what they want in terms of, you know, bringing the best of both worlds and converging this notion of convenience for developers and this notion of obfuscating the infrastructure underneath. And so if they want Kubernetes, then the community should be able to provide the cloud foundry convenience on Kubernetes. That's really it. Yeah. Yeah. You know, you're, you're, I was thinking similar, something similar this morning to what you're just saying is, is the, I think this is true. Like, like the, the, as you're saying, like the, what would it be? The design goal is the wrong word, but a use case scenario that it seems like the primary use case scenario starts with like developers in, in cloud foundry, right? Like it starts with what the developer experience is going to look like, and then more or less like works back into the stack from there. Right. So it has this view of that. Whereas like, if you look at like, uh, like a Kubernetes, it more or less starts with like the, what the infrastructure is doing. And, and like, and what you see currently is like, I mean, my theory of, of how all the container stuff and Kubernetes and all the platforms and service stuff has evolved is that, uh, like, like Kubernetes starts with that infrastructure thing.
10:22And just about now, everyone's like, yeah, it should be usable by developers. And so, you know, it's, it's the, uh, you know, and, and I think that's fueled along with all sorts of other stuff, fueled a lot of interest in, in like this, this arguably slightly new concept of platform engineering. Right. And it's, it's taking the idea of like, okay, you know, we're not, we're not doing Kubernetes the hard way anymore. Cause we figured that out or we just run it in, uh, in the public clouds or whatever, but now we need to like, finish it off to get back up to the developer part or the application developer, uh, part there. Right. And that, that seems to, that seems to be, you know, there's finally this, this reconvergence of like the lower level container orchestration back to just like platform as a service stuff. Uh, which is great now, now, you know, we can, we can pay attention to application developers, uh, on, on the whole again. Um, and, uh, yeah, I mean, I'm, I'm continually like, uh, whimsically bemused by, by that path of the things, but, um, it does, it does seem like now there's a lot to share between those two communities, right? Like, you know, as with respect to like, well, here's like, I was mentioning Mercedes and there's countless other ones, but here's, here's how we've been running platforms and, and paying attention to, uh, to developers, uh, in that area, which hopefully will pan out of the next, the next year or so, but, but to that, like, you know, in that area, like one thing I was also curious about, like, so if I look at like what platform engineering is, which is like this evolving notion, uh, of, I don't know, incrementally evolving DevOps, essentially. Like it seems like in platform engineering, there's a big emphasis on developer tools, like the project management stuff they use, the internal developer portals. And I was, I was, well, instead of me doing the thinking out loud in the form of a question,
12:23like, what do you think cloud foundries, again, to personify it, but you know, the community, like what's cloud foundries relationship with developer tools? Like how deeply integrated does it want to be with developer tools or not? Like what's its approach to the develop, the developer tool world? So historically the cloud foundry community swore by the cloud foundry core, obviously. So with Bosch and, um, all of that other fun stuff. And then they also backed the concourse project. Um, again, it's a very popular niche CI tool, um, that again, puts the developer experience at the forefront and a lot of people who've used it just swear by it, um, which is something that I love about, uh, the projects by the community. And then there was also back in the day, a pivotal issue tracker, um, which, which the cloud foundry was a community was, uh, very used very heavily. So it's always been part of the community's effort to continue to provide developer tooling for a lot of the, uh, needs of the community and serve in a developer first mindset, serve, um, technologists and engineers and engineering teams, um, in a manner that puts the developer experience ahead of any product thinking or any other usability thinking, um, stuff like that. Because again, in the concourse example, if you look at some of the UIs and the artifacts and the placements, it's, it's not the most visually pleasing, um, interface of all, but for developers, uh, who want their pipelines programmed in a certain way and who want their interfaces to work in a certain way, um, concourse is something that they love and, um, they continue
14:27to, uh, make use of it irrespective of where they go and things like that. So, um, there, there have also been a bunch of other attempts at providing like a ClickOps UI layer over a cloud foundry, um, installation. Um, it was called Stratos. Um, at the moment it's in like, uh, an archived slash maintenance mode. And there's, there's been some efforts to renew it, um, along the way, but like, uh, Stratos is another example of a project where the need for a UI based tool to, uh, serve as a dashboard, to serve as a place, to, uh, easily create services and, um, in, you know, float, uh, instances of an app and manage the app life cycle all through like a UI point and click mechanism was enabled for the community. So the community has always been aware of these needs and they've responded, uh, from time to time with tools and other things that, um, again, were aimed at core cloud foundry in a lot of ways. Uh, but also just gently serve the ecosystem. Right. Yeah, no, that makes sense. And, and like, yeah, like my, you know, like what I was saying to you this morning is the, like historically and probably futurely, if, if that's the way you're putting it, like the, the, the cloud foundry world isn't very interested in like the sort of like portals that developers use. Right. Like the, that, and that seems to be like the main difference. Uh, that between like platform engineering and just like DevOps, you know, broad, broadly put, right. Is that you, you essentially say like, oh, well we want to use like, like, you know, backstage or the humanitech thing or whatever, but we want the, you know, it's almost like DevOps, click ops or whatever to use a silly term.
16:27Um, but you know, having, having, having more of that, like project listing of things that you would have in an internal developer portal and things like that, which is, it doesn't seem like cloud foundry. You're so interested in like tightly integrating with and subsuming into that in the same way that like the emerging platform engineering practices. But I'm also comparing like a technology to practices, but like, but there's a, there's a, there's a second part to my answer as well, which is over time. We've seen your cloud foundry and the community becomes slightly more open and slightly less opinionated in terms of these exact tools that must be used with cloud foundry. So, um, eight years ago, when you looked at cloud foundry, it was always about, you know, this is our stack. These are our pipelines like it or leave it. Um, you know, so, uh, that that's changed and that's a very significant sort of shift within the community where we've seen a past tool become slightly less and less opinionated over the years. Um, swapping out the cloud foundry based Diego orchestrator for Kubernetes was, you know, one of these major shifts. Um, there was also the notion of building garden containers within cloud foundry, and then they allowed Docker containers to be pushed to, uh, pushed through CF essentially, and, um, Docker containers being deployed and managed through the cloud foundry interface. And so every time the community has sort of shifted, um, the, the, I mean, the larger tech community has shifted. The cloud foundry has created these minor changes in the product and reduced a lot of the rigidity, even in just this whole converging cloud foundry and Kubernetes attempts. The first attempt was, uh, just swapping out the Kubernetes, uh, orchestrator with whatever cloud foundry had.
18:30And for the rest of the, you know, peripheral projects that were required, you still continue to make use of cloud foundry based tools. And so the next iteration was, you know, let's swap out a few more components for CNCF projects. And then the present iteration is a very thin API shim for the Kubernetes layer. And then the rest of it is, you know, pick whatever set of CNCF projects you want to work with, and you basically can make cloud foundry work with them. So I think it's, it's a, it's a nice way of keeping a less opinionated, a more true to open source sort of route, um, and, uh, you know, showcasing how this project can fit into a lot of different workflows and doesn't have to be very rigid. So, yeah, so, so let's let you, like you, you know, you kind of went over the, uh, some, some evolutions of the overall community, right? Like what, you know, what would you say, like, who are the people and, and organizations involved in the cloud, uh, foundry community now? Like what, what's the, who, who makes up the community? So the big, uh, contributors are VMware, uh, with their Tanzu portfolio, uh, and SAP. So SAP cloud platform is essentially, uh, a cloud foundry redressed as the SAP platform. So a majority of our contributors come from these two areas. We also have a bunch of different highly regulated, uh, very federated industries in the form of some governments, banks, and, um, other places, which, uh, which also have like a bunch of different contributors come in. So like cloud.gov in the US and, uh, gov.uk PaaS, uh, in the UK are both major consumers of the cloud, uh, foundry platform.
20:31Um, they have a bunch of different contributors, uh, get in on the open source stuff as well. There's a few, uh, smaller vendors. Um, there's like any nines who I think are based out of Germany. Yeah. That sounds right. There was, yeah. Engineer Better who were based out of the UK. Um, I think they've gone through some acquisition. And so, um, I think they're no longer like major contributors like they were before. There was Stark and Wayne, which is also a slightly distributed sort of, uh, uh, vendor who was big on cloud foundry. Um, and they also went through a recent acquisition and, uh, we're not sure about how much they're going to come back and be able to contribute and things like that. But, um, yeah, that's our, uh, that's our major spread. There's also like a bunch of people who consume cloud foundry. Um, so like, I think the government of South Korea or something have a tool called pasta, P A S T A. Clever. Yeah. Uh, and, and they consume cloud foundry, but we don't see as much participation from a lot of others. So, um, um, I'm, I'm not going to name as many names, but, uh, yeah. Um, so those are like our major, uh, contributors and, um, for some specific projects like packet of bill packs, which is an implementation of cloud native bill packs is a cloud foundry foundation on project. Um, and, and those have a few more contributors like from Bloomberg and, uh, there's IBM, uh, who do good work on packet of bill packs and stuff. And so, um, yeah, some of the other, uh, foundation projects are seeing, uh, an uptick in, in maintainers from different companies, but, uh, a majority of the core cloud foundry contributions are, you know, VMware and SA. Yeah. You, you know, so you bring, you know, mentioning Paquetto and build packs and cloud native build packs.
22:33That's, that's another interesting area. I don't wander in around too much as it does seem like, well, I don't know, maybe you can tell me otherwise, but it seems like the largest part of the cloud foundry community that isn't like purely cloud foundry, right? Like, like, like the, like build cloud, build packs and cloud native build packs are, you know, can, can, and are used in non cloud foundry environments as, as I recall, right? So it's sort of like, how, how did that happen? Like, how did, how did it like, like escape the, the, the cloud foundry garden, so to speak, or not escape? How did it grow into, how did it grow into, in addition to? Yeah, no, I, I understand the intent of the question. Um, the, the, in, the purpose of build packs was, uh, the cloud, the purpose of cloud native build packs was never to be tightly coupled with the cloud foundry ecosystem. It was always thought of as an independent, uh, sort of project. Um, it always carried the vision of being a more general purpose container build system. Um, and that's what it has continued to, uh, you know, remain. So, uh, its, its core purpose was to overlap with the larger, uh, container and container orchestration community vis-a-vis the Kubernetes community. And, uh, it has seen adoption in, in these areas and there's some implementations. I mean, even last week, there was this demo by, uh, somebody from ING, um, based out of somewhere, uh, in central Europe. And they spoke to us about how they're implementing spark build packs and like Jupiter notebooks inside build packs. And, um, they've, they've created a whole platform for their, uh, data scientists using build packs.
24:33And, um, this has nothing to do with, you know, cloud foundry or whatever. And so, you know, in terms of, um, watching the community grow into areas that are slightly beyond, it just makes us very happy in, in one sense that, you know, the, the, the project is serving a lot of needs that, you know, it was basically envisioned to do. But there's also a path towards providing full cloud native build pack support within cloud foundry. And so once that happens, then, you know, this only improves the potential of now you can use cloud foundry for getting all of these workloads available through cloud foundry. So, um, you, you only serve to broaden the horizon in the longterm, um, with these tangential sort of short term explorations that you allow. Right. Right. Right. And, and then, and then, you know, can, can you, uh, like describe what a build pack is and, and like, like most importantly, like what you, you can see, I like to, uh, anthropomorphize or make human technologies a lot. But like, you know, like what's, what's the, the philosophy of how you like package up and deploy and configure applications that a build pack and a cloud native build pack like has what's, what's its approach. So, build packs borrow from, uh, the early Heroku version and the early cloud foundry version and, um, the design goal is to basically allow developers to give the platform access to source code. Um, without necessarily having to specify different build paths for different languages.
26:33So, build packs act as that interface that say, okay, here's an incoming, you know, source code and let's figure out how best to build this, right? Through a means of, uh, detection and analysis that basically goes in and says, okay, I can see a, um, bunch of, uh, Python files. So, I can see a set of Python based dependencies described in this, um, dependencies file. So, let me pick that up and, you know, um, decide that, uh, this is a Python application that's meant to run on so and so. And so, um, you can also create build packs for like a multi-language application. So, if you have a, let's say PHP backend that you want five instances of, and you have a React frontend, which is a very common thing, um, with two instances. So, build packs allow you to figure out, okay, this is how you want the application architected. And this comes at zero cost to the application developer. So, time and again, the philosophy of the, you know, community continues to remain. How can I make the developer think less and work less for these peripheral things like describing the application and architecture? Meta files like a Docker file, let's say, and how do you eliminate all of this extra work for the developer? And how do you continue to keep them focused on app development itself? And so, build packs take up this role of eliminating the need for something like a Docker file. And, um, if you remember like the Heroku experience of, you know, Git, Push, Master, Heroku, yada, yada. So, you don't necessarily specify what's the language your repo, uh, is, is, uh, what's the language in which the source code is inside your repo. You just give it access to the repo and Heroku is able to figure it out.
28:33Same with Cloud Foundry. And that same model continues to, you know, become true with cloud native build packs and Paqueto build packs or however you want to call it. And it's essentially that preservation of that developer experience that, you know, time and again is at the forefront of, uh, the foundation's projects. And in the case of build packs, it's a bunch of scripts that go in, figure out what is needed, what is not, and provide this sort of simple golden path for developers. That being said, there's a lot you can do to customize build packs to work the way you want as well. And so it comes with all of the hooks you need in order to configure build packs the way you want it and make use of build packs for very customized versions of a platform that you want to build and set up. So, um, it, it sort of, you know, works, uh, well, both ways. Essentially, uh, the anatomy of the build pack is a collection of scripts. It's divided into a life cycle. So four or five different stages, um, you detect, um, and then you do a bunch of analysis and see if, you know, the image layers are already built and if you have caches and things like that. And then you do the actual build itself of the app. And then the final step is an export. So you have scripts for each of these different phases that are just triggered and, um, runs. Right. And, and, and like you're saying, I mean, I think, I think one of the things that's appealing, uh, to, as you were mentioning earlier, regulated organizations and, and highly regulated organizations. Although I'm feel like I, I, I bet if you're working in a regulated organization, it always feels highly. No, no matter what. Uh, but is, you know, well, I guess it's kind of a side effect, but by now it's an intended effect. Is that when you use the, the build pack scheme, you essentially can control how software is built and assembled and deployed and configured instead of, and, and, you know, to put it on the, in, in the, I always joke that I don't talk like this to develop application developers.
30:47This is more of an, uh, like an infrastructure concern, but you basically can constrain what developers do. Or I think the new word I try to use is you can simplify it, right? Like, like you, and, and, you know, I think, I think the, the benefit of that is that if you, if you can control how things are built and configured and packaged and deployed, then it's easier to manage a lot of them. Right. Like hundreds and hundreds of those, and kind of go through and modify that as like, as we like that little team at, uh, at Mercedes, right. You can go through and the team that runs the platforms owns how it's built and, and configured and deployed versus all those developer teams who have to go in and fiddle around with that. When, when, when there's a change, which I think is, uh, you know, that's like, you know, going back to the, the, the Kubernetes stuff, like that's one of the starker contrasts between the two, the two approaches of the, the Swiss gentlemen. And however we personify Kubernetes, the, the, the rascally American probably would be a good, a good characterization of it. Um, is that kind of simplifying things, uh, on, on, on the developer angle there. And, you know, you also, you, you, you, you know, you brought up Heroku a few times and I wonder like for all types of container driven architectures and development, like the, the 12 factor app is still like this huge, like thought technology that people have. Which I remember, you know, back when I was an analyst at red monk, I mean, I think it was in 2009 or something or, or eight that they came out with these 12 factor things. And so it's like one of the more enduring, like general architectural things, like maybe right after the, uh, I don't know, whatever sort of like enterprise patterns and things like that. Uh, but like, how, how, how do you think, like, do you think that that's held up or like, is it something, is it more of a useful, like guide, like these 12 factors or like, what's the current state of it now, as far as it's kind of usefulness versus a delightful artifact of, of architectural history.
32:58Well, in my opinion, it's sort of become relegated to this very boring attribute that nobody cares about anymore because it's kind of become the default, right? Yeah. So, um, that's, that's really what it has become today. So, um, I was amazed the first time I saw Heroku and, um, the 12 factor principles were, you know, great. When I read about them, it definitely seemed to make things convenient. And, um, it was obviously very difficult to realize, uh, from the world that I was coming from, um, to be able to write true 12 factors, I had 12 factor apps for everything I was doing. But, um, the principles, like you mentioned, continue to endure, um, they're always in the background somewhere. Um, they're not named as much right now, but, um, you know, they've, they're, they're there, they're, um, they, they stood the sort of, um, testament of time in this after world. And, uh, they, they continue to be relevant, uh, in parts, um, in, in, in everywhere I see. Yeah, no, I, that's a good way of putting it. They're just like part of the systems now. So no one thinks about them right there. It's, it's almost like, you know, asking people what they think about asphalt. It just doesn't really come up very often, but it's, uh, it's, it's used every day. Well, you know, something, you know, the, the other, the other things that I, I was like asking people like yourself, people always asking me, this is like, well, first of all, how did you end up in like the tech world? What's, what's your own like path to sitting here today? Well, I went to school, um, and studied computer science. There was, uh, very little else that I was qualified for, uh, uh, after a college degree.
34:58Um, I started off as a programmer. Um, it was very mediocre as a programmer, but I had, you know, a lot of fun in talking about the stuff that I built. And understanding systems better and things like that. And, um, um, I quit, uh, being a programmer in favor of, uh, switching to academics and teaching computer science. Um, I did that for a few years and then, you know, I figured I wanted like a programmer salary, but I wanted a, a lecturer or a professor's job description. Right, right. That, that does sound like an attractive mix. Yes. And so, and so, uh, this path of, you know, developer relations happened along, um, when I was, uh, a product manager, uh, for a, uh, in, in a company. And then I, I started to realize that, you know, the, the biggest pain point that our users are having is not about, um, what to do with the product as much as how to get certain things done. And so you would see all of these users come in and not be able to figure out, you know, the path they want to take and things like that. And so, um, it was fun to apply engineering and product thinking to creating learning paths and educating users and, you know, bringing the sort of, uh, product knowledge that they needed in order to be more successful with the product itself. And so it was not about features for me at that point versus, uh, as much as it was about educating folks. And so I stepped into, um, you know, developer education and developer relations, um, and, you know, one product led to another. And, um, um, it seemed like a lot of different developer focused tools and products and projects were having this problem. And, um, along the way COVID happened and, um, you know, there was, um, there were a few job changes and stuff.
37:02And my first like full time, fully open source sort of role was with the cloud foundation. And so, um, um, happened through conversations and things like that. I came on board part-time and then, um, a bunch of different changes at the foundation led to taking on more responsibilities vis-a-vis marketing and, um, continue to focus on developer education for open source cloud foundry and things like that. And yeah, it's been a fun few years, um, with the cloud foundry community. Yeah. I mean, as you're describing, right, often with a, uh, uh, uh, a career path, like yourselves, yourself, you end up doing a lot of different things, right? Like I, I always think that, you know, you become, your role becomes like being like a, uh, to make a joke out of the old saying, you become like a hat rack. Like there's all sorts of different things that you take on and do, right. Like, which, which I, you know, it, it matches with that. Um, I haven't heard someone describe the dev rel outbound, whatever role as like wanting to be academic, but it's true, right? Like you, you, there's, there's, there's two parts to it. One, there's like the wanting to educate people or wanting to share what you've learned with people to, to put it another way. Um, but then too, there's also like the, how to take an engineering way to solve a problem or a structured way to solve a problem with an understanding of like the people involved. Right. Which, which I think like, I was just talking with someone yesterday who was trying to figure out, you know, in the best possible meaning of the phrase, how they were going to do digital transformation of their business. And, and they were needing, they were needing to like find the existing business processes and figure out the new way they wanted to run the business. And they, it was reminding me that like a lot of what I see is people start to take a software product management view of looking at the business, right?
39:10Thinking about who the users are and what work you want to do. And, but nowadays, especially there's like, I think most everyone, many people have like grown up with software as a part of how they run their life. And so it's a lot easier, like you don't have to force yourself to think about what would I like software to do here? Like you can be very imaginative about how it feeds in there. And then of course, like, you know, if you, uh, uh, if, if your, your reading list is as boring as mine, like, you know, the, the history of like management consulting is most of those firms were founded by engineers, which is an interesting thing to contemplate. So it's a very structured, like exploratory thing, just like an engineer would do. But anyways, yeah, that's, that's a, that's a good, good path. Cause as I'm sure you encounter it, people always want to know, how can I get into that? It seems like a great job. So it's always good to share. So, you know, the, the other thing is, is we've mentioned the cloud foundry foundation many times. So like, what, tell us about that. Like what, obviously it's the, the, the foundation that's a steward of cloud foundry, but like, like. Like what people not, not, you don't have to like name them, but like, what kind of functions does it serve? What, what kind of like capability, capacity capabilities does it have? Like, what does it do week to week? Like what's, how does it operate? So the foundation began originally as an independent nonprofit that was basically meant to be a vendor neutral sort of governance body for the cloud foundry project. Um, over time, um, you know, more projects were added to, um, the foundation's portfolio. And also in the year 2020, uh, we became a part of the Linux foundation itself. So at the moment we are a directed fund, um, under the Linux foundation. Um, we continue to have our own, uh, members, um, and you know, the, uh, goal of the foundation really is to, I like, I like, I like to put it, um, as it's responsible for two kinds of PRs.
41:22Um, there's, um, there's, there's, uh, you know, pull requests that community continues to do. And so we just make sure that everything runs smoothly. And there's also the press releases that we have to put out, which really goes to say there's, there's a lot of marketing efforts and marketing push that the foundation does for the open source, uh, cloud foundry project. So, um, it, it operates in these, um, two major areas. So there's always like a bunch of, uh, governance work that needs to be done. And there's also like a bunch of different marketing ish work that needs to go in as well. And so there's, there's the social media stuff, there's events that we host, um, there's a lot of, um, invited talks that, um, happen through the foundation owned media spaces like our YouTube channels and, you know, what have you. And, um, um, there's also, you know, maintaining, uh, some form of documentation and infrastructure for, uh, open source cloud foundry that, that the foundation is responsible for directly as well. So, yeah, it seems like, like thinking about what you were just saying that the, you know, among, among many other, let's call them shared services, but, but one that the Linux foundation really spends a lot of time on is basically marketing. Marketing, right? Like the, the, the shared, like, I, I don't know, especially in the tech world, people have all sorts of thoughts about marketing, which depending on who you talk with are mostly inaccurate or not nice, but like, like, you know, just like any other thing, like marketing is like, uh, uh, a profession that has a lot of like proven engineered skills behind it and things that you do. And like, it's not really like the, uh, the strength nor the interest of a lot of people who would be interested in working in open source. So it's nice.
43:22And it's all, it's especially hard to find marketing people who like understand the other side of marketing software, let alone open source stuff. Right. So it makes sense that you would have like one of the benefits of, of any, like a big foundation, like the Linux foundation would be that we, we want to make sure that we have like marketing and residents, so to speak as, as a service that people can go to, especially for, I mean, you made me think all this when you mentioned press releases, right? Like, like, like there, there are a few marketing artifacts that people that are more necessary and less reviled than the press release, like, like few people like working on press releases, but they're like, there's such an integral part of, uh, of the world. I guess it's almost like the asphalt thing, right? Like, I don't think anyone would say they enjoy like mixing and pouring asphalt, but it's very required. Well, it was speaking of events like the, um, so next week is, uh, uh, uh, a cloud foundry day. It's in, uh, is it, do you say Heidelberg? I, I, I forget how to say that the town, but it's, uh, it's on Thursday, uh, June 21st. And, and, uh, y'all, y'all were nice enough to accept the talk that I submitted. So, so that'll be fun to submit there, but like, what, uh, just to give, give people a little preview, like what, uh, what can people expect at CF day? So this year, a lot of the talks at cloud foundry day are going to be about how cloud foundry is very successful at scale. So we're going to look at a lot of insider information from how did we accomplish XYZ when cloud foundry was running at like planet scale workloads, both from, uh, big vendors. So there's like, so there's a bunch of talks by, uh, folks from SAP, um, some VMware and Tanzu folks too.
45:25Um, there's also any nines, the other, uh, smaller ish vendor that I was talking about. And they've also come forward to share some of their lessons about how cloud foundry is operating at scale and how it's been very successful for them and their customers and things like that. So the big theme at the conference is going to be about, you know, big CF installations and how it's able to hold up, you know, hundreds and nearly thousands of applications, um, as, as, uh, workloads and, um, you know, what breaks, what creaks and what, what's, uh, what's rough, uh, for, for the operators who are helping manage, uh, cloud foundry instances that support. These hundreds of applications and thousands of containers and what have you, so that's going to be the big theme at the conference. So we are, um, having a live, uh, conference at Heidelberg, like you mentioned, um, there's also a virtual component, uh, that people can, uh, sign up for and don't have to necessarily miss out on the action. So it's designed as a hybrid event. Um, and yeah, we're, uh, last I heard, we're very close to selling out. Um, on the, on the physical, um, version, uh, makes me very happy. Uh, it's been many, many years since, uh, there was, there's been a cloud foundry event in Europe. Um, so this was the first in probably four or five years. Um, what have you? Yeah. Yeah. Yeah. I mean, I mean, definitely as you, as you mentioned several times, all the, uh, the pandemic stuff changed calendars around a lot, but I was interrupting you. What, what, what were you saying? No, I was just saying, uh, going to, um, conclude by saying we're, I'm really looking forward to meeting a lot of people for the first time myself. So, yeah. I mean, I think, I think it's, it's a good location and like, like you were saying and indicating, cause there is, there's a lot of cloud founder use, not only in, you know, in Europe, but especially in Germany, at least that I know of.
47:29So it's, uh, it's, it's, it's hopefully it makes travel, uh, easy for people to get there. But then also, like you're saying, there's, there's the online component, which I think is, I mean, that, that is one nice aspect of, uh, of pandemic stuff. And so far as it could be a nice aspect is that it does seem conferences are generally, well, they're not always like hybrid events, but now we all know how to do them. Right. Like, like, like doing, doing online events is not a big deal. Like it's, it's pretty, uh, straightforward, uh, which, which is a good effect. Well, great. Well, uh, you know, I mean, if people were interested in more cloud foundry stuff or, or yourself, like what, what would you point them at? Like where, where could they look things up? So cloud foundry.org is always up to date with a lot of the information. There's a blog where we put out, you know, a lot of the important stuff, um, Twitter channels. Um, so at cloud foundry, uh, is the handle for the, uh, community stuff itself. Um, personally, I tweet from, uh, Ram Iyengar. So first name, last name, no space in between. And, uh, yeah, feel free to reach out, um, through either of these channels. And, um, there's also a cloud foundry slack that's more focused, um, through, uh, around the community. And like everybody who's a contributor is, is hanging out there and, um, will happy, be happy to have a chat about cloud foundry. So you can lead, uh, into slack through cloud foundry.org if you're looking for a way in. So I'd encourage people to reach out through these, um, two, three way channels. Yeah. Well, great. Well, it'll, it'll be nice to meet you in person next week and, uh, as well, I'm looking forward to it. Well, as always, uh, this has been Tanzu talk. You've either watched the live streaming, a recording, or listened to a podcast of this. There's almost too many options, but if you're, uh, if you're interested in the podcast, you can always go to tanzutalk.com and, uh, subscribe to it.
49:34And I'll put some links in the show notes to, uh, to things that we mentioned. And, uh, with that, thanks again. It was, it was fun and we'll see everyone next time. Thank you, Michael. Thanks for having me. Bye-bye. Of course. Bye.