Hacker News Reader

Comment by kirinan | Hacker News Reader

This will be what takes containers into the mainstream businesses. Companies may adopt docker or other instead of this, but Microsoft creating their own version of it means its a viable technology. Im more interested in the new frameworks and technologies that get adopted because of this than the fact that its in use. Traditional Java web projects that are hosted on Tomcat/JBoss don't run well inside containers but there are technologies like Node.js that lend themselves to containerization. Open source .NET is now a viable option for linux deployments, and Microsoft's new containers. It will be an interesting couple of years as this shakes out.

View on HN

Microsoft creating their own version means the technology is viable? I think people have been using 'the technology' for years, without any input from Microsoft. It doesn't need to be anointed by Microsoft to be 'viable'.

For the tech enthusiast and the visionaries, you are correct; It is a very viable technology. However the majority of people that deploy software are rather conservative and unless they see a market leader such as Microsoft with a solution they don't deem the technology safe to use. This is well documented in a lot of literature like Crossing the Chasm but can be observed frequently if you work at a larger non-tech oriented company. Whether or not this notion is actually correct is debatable but it doesn't change the validity of it.

This also means a lot of Microsoft shops who have a lot of Docker enthusiasts will be able to pitch this to thier bosses, who might not have been on board prior to this since it wasn't an enterprise MS product.

This will open a TON of doors for everybody.

I think that when a "market leader" finally adopts technologies that were in use for more than a decade by their competition, it's safe to assume the tech got mainstream...

> It doesn't need to be anointed by Microsoft to be 'viable'

Well, in a lot of corporations its viable when the big analyst companies say its viable (Gartner and Forrester Research) and they tend to be "nudged" by Microsoft. It once was does IBM have an offering in this space and then it became does Microsoft.

// one more soul crushing things done in corporate IT

BSD had jails for well over a decade before Linux containerization took off; Microsoft entering the space could very well be good for all participants. A rising tide, etc.

To be fair, there were things like usermode linux (UML) that were (roughly) contemporary to jail, circa late 2001 / early 2002.

Assume a generous reading of the comment, like, "It must be good if Microsoft is jumping on the bandwagon."

> Microsoft creating their own version means the technology is viable?

Keep in mind nearly all technologies are used mostly at non-tech companies (e.g. far more software is written by developers not working for a software company) and the software/IT teams at these companies usually prefer solutions from the large/major tech names they know/trust. Microsoft having their own version of something means a lot more businesses will consider using it.

It doesn't mean it wasn't viable before, it's just another piece of evidence, which many more people will be exposed to, that it is viable.

Microsoft creating their own version means it will be perceived as viable by many more people.

Could you please explain what kind of issues did you find running tomcat/jboss inside containers? We've been running several apps on docker and so far no problem. Thanks a lot in advance.

Essentially, Java is already run like containers, that container being an application server of some sort. Very rarely is Java software really dependent on specific packages being installed or even which operation system aside from a particular Java VM. When you add another container layer you generally are just adding more overhead and further you have issues with correctly setting some tunable parameters like heap sizes vs container memory sizes, etc. It works, it just isn't very ideal.

Thanks for your reply spullara. We might be one of those rare cases where we do need different packages and libraries for each applications. It's the pain that we have to suffer having to maintain several "legacy" apps.

Regarding your view on an app server being a container of some sort, I do agree. We are actually starting to develop apps to be run using embeded app servers (with Spring Boot), as it fits better when running apps using docker.

Makes sense. I've been recommending Dropwizard for years for similar reasons.

Tomcat/Jboss are resource hogs and tend to not do well in sandboxed environments as it takes away a lot of the configurability/tuning that they provide/need for scaling. In addition, people tend to deploy multiple applications per application server to keep resources requirements down: containizeration tends not to lend itself to multi-application stategies (in particular resource heavy applications like those that run on the JVM). This is far from something that makes java an impossibility but it changes the techniques enterprises are accustomed to. Technologies like Jetty provide a good solution to the problem, and will probably see wider adoption as containers become more prevalent.

Thanks a lot for your answer. We create a separate container for each application, as it seemed like the correct approach. In our company we do have several "levels" of library (even jvm) version requirements. Containers have been very helpful to easy the pain that was managing that on the server side.

I've found that building fat JARs with all dependencies bundled solves a lot of the same dependency management issues containers can be used for. And it does it without container overhead.

