Over a million developers have joined DZone.

Warning: Are You Building Your Own PaaS with Docker?

DZone's Guide to

Warning: Are You Building Your Own PaaS with Docker?

Docker is awesome, no question. But it's so powerful that you might be tempted to containerize too much -- to build your own PaaS from a bunch of containers...

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Containerization is awesome... it's revolutionary. But there are all these other components that you need in order to make it work. As a developer, you don't want to care about which VM or network... or any of those little details. And if you're on a development team in an enterprise pushing out software, you really shouldn't have to worry about them. What you should worry about is getting your application out the door--making sure that it scales, making sure that it's available, and making sure that it's secure, Those are the things that you should be focussed on.

I discussed these issues and more in my talk at ContainerCamp 2015. Below is an excerpt of the transcript and full video of my session.

While you want to make containers work for your organization, there are some issues over and above containers that you need to understand:


Back in the old days (like decades ago) logging was easy. On a Linux box, you have an application that sends out logs and you get to use all these cool tools like grep, awk, and Perl to go through your logs and generate all that stuff. That was back in the really old days.

Then suddenly it got a little bit more difficult when we had client/server...that means we've got logs here and there all over the network across a variety of systems. We have to capture and collect all the details and make sure they're all ready, make sure that there's an agent everywhere, make sure the agents don't crash, and make sure the disks don't get full.

And it only gets more complex as we move into the cloud. Now I've got these ephemeral services that are starting and stopping all over my network (who knows where they are) I have to make sure that the logs for these are captured. And then we have to deal with things like correlation between logs, logs to the database, how do they correlate with something that happens at the front and that happens in the middle tier? Or even more interestingly, across the hundreds of microservices that comprise my whole application. While logging is getting more difficult, a developer really shouldn't spend any time dealing with the intricacies of logging. In my career, I know that I've spent way too much time writing logging systems and make sure they keep running. But that's not what I'm supposed to be doing or what I'm being paid to do. I'm supposed to be shipping software, not fiddling with logs.


The scaling up of applications is very important. The typical pattern, what happens almost all the time, is a startup has this cool idea for an app. They start building it, prototyping it, and then begin getting investment. Then about three months before shipping someone says, "You know what? We really should make sure this thing scales." And then they start do some scale testing, and when things start breaking they have to go back to the drawing board. It's not the right approach. You should be scaling your application (and by that I also mean a service or microservice) from the very first second you write a line of code. In other words, if you start off your app, as you maybe should with a 'hello world' application, 10 seconds after that is deployed, you should scale that up to several thousand users. Do that from the very first start of everything. Most people don't do this today because they have all these cool ideas they want to implement, but the better approach is to start scaling it from day one and then as you are evolving your application, you have scale testing going on all the time through the whole delivery pipeline to make sure that in every moment it can support all the users it will ever need to support.

Instant Rollback and Versioning

Instant rollback and versioning is particularly relevant for microservices because you want to have this functionality for your services. With microservices it's very common to have multiple versions of your services running at one time, or if not that, then have the ability to roll back and forth these versions as things change and you discover issues. I mean you've got Docker (which is awesome), we got these containers in everything, but still to actually manage their versioning and rolling back, zero downtime rollbacks and roll forwards, things like that takes a lot of effort, a lot of time, a lot of knowledge and expertise.

On Demand / Self-Service

On demand, self-service, is one of the important promises of cloud computing. Ideally the developer should be able to get access to all the resources that are needed without having to submit a service desk ticket. It continually amazes me: when I first started working on this, I was discovering these companies that would tell me that it takes a month to get a VM provisioning or two months. I thought that was crazy (I was used to two weeks), and I recently came across the company in the financial industry where they say it takes six months to get a VM provisioned. 120 tickets have to be processed by their IT department before they can get a VM up...which still baffles me. And that's obviously the wrong approach, so you want to enable on-demand self-service as much as you possibly can. Again Docker is great for all these things, but you want to get another layer on top of that to enable all of that.


Another one that's important is monitoring. The recent webinar with David Farley (who wrote The Book on continuous delivery)...says that the whole concept of continuous delivery is based on the scientific method—in order to be meaningful, it has to be measured. And it's the same with software. If you can measure it, you can go a long way towards making all these other things you are concerned about reliable and scalable. But wiring up monitoring to your applications takes a fair amount of work, making sure it's reliable and accurate. Oftentimes we're in the weeds...we're dealing with the plumbing, we're working with all these things that are not directly applicable to building software, which is what they're paying me to do and what really "this company that makes toothpaste" is supposed to be doing. Not spending all their time in the weeds.

And there are a lot of weeds:

  • elastic scaling
  • resource scaling
  • integration with the infrastructure
  • multi-node cluster configuration and management
  • high-availability
  • security issues like single sign-on
  • multi-tenancy and isolation
  • monitoring
  • logging
  • routing
  • load balancing
  • service provisioning and auto-wiring
  • service discovery
  • instant rollback and versioning
  • service naming and URL mapping
  • polyglot language support
  • authentication service integration
  • consistency
  • orchestration

You can build this all yourself using Docker containers, but why? Why would you build it when you can use a PaaS? Don't get me wrong, we're big fans of Docker. We have seen a lot of very powerful benefits from using Docker and containerization. We've been using Docker in Stackato since 2013 and have the distinction of being the first commercial product (besides dotCloud of course) to ship with Docker. More recently, with the release of Stackato 3.6, we allow users to deploy their own Docker images directly to Stackato.

Containers are powerful, but you have to work on the giant list of weeds mentioned above. This means you are effectively building your own PaaS and taking time away from focussing on your own business.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.

docker ,paas ,versioning ,cloud ,cloud platforms

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}