A Panel: Will Docker Eat Cloud Foundry’s Lunch?
There is a concern inside the community that Docker may evolve into a PaaS. In this video, the panelists discuss if Docker can actually replace Cloud Foundry.
Cloud Foundry was an early adopter of the container technology. From this video, you can learn what Docker and Cloud Foundry are up to together, and how Diego fits to the picture.
What’s the issue?
Released as open-source in 2013, Docker caught everyone’s attention. However, in December 2014, CoreOS introduced Rocket—a new container runtime. This announcement wreaked havoc, generating a concern that Docker may be challenged to evolve as a PaaS. Or, at least, it may incorporate some PaaS functionality and start competing with PaaS platforms, including Cloud Foundry.
Some members of the Cloud Foundry ecosystem are raising this question from time to time—despite the fact that Docker joined the CF Foundation recently. Those concerns were, probably, triggered by the Docker roadmap from December 2014.
If it looks like PaaS, moves like PaaS, and smells like PaaS, isn’t it a PaaS?
So, the panel at the CF Beat event (held in late December, 2015) tried to clear up the situation. The topic of the discussion was put as “Will Docker Eat Cloud Foundry’s Lunch?” The panelists included Ramiro Salas (Pivotal), Dr. Nic (Stark & Wayne), and John Wetherill (ActiveState).
The Cloud Foundry–Docker relations
One of the very first questions raised by Dave Nielsen—the moderator of the panel—was how containers intersect with Cloud Foundry today and how the panelists see the evolution of this.
Ramiro was the first to comment on the question. In his view, it’s up to the community to determine how the Cloud Foundry–Docker relations will evolve. At the same time, he thinks that all this thing with Docker eating Cloud Foundry’s lunch isn’t a valid question.
“I mean, it’s like is a carburetor market actually going to eat a car market? That’s the way I see these things.” —Ramiro Salas, Pivotal
He nailed it with a remark questioning who is actually going to eat Cloud Foundry’s lunch: the container technology or the Docker company itself?
“Can Docker as a company eat Cloud Foundry in the future? We are talking about anything, I mean, McDonald’s can come to this business someday and completely bankrupt all of us, right?” noted Ramiro.
How Diego fits to the picture
According to Ramiro, the Diego elastic runtime marks the next generation of Cloud Foundry. Initially created in Ruby as DEA, Diego was rewritten in Go. The choice of the language was explained by the complexity of the Ruby code itself. What Diego does is taking a lot of original Cloud Foundry components and distributing them. To Ramiro’s mind, that’s the way a PaaS should truly be in the 2015 time frame.
One of the main benefits that Diego will bring is the possibility to run Docker containers on Cloud Foundry.
John Wetherill (left) and Dr. Nick (center)When Ramiro spoke about the container technology itself, he said that containers had historically been a solution to address Cloud Foundry issues. Ramiro thinks that it doesn’t have to be Warden containers or any other specific technology.
“It can be literally anything that the community decides to plug in.” —Ramiro Salas, Pivotal
The bottom line
As a container orchestration technology, Docker does a great job, that’s why it was chosen to do the job. What is more, Docker is easy to use. With the contribution of the community, Docker is rapidly evolving.
Here’s the breaking point. At the end of the panel, a guy from the audience noted that the rival for Cloud Foundry is not Docker itself, but, probably, a potential set of PaaS systems that may come out of the Docker ecosystem—built on top of the technology’s engine. Taking into account the list of the main contributors to the Docker code, this remark seems to make sense.
Want details? Watch the video!
Table of Contents
|
Further reading
About the panelists