How do you apply security updates to the dependencies?

You generate a fresh build with the updated libraries.

Exactly. This also ties in nicely with a test-heavy build process to make sure that said security updates don't cause any regressions.

EDIT: To give you a chance to catch those regressions, at least.

To update on this since I am a Java programmer who is picking up c again after 10 years:

In modern Java world people often maven or another project tool where upgrading a library is as simple as changing the version number in a "pom" file, push and wait for Jenkins to finish build, unit and integration tests.

Not kidding here, this is one of the things I love about Java development.

This is literally every ecosystem except classical c and c++.

This is exactly what should be done.

That's what we do now: fat JARs, including all dependencies and use embedded app server. On top of that, we use docker containers so we can control de JVM version as well. The overhead is not that high and it gives us the benefit of knowing that the same container that the developer/jenkins tested is the one that passed QA and will run in production.

As someone that has deployed multiple production applications in Tomcat and Jetty, I would never choose Jetty again. The concept is good but it has severe quality issues and does not offer the same stability as Tomcat. At one point we had to fork Jetty to fix critical problems, never again.

Interesting point. I've never had an issue with Jetty, though I've never ran it at huge scale before. I've used it for internal business systems which at peak require 1000 req/s which isn't a whole lot. Do you run an wrapped tomcat to create fat jars or Tomcat as a standalone application server?

Just worked on deploying OpenAM on tomcat with Docker. A few things stuck out to validate the "hard to deploy in containers" point:

(1) node.js/Ruby/Python scale with processes, not threads. There's no supervisory/control environment over the processes, just the OS. JVM on the other hand expects to do a lot more process/thread control itself so it's kind of another "layer" between the OS and your code.

(2) Port binding doesn't work the same way, either. Most of our dockerized services have one port/process with simple load balancing built into our "routing fabric", which is something ops controls at my company. My understanding of JVM scaleout is that the servlet container is responsible for multiplexing incoming connections onto free capacity, which isn't how most docker shops work.

(3) I'm not sure what the typical deployment patterns are for servlet containers but they seem more multi-tenant w.r.t # of applications running in them, vs. a typical docker setup where containers are very thin and meant to be run in the dozens or more per-machine.

It's not that the JVM is inherently inferior, more than Docker has grown up around unix/linux ops-minded folks and they're bringing a lot of their assumptions about how software should be deployed and operated (e.g. "things should be scriptable") with them, and that their thinking is dominant among the current container-using crowd.

My understanding of JVM scaleout is that the servlet container is responsible for multiplexing incoming connections onto free capacity, which isn't how most docker shops work.

No, not really, typically you would just run N of your JVM processes with either some sort of load balancer (or your "routing fabric") to balance between them or a discovery mechanism.

I think you might be referring to some sort of big-box "enterprise" servlet container like Websphere or something quite different than Tomcat.

Can you elaborate on, or point me to some reading on the issues with containerizing tomcat and/or jboss? This is not something I've encountered before and may become an issue for me soon. Thanks.

In my experience the Tomcat/JBoss tend to be a relatively large overhead, but since they can run multiple "war" files under the same overhead this is not as much a problem when running a single container for multiple applications. But when you containerize them you'd like to run one instance per application which will multiply the already significant overhead.

Not sure if this is what the GP was referring to, but just my 2 cents.

> ...Microsoft creating their own version of it means its a viable technology.

...Microsoft creating their own version of it means it's _viewed_ as a viable technology by _managers_.

At first I was like :D

Then I was like :(

App containers are SORELY needed in microsoft ecosystem.

But whats up with the HyperV vendor lock-in? Looks like to those of us already investing in vmware or EC2 etc get the shaft...

Windows Server Containers will absolutely work in other hypervisors. You need to be running Windows as a guest OS obviously.

Hi John

Former-MS guy here working in SV. I could tell you work at MS by some of the terms you use which aren't common outside the company (e.g. "SKU") but MS people say a lot ;)

You should set up your profile on HN so that people know you're an MS guy and write a bit about yourself. I would email you directly, but your profile is blank.

It's been a viable technology ever since IBM started doing it in the 1960s, with VM.

Oh, wait. This isn't VM. This is something less-featureful than VM which will, possibly, eventually evolve into VM after a lot of hair-pulling. My mistake.

Reply on news.ycombinator.com