Java containers are better viewed as the forerunners to general-purpose PaaSes. They load and health-check the app, route traffic, capture logs, inject services and the like.
Containers are a great building block for PaaSes. Red Hat have built their latest OpenShift on Kubernetes, for example. My own employers, Pivotal, are the majority contributor to Cloud Foundry, another containerising PaaS using a different container system.
Even in Java, folk are moving towards apps that bundle their own container. Spring Boot does with Tomcat by default. It turns out that the giant Java app servers were great, but eventually wound up with the same problem as previous generations of highly shared services: without strong isolation guarantees, it becomes necessary to heavily gateway production to prevent outages or degradations. That backpressure creates de facto waterfall.
> It turns out that the giant Java app servers were great, but eventually wound up with the same problem as previous generations of highly shared services: without strong isolation guarantees, it becomes necessary to heavily gateway production to prevent outages or degradations.
Are you talking about app isolation on an app server? I.e. running multiple WARs/EARs on a single server and not having one app destabilize the whole thing?
Containers are a great building block for PaaSes. Red Hat have built their latest OpenShift on Kubernetes, for example. My own employers, Pivotal, are the majority contributor to Cloud Foundry, another containerising PaaS using a different container system.
Even in Java, folk are moving towards apps that bundle their own container. Spring Boot does with Tomcat by default. It turns out that the giant Java app servers were great, but eventually wound up with the same problem as previous generations of highly shared services: without strong isolation guarantees, it becomes necessary to heavily gateway production to prevent outages or degradations. That backpressure creates de facto waterfall.