Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

Post reply on HN
Print view View original

241–250 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#241

Post by stephenr »

iamleppert wrote: post #227

I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil. Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker. Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll…

I'm definitely no fan of Docker or the ridiculous containerisation trend, but I think I may disagree with one key thing you said:

> Focus on your product, outsource the rest.

What do you mean by outsource the rest?

Do you mean, "hey we're using AWS -as-Service because we don't want to manage a DB cluster or deal with a load balancer?

Or do you mean, rely on existing available tools and stop reinventing the wheel every week?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#242

Post by statico »

stephenr wrote: post #241
iamleppert wrote: post #227

I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil. Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker. Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll…

I'm definitely no fan of Docker or the ridiculous containerisation trend, but I think I may disagree with one key thing you said: > Focus on your product, outsource the rest. What do you mean by outsource the rest? Do you mean, "hey we're using AWS -as-Service because we don't want to manage a DB cluster or deal with a load balancer? Or do you mean, rely on existing available tools and stop reinventing the wheel ever…

> What do you mean by outsource the rest?

iamleppert means: Identify your company's core competency and do that in house, but outsource or avoid that which is not your core.

For example, we're making a game. Gameplay, art, and tech is all done in-house and not with remote contractors because it needs to be -- it's the part of the product we love and the part our players will end up loving. Email, forums, chat, HR, applicant tracking systems, and git hosting are outside of our core and best handled by others.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#243

Post by stephenr »

statico wrote: post #242
stephenr wrote: post #241

Earlier quoted context omitted.

I'm definitely no fan of Docker or the ridiculous containerisation trend, but I think I may disagree with one key thing you said: > Focus on your product, outsource the rest. What do you mean by outsource the rest? Do you mean, "hey we're using AWS -as-Service because we don't want to manage a DB cluster or deal with a load balancer? Or do you mean, rely on existing available tools and stop reinventing the wheel ever…

> What do you mean by outsource the rest? iamleppert means: Identify your company's core competency and do that in house, but outsource or avoid that which is not your core. For example, we're making a game. Gameplay, art, and tech is all done in-house and not with remote contractors because it needs to be -- it's the part of the product we love and the part our players will end up loving. Email, forums, chat, HR, ap…

Define "handled by others".

Installing an exchange server is arguably letting email be "handled by others" because you are not responsible for how it works, just the setup and monitoring, which could be handled by in-house staff or by a contractor.

My point is that "focus on the core competency" doesn't have to mean "make our company reliant on a dozen other SaaS businesses who may go offline or change their business model/functionality on a whim"

Re: Why Docker Is Not Yet Succeeding Widely in Production

#244

Post by whitenoice »

spoondan wrote: post #181
tracker1 wrote: post #172

Earlier quoted context omitted.

That's a bit of my point... If you're building relatively small independent services with Docker you can deploy service A with node 0.10 as it's tested environment and service B with iojs 2.4 on the same server, without them conflicting... when you need to update/enhance/upgrade service A you then can update the runtime. The same can be said for ruby, python and any number of other language environments where you hav…

> The same can be said for ruby, python and any number of other language environments where you have multiple services that were written at different times with differing base targets. I've seen plenty of instances where updating a host server to a new runtime breaks some service that also runs on a given server. This is a solved problem in Python and Ruby. In Python, use virtual environments. In Ruby, use RVM. You w…

In local system yes, but in production its painful to work with. With RVM for isolation you would create gemsets for each app with specific ruby version. It OK for 2-3 applications, but anything more than that would be a pain to work with. And then if you plan to put everything behind passenger, it would just be too messy. Think of automating this? Would be a nightmare to maintain. Over here containerization does help.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#245

Post by catern »

Nyetan wrote: post #238
kosma wrote: post #233

Earlier quoted context omitted.

Until a few days ago I was a DevOps engineer at a medium-sized tech company. My primary responsibility was dockerizing their applications and infrastructure. I quit the job. The scenario played out just as you said: I ended up single-handedly and poorly re-engineering something that already existed (they did have a working Ansible setup) for no visible gain. "Swimming in containers upon containers" is exactly what ha…

Bother you for a little advice? I'm working at a mid-sized tech company and am evaluating Docker for CI, testing and limited, internal deployment usages. The services in question are built with a hodge-podge of shell scripts and build tools, so getting them all to compile locally is a challenge, let alone deploying them. My hope was that containerizing the builds would isolate any configuration problems, and that con…

You don't need Docker to make a standard build environment. You don't need "chroot on steroids", you just need chroot.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#246

Post by theatraine »

jordanthoms wrote: post #239
iamleppert wrote: post #227

