The New New Hotness (is dead already)
June 9, 2015 2:26 PM   Subscribe

CircleCI presents: It's The Future -Oh no. That’s old school. Heroku is dead – no-one uses it anymore. You need to use Docker now. It’s the future.
posted by CrystalDave (104 comments total) 41 users marked this as a favorite
 
Oh my lord. This hit way to close to home.

Docker - Now 100% buzzword compliant.
posted by lucasks at 2:36 PM on June 9, 2015 [2 favorites]


Do I laugh, or do I cry?

(wait, is someone recording conversations at my office?!)
posted by tocts at 2:37 PM on June 9, 2015 [2 favorites]


(wanders out into ocean, does not stop)
posted by boo_radley at 2:38 PM on June 9, 2015 [15 favorites]


So very true.
posted by GallonOfAlan at 2:41 PM on June 9, 2015


from a freebsd jail in 1994, i salute thee.
posted by gorestainedrunes at 2:41 PM on June 9, 2015 [16 favorites]


This is all too real.
posted by Edgewise at 2:42 PM on June 9, 2015


rsync . /var/www
posted by RobotVoodooPower at 2:43 PM on June 9, 2015 [5 favorites]


That was funny. What was it about?
posted by Stonestock Relentless at 2:48 PM on June 9, 2015 [3 favorites]


If you get images from Dockerhub, which 90% of Docker users do, your app is going to face a lot of security vulnerabilities that users of traditionally-installed operating systems have already patched.
posted by clarknova at 2:51 PM on June 9, 2015 [1 favorite]


There's something so odd about all these frameworks that provide "convenience" and "solutions." You need them to solve one isolated but nigh-intractable issue, but they end up introducing a couple of new ones, not unlike a certain mythical asshole. Only, unlike the original, it takes about six months before you notice the two new venom-spitting heads. If you're not careful, you can easily end up with something way more elaborate than it needs to be, which was the whole reason you adopted the new technology to begin with!

Still, I have to admit, Docker does some very nice things.
posted by Edgewise at 2:52 PM on June 9, 2015 [6 favorites]


clarknova, it makes sense that those images would have out-of-date and thus vulnerable packages. Standard practice would be to download one of those images, run updates, and then save off a new image, each time you run a build.
posted by unknownmosquito at 2:55 PM on June 9, 2015 [2 favorites]


Having spent the last 12 years as a programmer at a couple of Large Software Companies that only use their own stack, this kind of constantly-rotating platform bingo is something I am vaguely aware of from the outside.

This article pretty much nails how it has always seemed to me from that perspective, whether its actually true or not.
posted by thefoxgod at 2:55 PM on June 9, 2015 [9 favorites]


This is how I recall conversations about the 'coolness' of ruby and heroku... You will pry Java and GlassFish (or Payara) from my cold, dead, hands.


...and you can just use systemd in place of Docker. Or at least a chunk of it.
posted by combinatorial explosion at 2:57 PM on June 9, 2015 [1 favorite]


clarknova: "If you get images from Dockerhub, which 90% of Docker users do, your app is going to face a lot of security vulnerabilities that users of traditionally-installed operating systems have already patched."

And if you don't use dockerhub, there's little reason to not use vmware or hyper-v (rech) to barf out their next gen containers.

... I think of docker & etc as "enterprise sandboxie".

unknownmosquito: "each time you run a build."

Or we could admit that devops is a shoddy lie and have dedicated ops/ server teams to tend to virtual machines. Injecting "ensure the entire software stack is up to date" into an enterprise build process is not compelling to me.
posted by boo_radley at 2:58 PM on June 9, 2015 [15 favorites]


Thanks, this explains an incomprehensible sales pitch I heard a ponytailed tech millionaire make the other day about how the world was going to be changed by virtualized server instances. He had also invented an app for "ganja-aided meditation."
posted by johngoren at 2:58 PM on June 9, 2015


It has been 2 13 ZERO days since our last JavaScript framework.
posted by fifteen schnitzengruben is my limit at 2:59 PM on June 9, 2015 [50 favorites]


Injecting "ensure the entire software stack is up to date" into an enterprise build process is not compelling to me.

