Docker Containers, Cloud Foundry, and Diego—Why Abstraction Matters
Containers are surrounded by a lot of myths. For instance, contrary to the common belief, they are not new, Docker didn’t invent them, and they have actually been used in production since the 90s. In this talk, Renat Khasanshyn busts the most popular container myths, explains why containers are not perfect, and lists some things that could be improved.
Cloud Foundry/Diego and containers provide different levels of abstraction. Renat Khasanshyn explains what is on each level and how Cloud Foundry and Diego use containerization technologies, such as Docker, Warden, etc.
It’s all about abstraction
This 30-minute talk from the East Bay Cloud Foundry and Docker meetup busts some popular myths about containers and explains the difference between Docker, Diego, and the Cloud Foundry PaaS. Renat Khasanshyn, CEO of Altoros, also speaks about likely scenarios of Docker evolution in clustered systems.
While the purpose is clearly to draw the line between these three technologies, the main message is that “abstraction is the key to what’s happening all over the place.” According to Renat Khasanshyn, everything is being abstracted away. In the future, things such as data services, middleware, OS, virtualization, etc. will be provided automatically. Ultimately, the only thing you will have to worry about will be the actual app.
Containers vs. PaaS
The session starts with a brief introduction to levels of orchestration and the place of PaaS and containers in this hierarchy.
It continues with some “surprising” facts about containers. For example, contrary to the common belief, containers are not new. “Docker hasn’t invented containers,” either. They have been around at least since the 90s and early 2000s. And they are actually widely used in production, mostly by web hosting companies.
“The multi-tenancy and isolation that containers offer was the key to early adoption…Years of hard labour and lobbying have been put into making containers something that is part of and is supported by the Linux Kernel.” —Renat Khasanshyn, Altoros
As to the question of why containers suddenly became so hot, it is mostly thanks to Docker and LXC. LXC have been around for a while, but Docker finally made them “easy for app developers.” “Easy” equals “adoption.” As a result, the number of individuals and organizations using Docker and other containerization tools has gone through the roof. Today it’s not only web hosters who need containers, there are a lot of others who use them in production, e.g. Google.
“We see middleware being often replaced by container-based systems…Now teams are much smaller, much more contained, and they still produce valuable results.” —Renat Khasanshyn
Containers vs. Cloud Foundry and Diego
“If you noticed, the application, the developer, and the containers are coming together around Platform-as-a-Service,” according to Renat. A PaaS—e.g., Cloud Foundry—uses containers to isolate resources, but it also adds app management features, such as automatic health monitoring and recovery, a possibility to manage apps and services via an API, scheduling, etc. There are several projects in the Cloud Foundry community that feature Docker—e.g., Decker, Cloud Rocker (Focker), and Docker Circus.
Diego, the re-write of the Cloud Foundry runtime, which may in fact get its own release path in the future, takes Docker support even further. It actually provides native Docker integration, using the libcontainer library.
According to Renat Khasanshyn, the future of containers and PaaS looks very bright. Developers and managers alike want abstraction, which boosts productivity, helps to economize, and generally makes life easier. “Docker, Diego, and PaaS are all about abstraction,” so we already see a rapid growth in the number of companies and individuals who use Cloud Foundry, Docker, and similar tech. And there are reasons to believe that these technologies may become mainstream in the coming years.
Want details? Watch the video!
Table of contents
|
About the speaker
Related blog posts