I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil. Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker. Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll…

I do agree with you, but we're on Heroku and that also has it's downsides - the biggest one we've found is that CPU performance on 1x and 2x dynos is very unpredictable - We've had to move to Performance dynos ($500/month each!) to get decent performance and prevent random timeouts. Services like Cloud66 are interesting (they manage deployments onto your own EC2 or other cloud infrastructure), but the developer exper…

Azure App Service (https://azure.microsoft.com/en-us/services/app-service/) is Azure's Heroku competitor. It's quite close in features and ease-of-use. Disclosure: I work for this team.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#247

Post by 2muchcoffeeman »

maratd wrote: post #139
dasil003 wrote: post #97

Earlier quoted context omitted.

There was also a time when most people thought they didn't need version control. Back in the 80s and 90s it was a justifiable viewpoint because existing version control systems sucked . The problem with Docker is not that it doesn't solve (or attempt to solve) widespread problems. At its best, Docker gives you dev/production parity, and dependency isolation which is useful even for solo developers working part-time.…

> At its best, Docker gives you dev/production parity I get that when I use the same OS and built-in package manager? I would virtualize the environment using something like VirtualBox for my dev and EC2/DigitalOcean/etc on prod. > and dependency isolation If you're going to scale something, you're going to split everything out on different virtualized servers anyway, so you'll get your isolation that way. Basically,…

To be fair, I've worked in places where all the devs were on the same OS, same version, and we still had problems.

But I agree, just use VirtualBox. I know Idea already supports deploying to VMs and you they just look like another machine, so no learning curve. All the benefits with none of the hassle.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#248

Post by rmgraham »

catern wrote: post #245
Nyetan wrote: post #238

Earlier quoted context omitted.

Bother you for a little advice? I'm working at a mid-sized tech company and am evaluating Docker for CI, testing and limited, internal deployment usages. The services in question are built with a hodge-podge of shell scripts and build tools, so getting them all to compile locally is a challenge, let alone deploying them. My hope was that containerizing the builds would isolate any configuration problems, and that con…

You don't need Docker to make a standard build environment. You don't need "chroot on steroids", you just need chroot.

I've found docker to be "chroot with all your custom fs layouts and custom mount scripts combined" - in other words a much more convenient chroot.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#249

Post by abrookewood »

danudey wrote: post #212
shawnee_ wrote: post #75

Earlier quoted context omitted.

Docker will likely be more prevalent in a few years with startups who have built their infrastructure form the ground up. The opposite seems likely ... Docker will fade and become deprecated as building infrastructure from the ground up locally to feed into the cloud becomes cheaper and cheaper still. AWS is not always so cost-effective when you truly dig in and crunch the numbers. My guess as to why Docker won't suc…

> AWS is not always so cost-effective when you truly dig in and crunch the numbers. If you have a consistent level of traffic (i.e. you don't have inordinately wild upswings/downswings like e.g. Reddit), AWS isn't even remotely cost-effective. I was going to do the math to compare our current physical server infrastructure with AWS, and even if you factor in that physical servers need to be in pairs (for redundancy)…

There's one clear cut use case where AWS/Azure are incredibly cheap - Disaster Recovery. At my last job, we maintained a small DB instance and nothing else but an empty VPC. Within 15 minutes, we could spin up the entire DR stack including resizing the DB to support Production. There's no equivalent for this when you ONLY run your own hardware - you're stuck with a second site that sits there idle (unless you intend to do Active-Active which has its own share of problems).

Re: Why Docker Is Not Yet Succeeding Widely in Production

#250

Post by Nyetan »

catern wrote: post #245
Nyetan wrote: post #238

Earlier quoted context omitted.

Bother you for a little advice? I'm working at a mid-sized tech company and am evaluating Docker for CI, testing and limited, internal deployment usages. The services in question are built with a hodge-podge of shell scripts and build tools, so getting them all to compile locally is a challenge, let alone deploying them. My hope was that containerizing the builds would isolate any configuration problems, and that con…

You don't need Docker to make a standard build environment. You don't need "chroot on steroids", you just need chroot.

I certainly could (and actually hadn't thought of doing that; the hype was really getting to me)! Part of the difficulty is in fixing the setup process, though, as over the years this system seems to have accrued a fair amount of -- shall we say -- character. Jumping in and fixing it up to the point of making environment setup a short, portable and error-free process (such as (1) pull a vm image (2) feed it a commit hash to build, test and deploy) would optimistically take weeks. This drove my desire to short circuit the entire affair and stick it all into a VM. That's what I was alluding to vis. proper solutions :)
Post reply on HN