DockerCon 17 EU – Through the eyes of a VMware guy



I had the opportunity to attend the European DockerCon event with some of the guys from the Tech Field Day events. Docker and in particular containers is not something I have really looked at. I know what the concept of containers are and I have an idea of what Docker can do for containers, but that’s it. To give you my thoughts on what a container is, at a high level it is a way of abstracting an application or delivering a microservice in a self-contained bubble running on top of a common operating system. The container shares the common underlying kernel of the operating system but the container its self should not be able to break out of its bubble and interact directly with other containers. Docker is a platform on which containers can be packaged, secured and delivered amongst other things. Take a look at the What is Docker page for more info.

Eyes Wide Open

To say I was out of my comfort zone would be incorrect but I was in unfamiliar territory. I went into this event with the idea that a container is like a virtual machine but for applications. I quickly stopped believing that message and saw a great statement that summarises the container and virtual machine differences. “Docker is not a virtualisation technology, it’s an application delivery technology” by @MikeGColeman. I think this is an important thing to remember to stop yourself trying to draw comparisons to VMware or any other hypervisor technology.

Eyes wide open, I am looking for the problem that Docker is trying to fix. More specifically, MY problem that Docker could fix. This is not the way to traditionally approach a product, but I like to immerse myself in a technology to understand its benefits and where it may fit. I did not have a problem that needed to be solved with Docker in all honesty which is why I was finding it difficult to find that use case. One thing did jump out though and that’s the Docker Modernise Traditional Applications initiative. The concept of application abstraction is not new, but the way Docker approaches this problem is. I mentioned in the background that Docker is a platform that packages containers but also delivers them and adds security. Imagine being able to manage legacy application delivery from one location and do it in a secure fashion, that sounds pretty good. One example I saw to enhance a traditional application running out of a container was to be able to bolt on a microservice function to allow enhanced search capabilities and a method of delivering results back to a mobile user interface that would have previously not been supported. All without altering the original application.

The above is just one example of how Docker could be used and just the opening to the rabbit hole. Do I need to see how deep the rabbit hole goes? I don’t know at this point. If there is demand for this kind of service from the clients I deal with, sure why not.


The demographic at this event was different to what I am used to. Other events I attend tend to either be the hardcore infrastructure folk or someone who likely has the title of CTO. This event was just a different crowd. Maybe it’s the dev guys or the DevOps guys but it was certainly different. The pace at which products are born and come to fruition seems to be a lot quicker. A great example was the OpenFaaS project from @AlexEllisUK. The premise is that of running functions out of containers. Within 6 months of concption this product has won awards and gained a lot of traction.

The other side of it is my fanboyism of at least one product at a trade show did not apply here. It was funny watching other people getting caught up in the moment, being the respected peers in their field. The Docker Captains seemed to be well represented.

I won’t pretend to understand the excitement around the announcement of Docker integrating with Kubernetes, however, it seems to be an indication that the industry is moving to a standard orchestration platform. Docker Swarm is Dockers owns orchestration platform. From talking with some folk, the announcement means that duplication of work to allow a container to be deployed with Docker and with Kubernetes no longer needs to happen as doing is in Docker now also automatically does the same thing in Kubernetes.

The Takeaway

To not install Docker and perhaps convert an application to a container I think would be a silly idea for me. Even if its to have some ammunition to be able to hold a conversation with someone to explain the differences between virtualisation and containers and where each one can fit.

Public cloud is something I have not even touched upon here as it’s another can of worms. Just know that with a container, as it’s in its own bubble, it should be able to run anywhere with the same validated platform, Docker, in this case, running beneath it.

Further Learning

There were some good websites to take a look at that I picked up throughout the sessions, see below:

The Boring Bit

It would be fair to say that my DockerCon entrance fee, flights and hotel for this trip were covered by the good folks at Tech Field Day through the work they do with vendors such as Docker. However, this blog post is my own thoughts and in no way influenced by that. I am not obliged to write this drivel 🙂


You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.