In this RedMonk conversation, Ram Iyengar, Chief Evangelist at the Cloud Foundry Foundation, chats with Rachel Stephens, Research Director at RedMonk. Their wide-ranging conversation centers on developer experience from cf push and the promise of PaaS, to Korifi, a developer platform built by the Cloud Foundry community for deploying cloud-native applications on Kubernetes.
This RedMonk conversation is sponsored by the Cloud Foundry Foundation.
Links
Transcript
Rachel Stephens (00:12)
Hi everyone and welcome to the MonkCast. I’m Rachel Stephens and I’m here today with Ram Iyengar, the Chief Evangelist of the Cloud Foundry Foundation. We have been lucky to have Ram on a few times with a couple of my colleagues and I’m so excited to get to continue these conversations. Ram, for anyone who might have missed some of the other ones that you have done with us, can you please just give us a quick intro, who you are, what you’re doing with the Cloud Foundry Foundation?
Ram Iyengar (00:34)
sure Rachel, it’s an absolute pleasure to be having a discussion with you on yet another medium. we’ve had a lot of conversations in person. We’ve done some video episodes and now this podcast, think, we’ve checked about all of the boxes right now. And, yeah, so I work as the chief evangelist at the Cloud Foundry Foundation.
Rachel Stephens (00:52)
We really have.
Ram Iyengar (00:59)
What that means is I largely get credit for a lot of the work that the community is doing in terms of technical advancements and putting on projects and all of these things. I steward the marketing around a lot of open source projects and I focus particularly on the Cloud Foundry project itself and a lot of projects associated that are within the Cloud Foundry ecosystem and belong to the foundation engine.
Rachel Stephens (01:28)
Yes, and it’s one of those associated projects today in particular that we are here to talk about. It’s called Korifi. Before we can dive into that though, we have to maybe kind of talk a little bit about, I guess we’re gonna do a dive into history and we’re gonna dive in particular into the magic of cf push. And the magic of cf push is near and dear to my heart. It’s actually one of the first ways I ever got an app into prod. It makes me happy.
so we have to talk about how you talked about, so like the Cloud Foundry project is kind of central to the foundation. cf push command is kind of the core developer tenant of that.
And so I think we just kind of have to talk about just the Cloud Foundry project and the platform as a service kind of tenant of that project. The project was released in 2011.
and is publicly available then, if you kind of think about 2011 and the time span of technology overall, before Docker came on the scene, before Kubernetes, obviously. And so that’s kind of the early vision of the project, but can you kind of just talk about where this was in that space and time and kind of the vision of the project at that time and just kind of orient everyone where Cloud Foundry came from?
Ram Iyengar (02:15)
Mm-hmm.
Sure, the Cloud Foundry project is nearing 15 years. And in terms of like software lifespan, that’s almost like Jurassic level of evolution and longevity. So the Cloud Foundry project had always put the developer experience of
not having developers to experience anything in terms of overheads and toil between, the time they wrote their code and the time the app was live in production. So the idea was to cut down any and all of the effort that it takes for a developer to create an immutable artifact of what they’ve written and then attach a lot of
logging and monitoring and all of these other peripheral things and then putting that on infrastructure where it gets deployed and then attach load balancers and what have you and make you know ingress and egress available to the application. So, when you talk about this whole life cycle there is seems to be you know equal amounts of here is what effort it took to develop an application and here is what effort it took.
to make that application available live. So the Cloud Foundry experience has always been about reducing the whole here’s what it takes to get it live into a small set of commands, one, if you can. So that’s the history behind and the vision behind the cf push command and what that iconic
experience represents for developers. Now was Cloud Foundry the first one to do it? Probably not. I do recall doing like a Heroku push, which had a similar experience and a lot of developers probably around 40 years of age know that Heroku push experience and that really defined a first class, way to put applications.
on production and Cloud Foundry enabled that Heroku like experience on any infrastructure. So that was really key also for Cloud Foundry. So make it simple for developers to put applications into production and enable that kind of experience on any infrastructure. it was taking that Heroku experience that people love and amplifying the magic of that experience by,
allowing people to choose infrastructure and choose services and choose different applications in different languages and runtimes and frameworks and make that homogeneous magical experience available across all of these platforms. So lot of new platforms, appeared in the developers radar since the first launch of Cloud Foundry. as a community, the Cloud Foundry community has
pulled in you know all of the resources in order to adapt Cloud Foundry to all of these platforms. Now, the Docker wave sort of hit the world about 5 years into Cloud Foundry becoming mainstream and there was the Kubernetes wave you know few years later and both of these technology tsunamis in a way have sort of been.
worked into the Cloud Foundry experience as opposed to saying, hey, Docker versus Cloud Foundry or Kubernetes versus Cloud Foundry. So interoperability has been like a big thing and a big theme for the community. And they’ve really made it work across these two waves.
Rachel Stephens (06:11)
I want to circle back to what you were saying though when you were talking about making Cloud Foundry made things more open than Heroku was so you could bring things to more infrastructure. I think the other thing that’s interesting though is that Cloud Foundry is a very opinionated platform in a lot of ways. so I think one of the things is a very powerful developer experience if you can kind of live within the confines of what those opinions are.
Ram Iyengar (06:30)
Mm-hmm.
Correct.
Rachel Stephens (06:40)
But when Kubernetes came onto the scene, it was kind of the orchestrator for container centric workloads. One of the things that came along is that it was a very open platform and very extensible and came with a lot of choice for a lot of people to try to navigate. And with that came a lot of good and a lot of difficulty for a lot of people to try to navigate. It’s like we could, a ton of flexibility, but a lot of difficulty navigating how to.
Ram Iyengar (07:00)
That’s right.
Rachel Stephens (07:06)
navigate that flexibility. And so could you kind of talk about how, like you talked about not an either or an or choice for either of them, but like how Cloud Foundry and like these containerized ecosystems have kind of existed alongside each other.
Ram Iyengar (07:20)
Yes, it’s very interesting you asked that because in a way for a lot of people who would have adopted Cloud Foundry between say 2017 and now they were largely distracted by, know, what Docker and what Kubernetes had to offer. And so there’s a lot of people who’ve used Cloud Foundry and
Once you use it and once you get a taste of that kind of developer experience, it’s hard to really draw away or go away from it. There’s so many people I’ve met at KubeCon that just come up to us and say, hey, I’ve used Cloud Foundry in the past. I wish there was something like Cloud Foundry on Kubernetes and things like that. But in spite of a lot of its technical achievements,
One of the downsides of Cloud Foundry was how open and how not open it was at the same time. That’s been the most interesting discovery about Cloud Foundry I’ve had in my many years of being part of the community is Cloud Foundry was always an open source project since 2015. That was when the foundation was formed and all of the code was, you
put into the foundation, very typical open source life cycle. However, in order to contribute to the Cloud Foundry open source project, you had to go through a dojo of sorts. So you had to essentially spend time in person with the team. And after a certain quote unquote onboarding process is when you would be accepted as a contributor, as a maintainer, et cetera.
The opinionated part for me is the easier one to swallow. was these other practices around Cloud Foundry that I really had a tough time adjusting to. And then the other sort of minor problem with Cloud Foundry was also you could never try Cloud Foundry on a laptop, for example. And that’s how a lot of developer projects
I’m digressing a little bit, I think this part is essential to the larger story. the inability for developers to kick the tires around with Cloud Foundry is again, in my opinion, a massive place where Cloud Foundry really couldn’t get the kind of mass adoption and the developer driven adoption that some of the other technologies like Docker and Kubernetes have enjoyed. It was very
top down driven. you get told by management that, know, this is this thing called Cloud Foundry. Try it out. It’s amazing. And when developers tried it out, was amazing. And so the path to discovering Cloud Foundry was not a developer driven one. It was not something where people could try something locally and then replicate that experience on production and things like that. It was not easy to contribute to
this open source project. And finally, the opinionated stuff, you know, was, was like the last bastion of, of what in my opinion made Cloud Foundry a little difficult to work with as an open source project. Subsequent changes with Docker and Kubernetes was that the community as a whole realized that it’s not going to be easy for
in a Cloud Foundry as a technology to sustain without interoperating with these newer technologies that are more developer driven and that find a lot of favor with developers. And so the community, really didn’t have much of a choice, but also saw a lot of sense in adopting these technologies side by side. So history, is recorded that.
Cloud Foundry had an orchestrator before Kubernetes came along and Cloud Foundry had a way to containerize applications before Docker came along. But the containerization inside Cloud Foundry obviously didn’t enjoy the popularity that Docker did. The orchestration that Kubernetes is driving at so many different places isn’t the kind of adoption that
you know, Cloud Foundry was able to enjoy largely because these other technology ecosystems were more open, more available to developers. But now with the newer projects, the community has really taken efforts to change those. And thanks to Docker, thanks to Kubernetes, it’s a more open, more nimble and a less opinionated ecosystem than before. So,
For example, if you want to use Fluentd and Istio as opposed to the default Loggregator and Envoy and Contour based ingress that Cloud Foundry on Kubernetes ships with, you’re welcome to do that. Whereas years ago, you wouldn’t be able to do it. If you wanted to install Cloud Foundry on a laptop, I mean, my laptop right now is running
Cloud Foundry on kind clusters locally and so K3s clusters work with Cloud Foundry now and kind clusters work with Cloud Foundry now and like one node, two node clusters can also run on Cloud Foundry which was impossible before. So there’s been some good changes thanks to these technologies coming along and pushing things along and changing things a bit.
Rachel Stephens (12:41)
I love it. Alright, so I think we finally made it. Introduce us to Korifi. What is the Korifi Project?
Ram Iyengar (12:47)
So, the version of Cloud Foundry that runs on Kubernetes is named Cloud Foundry Korifi. So, it is a name we picked that means a peak or a scale scaling a peak in Greek. So, we sort of went with the Greek theme and we wanted to convey some sense of peak achievement or a zenith of sorts because Korifi was not the first attempt to put
Cloud Foundry and Kubernetes together. the community has had a few iterations where a lot of learning happened, but also a lot of ways that were to go the Edison way. We discovered many ways of how not to put a platform on Kubernetes sort of thing.
it took us a few tries, but right now what we have is a version that I think, the community is very proud of.
Rachel Stephens (13:36)
Well, I love that. I love that you experimented with ways that you learned lessons, you learned ways that it did not work, you learned ways that the community needed to iterate and evolve. But I also think you learned continued lessons about why and how the community needed abstractions over
Kubernetes, like where were the pain points and where are people actually needing assistance there? Because I think that’s just as important as where it didn’t work is where are those pain points in the Kubernetes ecosystem as well.
Ram Iyengar (13:54)
Absolutely. Yeah, if you think about it and the first KubeCon I attended was in Detroit in 2022. Nobody was speaking about platforms. Nobody was speaking about Kubernetes being a complex project overall. Nobody was having conversations about Kubernetes can do with a little bit of an opinionated path, if you know what I mean. And nobody was bringing up
The fact that too much openness is probably not the right recipe for systems in production. You want a little more control and clarity about what is the path you want your developers and operators to take. So none of those conversations were happening. And it was very difficult for us to be present, stand there physically in a booth and tell these people that, hey, you know what?
you probably need some kind of guardrails as you get into choosing the projects inside your Kubernetes deployment. And it’s become much easier now, not just because I’ve spent more time with the technology, but the conversations on the KubeCon floor itself, the conversations, the presentations on the keynote. I remember coming back to the Amsterdam edition of KubeCon and then
The keynote by Aparna, one of the co-chairs then, had this sort of Yelp review of Kubernetes in their organization and they said, stability five stars and developer experience three stars and then complexity one star. And so she admitted publicly for what I think is the first time that Kubernetes complexity could do with a little bit of simplification and some opinionated paths.
might be good for a lot more people to adopt Kubernetes and make sure that Kubernetes functions as the infrastructure abstraction it’s supposed to be as opposed to being, you know, a fancy project that all the developers somehow want to learn. And now I think, we’ve, come a long way in terms of what that actually means for the Kubernetes community as a whole. I think I can count about
20 projects off the top of my head that are tackling this job of too many CNCF projects and which ones to choose from. And I think the whole community is more receptive to something like Cloud Foundry right now, as opposed to two, three years ago even. And yeah, it’s a very interesting time for the project overall.
Rachel Stephens (16:29)
Absolutely. circling specifically around Korifi and where you’re at in terms of features and roadmap ideas and how you’re trying to tackle this space. Just give people a general idea of what are you doing to help with the simplification.
Ram Iyengar (16:42)
Sure, The aim of Cloud Foundry has always been to provide a first class multi-tenant self-service experience for cloud based infrastructure. Now this could be VMs of the past or it could be Kubernetes of today or some future abstraction of tomorrow.
In that path what we’ve discovered is not a lot of people are going to be doing green field development on Cloud Foundry. so Cloud Foundry is now so Korifi is now in this position where you can either manage the life cycle of new applications using Korifi or you could
take existing containers and images and deploy them to Kubernetes using the same Korifi experiences.
We also realize that people are not going to just deploy static applications. They’re going to have applications that connect to a multitude of services. And so we have support for also deploying services using Cloud Foundry. So you can create and manage individual instances of various services through the Cloud Foundry interface. And so it will give you
the ability to work with databases, with message queues, with observability tools, and all of those, for example. And so it’s providing all of these tools and applications and everything that an application lifecycle might need through a simple set of commands it has always been the goal of Cloud Foundry, and it continues to achieve that for the Kubernetes ecosystem today.
What we’ve been able to accomplish in the past year or so is integrate with Kubernetes based authentication, work with any sort of CNCF tool that you want to use alongside Korifi. It has the capability to function and integrate these Docker based or existing container workflows for a lot of people who don’t want like.
do want to always begin fresh. What we want to do in future is work with the services in a complete sort of manner. So, right now it is about I would say 50 or 75 percent there. There is some work that needs to go into completing services life cycles and I think the next big push will be to be able to do multi cluster management from.
single instances of Korifi or whatever, worker nodes and all of those through Korifi. So we’re not clear about how multi cluster management is going to work. So right now, all of this is available for individual clusters alone. So that’s what the future is for Korifi to nail down services to work with multi cluster management and. really try and become the choice of enterprise adopters for Kubernetes and smaller deployments alike if that’s possible.
Rachel Stephens (19:33)
Thank you so much for taking the time to chat with us today, Ram. This has been a wonderful update on the project. And if people are interested in either hearing more about what you are up to or more about the Korifi Project itself, where should they go?
Ram Iyengar (19:46)
So the Cloud Foundry community is quite active on Slack. So there’s a Slack that will be available on cloudfoundry.org, which is the home for Korifi and a lot of other Cloud Foundry projects. So Slack is the best way to get in touch with the contributors and maintainers. I’m available and quite active on that Slack as well. So I’m happy to direct people to the…
right channels and right folks if they have very specific or pertinent questions. The GitHub repos are actively maintained. there’s a GitHub org for Cloud Foundry and you can find Korifi as one of the projects and repos there. There’s an active issues list. There’s an active discussions list. Feel free to go through those and drop in comments and questions and…
Try the project really, it’s very simple to install on a local machine. The community very conveniently created kind Kubernetes, kind based installations for people to try these. And any issues that you find, any enhancements that you want to see, please report them and
very happy for all the feedback that we can get. The project is starting to become very vibrant in terms of all of the different contributors that we’re getting and the different orgs and different geographies that people are coming and participating in the conversation. And this was typically a VMware and SAP heavy given our pedigree, but it’s kind of changing. And I like the diversity among contributors now. than I did a year or so ago. So I’m very happy to see that kind of growth.
Rachel Stephens (21:19)
That’s great. That’s great. Well, I love this. Well, thank you so much for your time. And we appreciate all that you have been willing to share with us. This has been a wonderful conversation. If you enjoyed this conversation, like and subscribe and get more of our conversations on your podcast platform of choice. Thank you.
No Comments