Software component packaging is Day-1 concern for containers, however day-2 optimization of which container, how big the container, how many transactions the container will service in a scalable fashion, what other containers are related to the current container, and their dynamic movement for better scalability and availability is the key aspect of taking a niche technology to the next level. These are all concerns of the next wave of commercialized products, no doubt developers want to quickly package something and deploy it to production, however, fundamentals of distributed computing and scalability don’t magically disappear. The current container packaging wave is yet another developer behavior of trying to encapsulate the various software components, libraries and process details. Packaging and containerization is great concept, after all containment concept is a natural progression of trying to abstract implementation detail, for example, we saw a similar progression with the concept of encapsulating many threads into a process, encapsulating may files into tar, many source codes into jars/wars etc. The current wave of containerization is about encapsulating the software components and associated processes to the context of the application being deployed, as one deployment unit without the repeated overhead of an entire operating system. The next wave will be about day-2 operations, and how to write DRS (VMware vCenter Distributed Resource Scheduler) like functionality for containers delivering the correct scale and meeting the response time SLA of an app, at the most cost efficient utilization of hardware. In almost every corner of container discussions, microservices architecture is part and parcel of the discussion, and the service unit of a microservice is being positioned as the containerized deployment unit, this would lead to fragmented scale-out of the distributed platform that would negatively impact response times, I wrote a little about this here, a better answer would be to more appropriately containerize based on relationships between service usage as suggested in my earlier blog. This type of containerization can be encoded into how the container is formed on day-1 if the developer intimately knows how the microservices graph is used, or the app is used, and perhaps it can be calculated by the runtime at incubation time, pilot/trial time, or even prod time. Let’s say you deploy a deeply fragmented fashion microservices as touted by many early entrants, the underlying application/container/platform runtime engine can determine and give you recommendations of how to better deploy…more on this later.