I've been seeing a lot of systems built using containers recently, and they have been an effective way to build and deploy applications in the cloud. For the most part, the hype has lived up to reality.
What I like about containers is that they are based on known patterns. We've been building distributed systems using containers for years, and the newfangled containers like Docker are a progression of that technology. Plus, there are clear advantages to the new generation of container standards.
However, most IT organizations building cloud applications that use containers have not bothered to understand the proper architecture and design of container-enabled applications. Thus, containers are often not used correctly.
It's not the container technology that has failed the developers. Rather, the developers have failed the container technology.
Containers provide powerful reusable components that let you speed up distributed system design and development. The ability to build applications from encapsulated containers in the cloud is the pinnacle of distributed systems design and development. It's a technology and design pattern that's built on the best of past technologies.
The power of containers is the ability to take a distributed approach to application development. For example, you can leverage the database decoupling that containers offer, allowing the applications to scale -- without having to allocate more machines.
If you're designing and developing applications, you need to understand that containers virtualize the processor and the kernel. Thus, they let applications use the same underlying kernel with a level of introspection (and abstraction) in a closed container. In other words, you're dealing with distributed application components that can also be applications unto themselves. However, that flexibility gets you in trouble.
To get the advantages of containers, you have to make an effort to understand them in terms of proper design, and proper development. Merely using containers is not enough.