I actually agree with this, and really your whole comment, for what it's worth.
posted by unknownmosquito at 3:01 PM on June 9, 2015


 
:           (
 
posted by aubilenon at 3:02 PM on June 9, 2015


fifteen schnitzengruben is my limit: "It has been 2 13 ZERO days since our last JavaScript framework."

"only you can prevent javascript frameworks"
posted by boo_radley at 3:02 PM on June 9, 2015 [31 favorites]


unknownmosquito: "I actually agree with this, and really your whole comment, for what it's worth."

it was a pretty good comment, tbh.
posted by boo_radley at 3:03 PM on June 9, 2015 [3 favorites]


When a significant part of the requirement most people have for a new technology is that the webpage looks nice (see: hacker news), you know it's time to give up, do the minimum, defend your turf, collect the paychecks and find unrelated hobbies.
posted by smidgen at 3:06 PM on June 9, 2015


Man, I hate everything new.
posted by ignignokt at 3:07 PM on June 9, 2015 [2 favorites]


The hilarious part is that Ruby On Rails deployed to Heroku is presented as the comfortable and established (though old fashioned) status quo.
posted by idiopath at 3:16 PM on June 9, 2015 [17 favorites]


This whole pattern gives the strong appearance of generalizing to every part of the tech industry, broadly construed, not already composed entirely of exhausted old people (read: 35 and up) who decided fuck it, we'll just stay with what we already know because we can probably keep it trundling along until we retire or just give up and move into that van down by the river.

I have less and less to say against this as a career strategy, but then I'm going to turn 35 before long.
posted by brennen at 3:26 PM on June 9, 2015 [5 favorites]


I have more and more been seriously considering picking up COBOL.
posted by You Can't Tip a Buick at 3:28 PM on June 9, 2015 [6 favorites]


The article is perfectly on-point, but I feel like the author(s) are not nearly as down on the things being satirized as the comments here would suggest.

Anyway, it seems apparent to me that some form of containerization combined with cluster scheduling like Marathon on Mesos and service discovery like Consul is going to be a very useful technology for large-scale systems, and even further down the line will probably be one of those abstraction layers that people have a hard time even conceiving the absence of. Even though I still struggle to understand why Docker as yet deserves a number greater than zero in the major version slot, and even though it's still far less suitable for actual production use than the hype would suggest, I don't see anything that rules it out as the eventual containerization convenience wrapper of choice for that sort of system.

The credulous-slavering-boob/skeptical-grizzled-veteran binary has to be my least favorite thing about talking about this stuff with people.
posted by invitapriore at 3:29 PM on June 9, 2015 [3 favorites]


That was pretty much the lunch-and-learn talk given by one of our architects this week at my office. I think the title was "Docker all the things!"
posted by octothorpe at 3:39 PM on June 9, 2015 [1 favorite]


I literally cannot believe I was once employed to make a searchable database accessible via a website.
posted by infinitewindow at 3:42 PM on June 9, 2015 [5 favorites]


I think Docker is great, honestly. Still, I think too many people overlook the value of making some things Somebody Else's Problem™.
posted by ob1quixote at 3:47 PM on June 9, 2015 [3 favorites]


Buzzwords aside, as a QA person I do like having the quick and easy access to deployments that Docker gives you. No more begging for more test hosts or having to schedule test runs, you just spin up another set of containers and test away.
posted by octothorpe at 3:50 PM on June 9, 2015 [2 favorites]


WTF did I just read? Sigh...
posted by MikeMc at 3:50 PM on June 9, 2015 [2 favorites]


This isn't a grizzled veteran problem in that sense. The problem is not that the technology is necessarily bad (Docker is quite useful). It is that isn't even well vetted yet and people act like it is fait accompli. It's like the new replacement for steak & strippers is a cute name & a fancy webpage.
posted by smidgen at 4:01 PM on June 9, 2015 [3 favorites]


I'm not big into strippers, but I would like at least a steak if I'm going to end up using something that is evaluated at the same facile level as a typical Oracle deployment.
posted by smidgen at 4:04 PM on June 9, 2015 [3 favorites]


I mean, I think the technology is a little further along than all that, but I hope it's apparent from my previous comment that I agree with you in principle.
posted by invitapriore at 4:04 PM on June 9, 2015


Yeah, I'm just venting a little :-)
posted by smidgen at 4:06 PM on June 9, 2015 [1 favorite]


We have seen a wide variety of stability issues in docker containers, particularly the layered filesystems underneath.

"cattle not pets" is fine, but I could really go for less anthrax in the cattle.
posted by poe at 4:18 PM on June 9, 2015 [2 favorites]


-Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed systems and BDSM guy?
Don't Repeat Yourself.
posted by rustcrumb at 4:24 PM on June 9, 2015 [13 favorites]


Executive summary: If you keep cattle and not pets, you're gonna have to do some yak shaving.
posted by mccarty.tim at 4:25 PM on June 9, 2015 [10 favorites]


I am running what is effectively several ec2 and other instances that are all managed by puppet. I'm investigating docker, but given that I'm already segregating services to an instance where it makes sense, and using puppet to ensure that they are all deployed exactly to my spec -- including ensuring things like OpenSSL and other security-critical components are all up-to-date automatically, and controlling versions / deploying code from our git repos where appropriate.

I'm having a hard time seeing where I'd ever want to use docker over this, unless I want to go from running several smaller instances to less larger instances that basically segregate things the same way functionally, while providing many more complicated layers of abstraction that now require management. I'm not sure what I gain. I'm checking it out regardless, but it seems "not so useful" for me.

Of course, it is possible that I don't really "get it."
posted by MysticMCJ at 4:41 PM on June 9, 2015


I have more and more been seriously considering picking up COBOL.

You're gonna want COBOL ON COGS.
posted by Itaxpica at 4:43 PM on June 9, 2015 [12 favorites]


Problem: Linux is a bloated mess.

Solution: Let’s add yet another layer on top of Linux to handwave the complexity away!
posted by 1970s Antihero at 4:45 PM on June 9, 2015 [8 favorites]


You're gonna want COBOL ON COGS.

I have to admit, I legit snort-laughed at "(c) <DATE OVERFLOW>."
posted by You Can't Tip a Buick at 4:55 PM on June 9, 2015 [7 favorites]


we also would have accepted ©<19115>.
posted by boo_radley at 4:58 PM on June 9, 2015 [17 favorites]


I so love the first few weeks of any job which consist of figuring out what I need to run on the commandline to get a local instance running based on an out of date wiki entry and shrugs and rumours from more devs who've already been though it.
posted by Artw at 5:03 PM on June 9, 2015 [20 favorites]


#HIREABLE
posted by Artw at 5:15 PM on June 9, 2015 [1 favorite]


This seems unnecessarily limiting to me, what if I want to run multiple hypervisors?
posted by rhizome at 5:18 PM on June 9, 2015 [7 favorites]


Problem: Linux is a bloated mess.

Solution: Let’s add yet another layer on top of Linux to handwave the complexity away!


But...this isn't really the motivating problem behind containerization at all.
posted by invitapriore at 5:20 PM on June 9, 2015 [2 favorites]


Art if you're in Denver hmu
posted by boo_radley at 5:26 PM on June 9, 2015


I'm basically a caveman in computer terms — I'm real good at interacting with computers the way people interacted with computers from 1991 to 2000 or so, and inept at everything that comes after. (you'll take my copy of vi when you pry it from my cold dead hands).

Given my cavemannish cognitive constraints, is it possible to explain what containerization is? No, seriously, I don't know and I can't figure it out. I know if I go haring off to google and wikipedia to untangle it, I'll end up thinking I understand it, but will inevitably miss key details.
posted by You Can't Tip a Buick at 5:28 PM on June 9, 2015 [2 favorites]


I look at this and I think of all the operations effort that's going to go into keeping software written on abandoned platforms like this alive. And the pain of people dealing with 90% complete reimplementations in whatever the new hotness turns out to be when ops gives up.

But shit... I still use Perl - my gem has been glowing like a MF for YEARS now.
posted by wotsac at 5:34 PM on June 9, 2015 [3 favorites]


Gods, that read like a transcript from most of the dev meetings I ever sat in on. GAHHHHH!
posted by Thorzdad at 5:40 PM on June 9, 2015 [1 favorite]


Given my cavemannish cognitive constraints, is it possible to explain what containerization is? No, seriously, I don't know and I can't figure it out.

It's simple really. Just imagine a virtual machine that isn't virtual or a machine.
posted by blue_beetle at 6:02 PM on June 9, 2015 [8 favorites]


it's a chroot that theoretically actually works
posted by idiopath at 6:03 PM on June 9, 2015 [7 favorites]


This is very much what it's like to try and read Hacker News's RSS feed.
posted by cult_url_bias at 6:06 PM on June 9, 2015 [3 favorites]


needs more monad tutorials.
posted by lkc at 6:15 PM on June 9, 2015 [4 favorites]


Wow, so this is how the rest of you guys feel on the math threads.
posted by escabeche at 6:20 PM on June 9, 2015 [8 favorites]


Wow, so this is how the rest of you guys feel on the math threads.

Imagine how I feel in both tech and math threads!
posted by Thorzdad at 6:25 PM on June 9, 2015 [5 favorites]


Given my cavemannish cognitive constraints, is it possible to explain what containerization is? No, seriously, I don't know and I can't figure it out. I know if I go haring off to google and wikipedia to untangle it, I'll end up thinking I understand it, but will inevitably miss key details.

Yeah, definitely. So, before detailing the technical aspects, let's talk about virtual machines for a second. Balanced analysis aside, you can imagine the potential benefits of virtual machines for systems with more than a few moving parts, if you put each part (for example, an HTTP server) or a small number of related parts in their own VM:
  • You don't have to worry about conflicting dependencies, conflicting file usage patterns, etc.
  • You can include only the things on that machine that the part depends on.
  • You can standardize the setup process for each type of machine, which lets you alter them independently without having to worry about stepping on anyone's toes.
  • You can adjust how many and which VMs you have running with code, no physical access to boxes required.
  • You can constrain the resources available to a VM, so that if you've got several running on one physical machine you don't have to worry about a runaway process taking down everything else.
So those are some of the benefits, but the drawbacks are numerous. VMs are pretty heavy-weight, and besides the fact that they're pretty slow to provision/restart/etc. you end up paying the fixed cost of a new OS instance, most of whose capabilities are going completely unused, with each new machine you spin up. So containers are born out of a desire to reap the benefits of virtualization without paying the performance penalties. That's accomplished by the coordination of several techniques:
  • Process namespacing, which lets you convince a process or set of processes that they are the only ones running on a system, with no ability to inspect or tamper with processes running on the computer outside of that set,
  • Mount namespacing, which lets you convince a process or set of processes that they have access to an entire filesystem, even though they're actually just seeing a subdirectory that you specify inside the parent filesystem,
  • Resource control for processes, limiting things like memory/CPU usage,
  • Other things like virtual network interfaces, you get the idea.
Linux implements these things natively for the most part with kernel features like cgroups (well, except chroot doesn't really work, as mentioned, so container technologies have worked around that to supply the same sort of filesystem isolation), things like Docker mostly just do the heavy lifting for you in terms of coordinating them and setting them up based on a specification you provide, and also distributing the packaged components you create. Crucially, what this combination of technologies theoretically allows you to do is to run a process in an isolated environment a la virtual machines, but all with the same OS kernel. In terms of runtime overhead, this is much closer to just running the process(es) directly on the host OS than it is to running them in a VM. Storage overhead is reduced too, but to a lesser extent.

The devil's in the details, as always, but that's the bird's-eye view.
posted by invitapriore at 6:26 PM on June 9, 2015 [41 favorites]


You need to use Docker now. It’s the future.

I thought Dockers were already standard throughout the tech industry.
posted by octobersurprise at 6:39 PM on June 9, 2015 [15 favorites]


(I'll show myself out.)
posted by octobersurprise at 6:40 PM on June 9, 2015 [5 favorites]


I still don't get why I wouldn't just use a VM for that. KVM is really quite fast and the memory overhead is slight if you do dedupe with KSM.

The isolation is better and it is more flexible in that it will run any OS you desire. There is a reason the world moved on from LXC and similar. If there are problems with the tooling making deployment hard, it seems.to me that we should be fixing that rather than going backwards.
posted by wierdo at 6:41 PM on June 9, 2015


KVM...is more flexible in that it will run any OS you desire.

Ha! Shows what you know! I run Docker on my PC workstation...using Boot2Docker, which rests on top of a Linux VM.

Oh, crap.
posted by Edgewise at 6:48 PM on June 9, 2015 [1 favorite]


I still don't get why I wouldn't just use a VM for that. KVM is really quite fast and the memory overhead is slight if you do dedupe with KSM.

I have to admit, my experiment with splitting up a KVM server into functional groups (www, smtp/imap, etc.) and reimplementing them as unprivileged LXC containers* on the same host was everything I could have hoped for. Effectively instant startup, minuscule overhead, separation of concerns, don't have to keep multiple kernels and fat distros updated, and of course, the relative security of no actual root in any of them. KSM is useful if you actually have a good reason to run virtual full systems, but if you don't, then why dedupe when you can just not dupe in the first place?

*And yes, I know LXC container is an example of RAS syndrome, like putting your PIN number in the ATM machine.
posted by George_Spiggott at 6:56 PM on June 9, 2015


I don't really see the deployment issue. There are plenty of standards that address that - cloudinit in conjunction with something like puppet/chef work awesomely, and are easy to script around -- I have new instances deployed by running a single command (./deploy webserver, for example) and they get named, users, and all packages/code installed on them within 3-5 minutes. At the same time, this webapp doesn't really benefit from containerization as much as it does the ability to spin up new instances quickly that don't share hardware. And if I have to update any of them, then I update my puppet manifests, and it all goes out on it's own within 30 minutes - or I can push them through on demand, if needed.

Where I get concerned with docker is for a scenario like the Heartbleed issue, or any of the other numerous SSL bugs I've seen. So, instead of updating a puppet manifest (or having puppet automatically pull and deploy new versions) I have to update each docker image and then re-deploy those, right? Or, alternatively, I have something like puppet running inside of it (which goes against the philosophy from what I understand) that updates it, but then what have I really gained? We react to SSL bugs across our entire infrastructure within 30 minutes of the package being available, and we need that ability.

At the same time, something like docker is great for development on a local machine - I think it's a great tool for rapid prototyping. I do not believe it's always the appropriate tool for a production environment - It certainly doesn't appear to be for ours yet, but I can see where it would be appropriate for others.

I like the take that Netflix has on docker: We designed these images to be as small as possible in scope so you can get the minimum function running as quickly as possible. That means they do not consider production issues that matter like multi-host networking, security hardening, operational visibility, storage management, and high availability with automatic recovery.

One thing I will point out about docker - You are stuck on linux. Not really a problem for most things, but the overwhelming majority of my puppet scripts will run on OSX (courtesy of macports) and FreeBSD. I haven't cleaned up all of the package names, but that's the only place I've been having problems. If you want to do local dev NOT on linux, as mentioned up in the thread, you need a linux VM -- period.
posted by MysticMCJ at 7:09 PM on June 9, 2015


Can you live migrate a docker container to another host, possibly halfway around the world, with no interruption to users or does it depend on some sort of HA or load balancer like we used to do for physical servers without containers? (Seriously asking)
posted by wierdo at 7:22 PM on June 9, 2015


wierdo: "Can you live migrate a docker container to another host, possibly halfway around the world, with no interruption to users or does it depend on some sort of HA or load balancer like we used to do for physical servers without containers? (Seriously asking)"

If I understand you correctly, something like Mesos and Aurora has you covered.
posted by boo_radley at 7:39 PM on June 9, 2015


MysticMCJ: If you want to do local dev NOT on linux, as mentioned up in the thread, you need a linux VM -- period.

Oh?
posted by coriolisdave at 7:43 PM on June 9, 2015


invitapriore: thanks! I think an actual light bulb may have appeared over my head when I got to the second bulletpoint list. So the idea is (this might be me missing the subtle details) to allow processes to pretend that they're running on their own VM without actually giving them a full VM, through giving them unique namespaces and so forth for everything they might need to use. I'm struggling to make an accurate analogy to stuff I actually get from object-oriented programming: so, like, just as an object can (for example) have private attributes that have the same names as other variables in a program, meaning that you don't have to care about whether a given object has the same attribute names as the attributes of any other object, containerization allows processes to have (for example) what appear to be private filesystems, meaning you don't have to worry about other processes writing over / otherwise interfering with files you're using. Right?
posted by You Can't Tip a Buick at 7:47 PM on June 9, 2015


As a very antiquated programmer that likes to keep on top of Where The Industry's Going (have to, really, likes is perhaps a bit strong), I only feel comfortable when I can envisage the whole stack from UI to silicon. That used to be easy, either because I hadn't burned through quite so many IQ points back then or because I'd pretty much watched the PC grow from the days when if you had an OS it was CP/M to the point where hardware virtualisation came in. I knew a bit about Unix, a bit about VMS, nothing at all about big iron.

What's changed since then, in the small window into IT as a whole that I look through, is an insane inflation of scale, an insane deflation of the distance between dev and user, and a wholesale transition from disconnection to connection everywhere. All these fundamentally change the landscape and transform what things like security, expectation, business models and data actually look like to those who have to manage them.

In particular, they're smashing into all the old models of how to do things. Stuff like containerisation is changing the partition models between virtualisation, OS and apps. Stuff like devops is changing the partition models between design, implementation, testing and deployment. At the same time, the in-browser services and mobile app usage model is changing the partition models between software, services and user environment. All these things are hitting on the infrastructure in different ways, and hunting for the sweet spots that match optimal results for everyone, but with all sorts of interactions and multiple different requirements.

Layer on top of _that_ the various industry habits of over-hyping, trend-tropism, Corporate Vision Marketing, and deliberate obfustication (or disguised confusion, those two are difficult to separate), and it's a wonder any of this shit works, let alone that quite a lot of it works so well. There are a lot of energetic, brilliant and creative people attacking all the problems. There's a lot of insane crud - but if you look at, say, the human metabolic pathways, we've got a way to go yet.

In other words - thiese are the early days of a very different world, and we're still at the Cambrian Explosion stage. I think we're moving towards the Devonian (yeah, yeah) where the basic body plans are being worked out. I don't feel (too) bad at having to take several runs at something like Docker before I work out how it's different to what's gone before and how it's not, because it does mean looking back to where it's come from, the environment in which it has evolved, and what to read between the lines. It's one of a hundred current interesting and frustrating trends, documented in vastly different ways, and the days when things washed up on the shores of my perception in monthly magazine-shaped chunks have long gone.

It's a great time to be in tech, but it's a different great time to ten or twenty or forty years before, and of all the things that are hard, updating one's mental models is the hardest.
posted by Devonian at 7:58 PM on June 9, 2015 [15 favorites]


Eventually it will dawn on someone that what we need are operating systems that sandbox everything by default... the exact opposite of the default permissive environments that Linux, Windows, MacOS, etc. all give.

VMware was the first really successful step in this direction for a lot of people, because you can sandbox the entire OS. Everything since is trying to make things more efficient and/or fine grained.

Does that about sum this whole situation up, or am I off base?
posted by MikeWarot at 8:00 PM on June 9, 2015 [3 favorites]


Eventually it will dawn on someone that what we need are operating systems that sandbox everything by default...

The Qubes OS and its creator were the subject of a post a week ago.
posted by George_Spiggott at 8:08 PM on June 9, 2015 [2 favorites]


MikeWarot: that's exactly what iOS and Android do now, and what OS X and Windows are moving towards as rapidly as application developers can update. This is easy to do for apps which don't need to access arbitrary data but is going to take time to develop the appropriate ways to mediate permission so e.g. your photo app doesn't have to ask for permission to open each file so it can show a thumbnail display.

On OS X, if you open a Console window you'll see messages from sandboxd if you use one of the system applications like Mail.app each time it uses a file open / save dialog, accesses your contacts, etc. This is now mandatory for App Store apps as well, which is why certain classes of apps have left the app store because the permissions model wasn't compatible with what they need to do:

http://www.panic.com/blog/coda-and-sandboxing/

I'm expecting that within 5 years this will be the default for everything because it's so valuable to break the model where making the mistake of running a free “game” means that your banking credentials are now in the hands of some mobster.
posted by adamsc at 8:11 PM on June 9, 2015 [1 favorite]




You know I read that as Québec OS and suddenly got really interested, cos, well, nation within a nation and all that.
posted by pmv at 9:10 PM on June 9, 2015 [1 favorite]


A lot of the terminology surrounding docker is unnecessarily impenetrable. Once you think of it as Solaris Zones for kids who don't like Sun/Oracle, stripped down to run a single app to simplify development and deployment, it's easier to figure.

The self congratulatory, overinflated tones surrounding the current tech industry is mostly to blame. Everyone's gotta have a cute marketing name and pseudo technical jargon by the dictionary full to convince you it's revolutionary and new, rather than a clever and useful take on something well established.

I mean, it's always been a problem, the further you stay from actual radical innovation, the more it's devs and users try to sell you that it's revolution rather than evolution, but it's way out of hand now.
posted by Slap*Happy at 9:31 PM on June 9, 2015 [6 favorites]


Buzzwords aside, as a QA person I do like having the quick and easy access to deployments that Docker gives you. No more begging for more test hosts or having to schedule test runs, you just spin up another set of containers and test away.

I mean, the same can be said of Vagrant. Containers are pretty much just more efficient virtualization layers. Really, the most important innovation behind docker is that it doesn't depend on Ruby.
posted by pwnguin at 9:40 PM on June 9, 2015 [3 favorites]


faintpraise dot text there
posted by boo_radley at 9:44 PM on June 9, 2015 [1 favorite]


Also not actually a JavaScript framework.
posted by Artw at 9:56 PM on June 9, 2015 [4 favorites]


I mean, it's always been a problem, the further you stay from actual radical innovation, the more it's devs and users try to sell you that it's revolution rather than evolution, but it's way out of hand now.

Remember how big a deal XML was?
posted by aubilenon at 11:16 PM on June 9, 2015 [1 favorite]


Metafilter: Look I really don’t want to host my own stuff.

Also, can someone alter that cat-that-should-buy-a-boat meme to say, "I should buy some containers?"
posted by digitalprimate at 2:03 AM on June 10, 2015


Or we could admit that devops is a shoddy lie and have dedicated ops/ server teams to tend to virtual machines. Injecting "ensure the entire software stack is up to date" into an enterprise build process is not compelling to me.

DevOps is successful in one area: if you have stateless web services, and stateless UX, you can easily use it to build new VMs in whatever environment you want. This is incredible, when it works, but my complaint is that currently many people in power seem to be chasing buzzwords—AWS, Heroku, Docker!—without realizing that it's the statelessness that's necessary. You haven't known Hell until you've tried to write Chef scripts for environments built entirely by accrual, where the leadership lacks enough vision to even know why that's bad.
posted by sonic meat machine at 4:28 AM on June 10, 2015 [4 favorites]


Do any of the current technologies include the ability for an app to declare what subset of the OS (or whatever you want to call it) APIs are it's actually going to use? Or, alternatively, for these to be determined dynamically at runtime - implicit declaration on first use? That's the sort of behaviour I'd think would benefit constructing lightweight containers, reducing surfaces, deploying minimal VM resources, maximising manageability, and all that good stuff.

This is the sort of thing I'd like to know about, but which is practically impossible to discover unless you (a) read all the things, (b) can decode all the marketing spiel, (c) hang out with people who actually use this stuff. All doable, but at great risk to the beer fund.

One of the problems in this game is that there isn't a cadre of sceptical, enthusiastic, well-informed journalists on top of it all. All the information is spread out across a Babel of blogs, forums and miscellaneous sites, and Google is no good to you if you don't know the vocabulary people are speaking or don't have the time to sift through all the outdated, all the marketing-led and all the frankly-not-even-wrong out there. Which is a real delta of shifting sands. There are plenty of developers who are also talented writers, but plenty more who aren't - but no business model I can see that actually allows the creation of a full-time team dedicated to this. (This isn't the Web's fault; it has always been well-nigh impossible to be a generalist software technologies publication, because there's no sensible advertising model.)
posted by Devonian at 4:28 AM on June 10, 2015 [2 favorites]


So yeah. I'm on course to get into web development. (Just at the beginner language stage). Is all this stuff things that I will eventually know or need to know?
Cause wow.
I figure I sorta know a lot of what it's referencing at a basic level because I laughed.
posted by Jalliah at 4:37 AM on June 10, 2015 [1 favorite]


rhizome: This seems unnecessarily limiting to me, what if I want to run multiple hypervisors?

Oh, that's no problem at all! The sysadmins will just swing by your house and nail the doors shut while you sleep and then set it ablaze.
posted by wenestvedt at 5:38 AM on June 10, 2015 [12 favorites]


Sonic Meat Machine: DevOps is successful in one area: if you have stateless web services, and stateless UX, you can easily use it to build new VMs in whatever environment you want.

But for the rest of us who don't tend a Clone Army server farm of identical web servers, and instead have a more diverse flock of sheep (note: not cattle, not pets) to tend, it's kind of abstractly interesting but not as immediately useful.

Slap*Happy: Once you think of it as Solaris Zones for kids who don't like Sun/Oracle, stripped down to run a single app to simplify development and deployment, it's easier to figure.

Right, that's what I thought of the first time I heard them explained in detail: Linux Containers are surprisingly close to Solaris Zones -- a.k.a. Solaris Containers, whattaya know --- though they have the benefit of lessons learned after most of a decade of Zones being actually used.
posted by wenestvedt at 5:56 AM on June 10, 2015


This is 100000000% hilarious to me right now, as I just walked out of a room after, hand to God, a 20 minute derail at the end of a 70-minutes-over meeting about how we need to scrap everything and go to Docker because it's the future.

Send help. And beer. Maybe mostly beer.
posted by sldownard at 7:03 AM on June 10, 2015 [6 favorites]


Remember how big a deal XML was?

We should use SOAP!
posted by Artw at 7:27 AM on June 10, 2015 [3 favorites]


But for the rest of us who don't tend a Clone Army server farm of identical web servers, and instead have a more diverse flock of sheep (note: not cattle, not pets) to tend, it's kind of abstractly interesting but not as immediately useful.

Well, the places that I've seen it work usually organize their systems into pods of heterogeneous servers, and then spin up pods as a whole. Or, they rework it so that all the different heterogeneous components (which one assumes you need in prod, staging, and dev) can be built based on small divergences from a common base. Almost nobody uses just a homogenous farm of 5000 Apache servers.
posted by sonic meat machine at 7:45 AM on June 10, 2015 [1 favorite]


Docker may not be the F U TU R E, but something like it will be. True virtualization (like vmware and cousins) eats resources and slows some things down pretty badly - one of our bits of infrastructure, on which we depend heavily, is about three times slower on a VM than on a 5 year old laptop with nominally the same resources. Docker sits closer to the hardware, so doesn't incur the same penalties.

But docker is still kind of a pain to set up and use - easiest way is still to use something like Puppet or Ansible to get it running for complicated installations, which ours is.

I've been trying to encourage people here to experiment with docker (or similar tech) with the hope that we could both get better hardware performance, and use it to break apart our needlessly monolithic service - everything runs in one big Python service even though it is really functionally about five services that only interact minimally.
For instance we use at least three and maybe four relational databases, two (or maybe more) nosql data stores, and more! So far no luck, but it would so simplify our jobs (though complicate ops jobs a bit) to break things apart.
posted by Death and Gravity at 7:46 AM on June 10, 2015


I'm not a techie, I'm a bartender. But I'm a bartender at a tech-heavy private club, so I've heard conversations that sound like this, and still find it hilarious.
posted by Pirate-Bartender-Zombie-Monkey at 8:13 AM on June 10, 2015 [2 favorites]


"So yeah. I'm on course to get into web development. (Just at the beginner language stage). Is all this stuff things that I will eventually know or need to know?
Cause wow."


I'd say possibily yes, one dynamic website is made up of server side language (python, asp, php), client side language (javascript), css, html. Also you will have to understand the basic operations of a webserver and how to manipulate databases. Knowing HTTP is a must. Versioning (git for example) is something that you have to learn immediately right now.

Usually you will have a dev environment where you will work on your project, and the you will have a production env. where you will depoly, and only if you are very lucky those two envs will be equal.

Otherwise docker will be really useful to you if you don't really want to care where you are developing and where you are deploying for production, it will also help greatly if you work in a team, one docker image for everybody.

I personally have found very useful to dockerize some webapps, like phpmyadmin. After preparing the base image, I wrote a startup script that acts like a commandline tool, you pass it a mysqlhostname, login and password. When run, it starts a container that connects and automatically opens a browser window. Compare this for everytime you wanted to use phpmyadmin and had to install and configure it somewhere from scratch.

Docker has quirks and stuff, but all the time it costs to prepare a nice Dockerfile (opposed to deploying directly on dev/prod) is time that you gain later in deployment rapidity. In any case, you started learning, and I'd suggest to focus on the webdev stuff, and only later go with docker.
posted by yann at 8:39 AM on June 10, 2015 [5 favorites]


LWN is currently my go-to for "here's what the heck this open source or open source-compatible suite of technologies is, what it's competing against, and whether it's mature enough for you to really want to depend on it." The Recompiler, I hope, will have a similar level of friendly usability.
posted by brainwane at 8:50 AM on June 10, 2015


So yeah. I'm on course to get into web development.

Probably depends on where you go. We run web apps on Windows and they hit SQL Server on other Windows boxes, and the Windows boxes are all VMWare VMs, and none of the devs have any reason to even worry about how VMWare works. So having made web apps for 15 years but coming from that background, I understood exactly 0% of the linked article. invitapriore did a great job of explaining some of it.

I think Devonian hit it on the head talking about a lack of journalistic resources for analyzing these zillions of technologies and figuring out how they compare, or whether they are "prime time" etc. For most folks who are devs and not ops people, you just learn a bit about whatever they use at your next job - like I'm moving somewhere that uses AWS so I guess I'll learn that.
posted by freecellwizard at 9:04 AM on June 10, 2015 [1 favorite]


Artw: "Remember how big a deal XML was?

We should use SOAP!
"

ZESTful JSON micro-apilettes.

Jalliah: "Is all this stuff things that I will eventually know or need to know? "

Eventually eventually? From my perspective (and to play off wenestvedt, I'm more of a shepard and not a cowboy), I expect a new developer to focus on building the application artefacts. If you don't have anything to put in it, what good is a container?
posted by boo_radley at 9:04 AM on June 10, 2015 [4 favorites]


You will pry Java and GlassFish (or Payara) from my cold, dead, hands.

The problem of Java is that it's just so.... horribly.... stagnant.

I've recently started to dabble in Java (I'm usually a front-end guy, but we were understaffed, so...), and frankly there's a lot to like. Coupled with a modern IDE, a lot of Java code becomes surprisingly pleasant to write, to the point where Java's trademark verbosity really isn't an issue.

However, when it comes to the governance, evolution, and open-source communities surrounding Java, everything is just sad and terrible.

If I find a bug in any popular JS framework, I can hop onto Github, search to see if anybody has had the same problem, file a bug, and possibly also fix the bug with a pull-request. Meanwhile, there's tons of exciting stuff going on relating to the evolution of JavaScript, and Node recently went through a weirdly-productive schism and reconciliation, emerging with tons of new ideas and a great governance model.

In contrast, it's difficult to find a bug tracker for most OSS Java projects, and there's seemingly very little going on at all in Java's OSS world at all. Everything is still done over listservs (and therefore impossible to browse or search), and seems to be controlled by a close-knit cabal that lost interest years ago. Apache's projects seem to be particularly stuck in the 1990s mindset of open-source software.

Oracle probably can take a big share of the blame: Java only just go Lambdas in Java 8.... about 5 years after they were generally considered a good idea (and widely used thanks to Google's Guava library).

Last week, Codehaus pulled the plug on its servers, and I'd (conservatively) estimate that about 50% of open-source Java projects vanished from the web overnight. Forcing everybody over to

XMLBeans is deprecated, and JAXB feels unfinished (despite being over 10 years old). Maven has glaring and ridiculous bugs that haven't been fixed in 2 years. Every Java library I touch feels the same way -- stagnant, unfinished, and unwelcoming to anybody who might want to fix it.

I want to love the Java ecosystem. Java *is* salvageable, and there's enough existing Java code that many of us are going to be stuck with it for a long time. I'm just a little tired of waiting for Java to get with the times....
posted by schmod at 10:34 AM on June 10, 2015 [1 favorite]


I’ve always found the sociality of the Ruby and Javascript communities to be a major problem. It’s nice to be able to ask for help on Github, but it’s even nicer to not have to because things are stable and documented. A lot of the faster-moving language communities seem to prioritize social interactions over documentation and predictability, to the point that you need to know who’s-who and exhibit cultural fit in order to work effectively. I am often reminded of Coda Hale’s excellent 2011 criticism of Scala:
In addition to the concepts and specific implementations that Scala introduces, there is also a cultural layer of what it means to write idiomatic Scala. The most vocal — and thus most visible — members of the Scala community at large seem to tend either towards the comic buffoonery of attempting to compile their Haskell using scalac or towards vigorously and enthusiastically reinventing the wheel as a way of exercising concepts they'd been struggling with or curious about. As my team navigated these waters, they would occasionally ask things like: "So this one guy says the only way to do this is with a bijective map on a semi-algebra, whatever the hell that is, and this other guy says to use a library which doesn't have docs and didn't exist until last week and that he wrote. The first guy and the second guy seem to hate each other. What's the Scala way of sending an HTTP request to a server?" We had some patchwork code where idioms which had been heartily recommended and then hotly criticized on Stack Overflow threads were tried out, but at some point a best practice emerged: ignore the community entirely.
posted by migurski at 11:11 AM on June 10, 2015 [1 favorite]


C# is worth a look if Java is too stagnant for you, especially as it's in the process of seperating its links with the least fashionable operating system.
posted by Artw at 11:16 AM on June 10, 2015 [2 favorites]


I'm just a little tired of waiting for Java to get with the times....

Unfortunately, until Oracle gets religion, Java is a legacy orphan at this point, Cobol Pt 2. Oracle is notoriously uncooperative and litigious, and likely to unleash the legal weasels at attempts to fork (which was good back when Microsoft was in embrace-extend-extinguish mode, but bad now that they refuse to move Java into the modern day.)

Worse, all of the Big Players think they're all Bell Labs now, and have their own C-derived in-house languages: C#, Go, Hack, Swift, Rust, etc. Saving Java is too much effort, too risky and not cool enough to interest the big brains guiding dev work at places large enough to attempt it. Maybe Apache? They'd need to get their own crap together, first.
posted by Slap*Happy at 11:27 AM on June 10, 2015 [3 favorites]


Almost nobody uses just a homogenous farm of 5000 Apache servers

It's all nginx, right?
posted by kenko at 12:58 PM on June 10, 2015 [2 favorites]


Artw: "C# is worth a look if Java is too stagnant for you, especially as it's in the process of seperating its links with the least fashionable operating system."

SCO Xenix?
posted by boo_radley at 1:40 PM on June 10, 2015 [3 favorites]


> Unfortunately, until Oracle gets religion, Java is a legacy orphan at this point, Cobol Pt 2.

OTOH if you have the gift of spotting the COBOL of today you're employable for the next 50-75 years. Java might be it! (When I worked for a hospital I got some mileage out of MUMPS.)
posted by jfuller at 2:04 PM on June 10, 2015 [1 favorite]


Oh god, the Oracle/Java "community." I remember looking for a specific patch at one point, and as I was looking, it appeared that any request for help was shouted down and a suggestion to go read the manual. Huge culture shock when you're used to the friendliness and humor of the HTML/CSS folks...
posted by fifteen schnitzengruben is my limit at 4:00 PM on June 10, 2015 [1 favorite]


Given the popularity of Java for the sort of in-house custom business software that rarely if ever gets rewritten and isn't part of some major software house or short-lived startup, I suspect it is in fact the next COBOL. I mean COBOL is still around, and it hangs on in environments that are either not interested in change or very conservative (like banks).
posted by thefoxgod at 7:30 PM on June 10, 2015 [1 favorite]


fifteen schnitzengruben is my limit: ...any request for help was shouted down and a suggestion to go read the manual. Huge culture shock when you're used to the friendliness and humor of the HTML/CSS folks...

Hmmmm…. It's probably for the best that you missed the warmth and friendliness of the Linux community in the 1990s. *wince*
posted by wenestvedt at 5:33 AM on June 11, 2015


« Older 40 acres and a mule   |   R.I.P. Hermann Zapf, 1918-2015 Newer »


This thread has been archived and is closed to new comments