anynines is focused on planning, building, and operating modern application developer platforms and has years of experience automating the delivery of enterprise-grade PaaS (Platform as a Service). But change is always inevitable and anynines is currently transforming in the face of major change with Cloud Foundry.
Julian Fischer, CEO and founder at anynines, points out that one of the problems with Cloud Foundry is that “Not every organization that is keen to transform digitally has the power, the money, the patience, and maybe the skills to bootstrap their own Cloud Foundry environments.” Because of this, Fischer says, “consultancies such as an EngineerBetter, Stark & Wayne and anynines have entered the stage (as well as large corporates such as IBM, and SAP and Pivotal) have entered the stage to become vivid partners of the Cloud Foundry ecosystem.”
Over the years, the container movement has gained tremendous momentum, which has led to the question, “How does container orchestration work?” With regards to this, Fischer says, “The container image has seemed to have conquered a lot of markets in the sense that it has not been a top-down, but bottom-up revolution.” This movement was bottom-up, so some developers could easily install Docker and instantly play around with the environment. And then came Kubernetes, which lifted the idea from a local container to distributed systems and spending across multiple services.
Once a large audience had bought into containers, it disrupted Docker and its community. With this shift in container orchestration being so dominated by Kubernetes, what happens to the Cloud Foundry Foundation? It means the Cloud Foundry Foundation will have to change by cutting costs. To that, Fischer says, “With Kubernetes being the dominant technology for container orchestration, the only direction that makes sense is to think what are overlapping parts and responsibilities in Cloud Foundry and Kubernetes.” Fischer then offers an example using container scheduling. “The idea that somebody needs, for example, the Diego subsystem to do container scheduling is highly doubtful and therefore Cloud Foundry for Kubernetes has been proposed.”
Because of this, Fischer believes that Cloud Foundry for Kubernetes will be the future of Cloud Foundry. By putting Kubernetes in place for some use-cases and tasks, it would allow for a more lightweight Cloud Foundry and cut down on maintenance costs.
But should Cloud Foundry users be concerned? Fischer doesn’t believe panic is necessary. He says, “The customers who have adapted to Cloud Foundry over the years, they have a certain weight and these organizations, they won’t just let technologies such as Cloud Foundry go away.” One of the primary reasons, however, that Cloud Foundry users shouldn’t panic is that no other technology has managed to achieve a similar economy of scale. There is no migration path from a large Cloud Foundry environment to Kubernetes. Fischer believes those classic Cloud Foundry environments will continue to be maintained. He says Aanynines will maintain Cloud Foundry. They’ll operate those environments and help to keep them secure for a prolonged amount of time.
As to the role Cloud Foundry will play in the Kubernetes space, Fischer says, it’s a convenience product. Fischer offers up the example, “You, as a Cloud Foundry user, don’t want to think about stateful sets or operators on how to do database automation. You want to deploy an application that’s perfect or compliant and connect it to a database that comes from some service broker that manages that for you. And I think that is the interface to the Cloud Foundry users that will remain relevant for Cloud Foundry.”
At the same time, Cloud Foundry will have to adapt to become more Kubernetes idiomatic. In fact, according to recent design drafts, Fischer makes it clear that Cloud Foundry is not only replacing Diego with Kubernetes, it’s changing the inner API to translate the responsibilities of subsystems into more Kubernetes-native structures. Fischer finishes by saying, “It’s about the user experience and will remain to be about the user experience in the future as well.”
The summary of the show is written by Jack Wallen
Here is the rough, unedited transcript of the show…
Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya. And welcome to TFiR Let’s Talk. Today we have with us, once again, Julian Fischer, CEO, and founder at anynines. Cloud Foundry foundation is going through its own transformation. Chip Childers has left the foundation to explore other opportunities, as the Cloud Foundry community and the project is reforming itself within the Linux foundation. I will talk to you surely on that. How do you look at these changes? Did you see them coming? What des Chips’s departure mean for not only the project, but also the whole community? So give me a good summary of how do you see these changes?
Julian Fischer: A Cloud Foundry set up always has been relatively heavyweight. So you had to offer and throw a lot of infrastructure resources to get a Cloud Foundry up and running because the idea was to have a central platform technology within a large corporate, for example, so that central IT could utilize that platform. And the idea to centralize the platform with a single or a few Cloud Foundry environments has tremendous economy of scale effects that I believe, up to this day are very unique to Cloud Foundry. And the Kubernetes ecosystem has to evolve and come up with certain solutions before they can live up to the standards Cloud Foundry has said to this point. However, not every organization that is keen to transform digitally has the power, the money, the patience, and maybe the skills to bootstrap their own Cloud Foundry environments and thus, well, consultancies such as a EngineerBetter, Stark & Wayne and anynines have entered the stage as well as large corporates such as IBM and SAP and Pivotal and all their likes have become vivid partners of the Cloud Foundry ecosystem.
Now over years that when the container movement has gained such momentum, the question evolved, how does container orchestration work? And if the CF push experience in comparison to the creation of container images, the container image has seemed to have conquered a lot of market in the sense that it has not been a top down, but bottom up revolution. So where Cloud Foundry has been pushed into large organizations successfully, and these environments, they still exist and they will run for many years to come. The container movement was bottom up. There were developers who could easily download Docker, play around and have their rewards. And then Kubernetes came along and Kubernetes, they lifted that idea from having a local container, into deploying distributed systems, spending across multiple service.
We are far away from the [inaudible 00:03:17] environments reach, but it appeared to the large audience that already bought into containerization so well that it actually even disrupted Docker and the company behind Docker. So in my belief, that is the underlying phenomenon the Cloud Foundry community responds to, is the shift in the container orchestration is being dominated by Kubernetes. Now that being said, the question is what happens to the Cloud Foundry foundation? Now, I think the phase where large corporates such as Pivotal and SAP and IBM invest huge amounts of money into Cloud Foundry over because Cloud Foundry has stabilized to one extend to other extends that they also invest into other areas nowadays, which means that with these changes, the Cloud Foundry foundation is slightly to undergo changes itself by having to cut costs to some degree.
Swapnil Bhartiya: What does it mean for the Cloud Foundry as a foundation? How do you see it [inaudible 00:04:40]?
Julian Fischer: Well, I think that with Kubernetes being the dominant technology for container orchestration, the only direction that makes sense is to think what are overlapping parts and responsibilities in Cloud Foundry and Kubernetes. So for example, container scheduling the idea that somebody needs, for example, the Diego subsystem to do container scheduling is highly doubtful and therefore Cloud Foundry for Kubernetes has been proposed.
And I think it was clear for a while that Cloud Foundry for Kubernetes will be the future for Cloud Foundry. In order to address, for example, the economy of scaling issue that I mentioned earlier, where Cloud Foundry needed to have a lot of infrastructure resources, in order to cut that down, Kubernetes can be used as this would allow for a more lightweight Cloud Foundry. More than that, it would also allow to cut down the maintenance costs on Cloud Foundry, because there is an open source technology called Kubernetes, that’s been built for building other platforms such as Cloud Foundry, and it’s therefore the ideal fit. So if, it is possible to adapt Kubernetes in a way that Cloud Foundry becomes lean in the sense that it can reduce the complexity. I think the Cloud Foundry Foundation will respond in a similar way. They will also reduce their complexity because the Cloud Foundry Foundation will shrink as the code base of Cloud Foundry will. And I think that’s perfectly fine to observe.
Swapnil Bhartiya: As you said that the Cloud Foundry will evolve, that Cloud Foundry will respond, but with Chip’s kind of departure, what does the Cloud Foundry community look like? Is there a leadership void there? What role players like any [inaudible 00:06:41] play there who have, you have a lot of users who have invested in a Cloud for the end, to be honest with you. I look at Cloud Foundry as any other technology. We used to talk about, Hey, Unix is gone, but we all know people still use Unix. People still use main frame. So these technologies will remain for a while, they will of course evolve. But if I ask, what is Cloud Foundry community now, what is the departure of Chip means? And what will the community look like?
Julian Fischer: Losing Chip Childers as the CEO is very sad because, he was such a great person and it’s a pleasure to work with him. I think that he and his predecessors, they have help the Cloud Foundry community to become stable enough to exist without a CEO. And I think that’s fair to say there is a board of people who will govern the Cloud Foundry Foundation instead. And I think that introduces democracy that is long overdue in Cloud Foundry, not because of the dominance of Cloud Foundry Foundation CEOs, but because of the dominance of certain sponsors of the Cloud Foundry foundation. It was very hard for smaller companies like us to contribute to Cloud Foundry at a certain stage, because there was a high barrier of entry to, for example, established developers. We at anynines, we believe that Cloud Foundry and companies who have invested in Cloud Foundry will be remain relevant for years to come. And therefore we will remain as active participants in the community and are also willing to take on more responsibilities in the Cloud Foundry community.
Swapnil Bhartiya: If we just look at Cloud Foundry, the existing users are people who have invested resources, or they have built infrastructure and the whole team’s around them. Should they worry? Should they panic? What is the message to them?
Julian Fischer: Well, I don’t think that panic is somehow necessary. The customers who have adapted to Cloud Foundry over the years, they have a certain weight and these organizations, they won’t just let technologies such as Cloud Foundry go away. I don’t think it is possible because where Cloud Foundry has been adopted successfully, there are thousands of applications and thousands of service instances running like the technology that Cloud Foundry provides. And as I said earlier, the economy of scale is yet to be reached by any other technology. Like there is no migration path into Kubernetes tooling that will allow a large organization, a large Cloud Foundry environment to be transformed into Kubernetes environment easily. And it won’t be able to achieve with anything that Cloud Foundry will deliver on top of Kubernetes in the very near future. So I believe we need to distinguish two discussions.
What happens to classic Cloud Foundry environments, especially if they have larger scales. Well, they will be continued to be maintained. We, as a company, for example, will maintain Cloud Foundry. We will operate them. We will help to keep them secure as good as we can for, for a prolonged amount of time. So there’s absolutely no reason to panic there. I’m also pretty sure that whoever has sponsored Cloud Foundry in the past, they will have the same problem and they can’t just go away and move on because there are so many applications and organizations relying on that technology. We are not talking about something that you can easily just abandoned. And I think it’s not meaningful to do that. And that gives room and time to let Cloud Foundry for Kubernetes and maybe even Kubernetes itself evolve a bit so that it becomes a viable alternative.
So just to give you an example, if you create large group [inaudible 00:10:51] environments, it’s very likely to have multiple Kubernetes clusters. We’ve mentioned that in earlier conversations, so that Federation of Kubernetes clusters and making sense of a Federation of Kubernetes clusters, that is essential point that needs to be solved before it becomes a viable alternative to Cloud Foundry. And while some commercial products try to do that, I’m still waiting for anything that lives up to the standards. For example, when it comes to operational ease, once you set up yourself in Cloud Foundry operating huge environments has been such a pleasure. And I’m still waiting for anything that can live up to these standards.
Swapnil Bhartiya: You have already touched upon this point, but I just want to hammer it a bit more is that, what role do you see Cloud Foundry is going to play in the Kubernetes space? Because there had been a lot of projects not to kind of build a bridge between that. So talk about that also.
Julian Fischer: Yeah. The role of Cloud Foundry, Cloud Foundry is a convenience product for Kubernetes. That’s my belief for the future of Cloud Foundry, is the CF push experience is together with the idea of having a marketplace so that you basically create, if you want to say that like a shared hosting for running distributed applications, you as a Cloud Foundry user, you don’t want to think about stateful sets or operators on how to do database automation. You want to deploy an application that’s perfect or compliant and connect it to a database that comes from some service broker that manages that for you. And I think that is the interface to the Cloud Foundry users that will remain relevant for Cloud Foundry.
However, at the same time, Cloud Foundry will have to adapt to become more Kubernetes idiomatic. So if you look into recent design drafts on where Cloud Foundry will go, you will see that it’s not only replacing, Diego with Kubernetes, it’s also about changing the inner APIs to translate the responsibilities of subsystems into more Kubernetes native structures, like CRDs custom resource definitions and controllers, so that you basically have more or less an adapter that will provide you the Cloud Foundry API. So what Cloud Foundry will become is one of the ways on how you can deploy applications to Kubernetes. And if you look at Knative or Kubernetes, Bayer Kubernetes, or Kubernetes with K pack, or you take a Cloud Foundry, you will have many different ways on how to deploy web applications to Kubernetes and it will be the choice of the predominant user experience that will make up the decision for Cloud Foundry. So I think that somehow describes it. It’s about the user experience that will remain to be about the user experience in the future as well.
Swapnil Bhartiya: Julian, thank you so much for taking time out today and talk about not only the transformation, the evolution of Cloud Foundry community, the product, and also kind of instilling some confidence within users that there is nothing to worry about. A lot of the technologies, they were created like decades ago, but they’re still around. Cloud Foundry is one of those technologies that has a lot of investment from big players, from users. So that will also remain critical for a lot of years to come and also talk about open source, how you are trying to balance between the commercial interests and the community [inaudible 00:14:52]. So thanks for those insights. And as usual, I would love to have you back on the show. Thank you.
Julian Fischer: You’re very welcome. And thanks again for having me here.