Jess Frazelle
github.com
github.com
If I were in charge of hiring, I'd have recruiters pestering the hell out of her to join my team.
Seriously, she's one of my favorite people that I've never met :)
Did she talk about advantages/disadvantages to this approach? Does she use this daily?
(I am not a web developer, so this is a sincere question. I am genuinely curious!)
Putting programs in a container means you keep your main system free of this cruft.
and the non-solutions of WinSxS (https://en.wikipedia.org/wiki/Side-by-side_assembly) and the current 'binaries are linked to an exactly matching library forever, install EVERY possible library version'.
https://web.archive.org/web/20100305054645/http://msdn.micro...
Note that in terms of isolation, I would be hesitant to consider this (dockerizing apps) a particularly strong solution in terms of security now, but isolation is not only about security, but also about e.g. preventing applications from crapping files all over your system (and being able to know where they've put files - e.g. "docker diff" is quite nice), and having convenient ways of restricting their resource usage etc.
For me at least, when I dockerize apps it tends to be about those concerns, as well as being able to run multiple versions of apps conveniently etc. or to be able to package up a whole toolchain and lock it at combinations of tools I know work well together.
Different network configurations per browser. This is useful for doing things like checking geo-targetting via VPNs etc.
Better security isolation. Chrome is pretty good at this, but if you want to run a suspicious add-on this is a good way to do it.
Better isolation for scriptable browsers.
I'm sure there are plenty I haven't thought of.
One particular problem is that drama has a certain amount of "background radiation" in the world, a noise floor you can't eliminate. The right solution is to have a gate in the sense that you just ignore things underneath the noise floor.
Lowering drama is possible, but elimination is impossible IMO. Hence, you end up in a situation where the perpetually outraged keep being outraged, because there is always some kind of noise floor you can grab onto.
You need to gauge "drama relative to other situations" in order to figure out where we stand. And once you do, you will realize that some people are feeding off of perpetual outrage.
In short, I think we need to define when we activate the gate. And for me personally, the amount of drama in tech is actually not that high. Try Sales&Marketing for a change :) It is just that social media is an excellent amplifier, so now we have far more focus than you had back in the 80'es and 90'es where the situation is likely to have been worse.
She was always around to help or hack something cool. I remember the night of the release of Docker 1.9, we stayed late at the office to merge the last PRs and run test suites before releasing the binaries. Jess did not have to be there but she stayed to help Tibor (another amazing human being and prolific contributor) and myself 'til 23pm on the release process. You know you are surrounded with talented engineers when you can count on them regardless of the difficulties encountered. That night, her presence lifted a big burden off my shoulders.
I'm not sure I would have had the same excitement for Docker before joining if she was not working there. To me, she had a huge impact on the craze towards containers.
This should be part of the title.
Oh, you mean why was it submitted & upvoted? Frankly, I never know why any particular story takes off whereas others do not. E.g., First Steve Yegge blog post in 5 years didn't even make 1st page of HN! (https://news.ycombinator.com/item?id=12979108)
Guess you'd have to ask everyone who up-voted why they did.
Based on your comment, you're probably not the target audience for the platform. I recommend checking out some of the components to see if they meet your criteria of simplicity.
A few examples:
https://github.com/docker/swarmkit
https://github.com/docker/notary
https://github.com/docker/infrakit
https://github.com/docker/hyperkit
We are continuing the work of carving out more and more usable components from the platform.
P.S. Her twitter timeline is a must-follow - https://twitter.com/jessfraz
Jessie is an incredible speaker and a really funny engineer. It was genuinely hard to not laugh watching her talk @ Monitorama last year titled "Everything is Broken":
Kubernetes is a project started by Google to make managing containers at scale, on premise, or on the cloud, streamlined and dead simple. So far it is "winning".
[0] http://blog.kubernetes.io/2017/02/caas-the-foundation-for-ne...
https://techcrunch.com/2017/02/21/kubernetes-on-microsofts-a...
"This means the service is now backed by an SLA, and users will be able to get support contracts from Microsoft. Maybe more importantly, though, Microsoft also added two pivotal new features with this update: the ability to easily scale Kubernetes clusters up and down and support for high-availability setups with multiple masters."
Also, Jess Frazelle will be presenting at CloudNativeCon/KubeCon in Berlin on March 30 [3].
[0] https://kubernetes.io [1] https://www.cncf.io [2] https://kubernetes.io/partners/ [3] https://cloudnativeeu2017.sched.com/mobile/#person:jess_fraz...
Disclosure: I'm the executive director of CNCF.
Background for k8s is that Google had (has) an internal container scheduler called Borg (https://research.google.com/pubs/pub43438.html) with which they do clever things like pack a CPU-hungry and RAM-hungry process on the same box so all of that machine's resources get used, and can use the same server for a mix of production processes (that might e.g. be latency-sensitive need a dedicated core) and non-production tasks like internal data crunching. For example, a non-production task can run opportunistically when a prod job isn't using its full allocation of RAM, and be preempted if the production tasks need that RAM later or more important tasks come along.
Kubernetes is a ground-up effort to do the same sort of thing in the open. The components are different--etcd instead of Chubby, and of course not using Google's internal container stuff for tasks--but idea's the same.