Fred Wilson's response to "Paul Graham's Letter to YC Companies" - <AUTHOR> http://www.avc.com/a_vc/2012/06/some-perspective.html <comment><USER5> Personally I love to see Facebook's stock languish. Not because I dislike Facebook, but because it's great to see the market react rationally to an over-hyped tech stock.

FB is arguably the most hyped IPO in history. There was a blockbuster movie made about it. If ever there was a positive sign that we are not in a bubble, the poor performance of FB on the open market is it.

It's great to not be in a bubble. That means we won't wake up one day to discover it has popped. But to see the lack of a bubble on display so publicly has more important benefits. All the sub-par investors and entrepreneurs who flood the valley just to cash in on bubbles will be repelled.

<comment><USER6> The bubble isn't in valuations, which are reasonable. Rather, the bubble is in the high value that some very talented people are giving to subordinate positions in startups that "seem" cool, not based on business or career considerations, but irrelevancies like whether there's an XBox on site. They're doing themselves a disservice by taking positions that tout themselves as the "startup experience" but involve none of the investor contact, mentoring, or career development that they'd actually need in order to become founders for real (I.e. with enough contacts and resources to do it right and without risking personal financial ruin). They'd be better served if they took technical positions at more established and traditional companies, whether these be larger corporations or "lifestyle" businesses.

Of course, there are a lot of great startups out there, where a person can learn a lot very quickly, but those are not all of them and joining a company because "it's a startup!" is, without more knowledge, a bad idea.

That's the bubble I see: people taking jobs in dodgy startups for ridiculously low equity slices based on information that's either biased or only validated by the ridiculous echo chamber, thinking that their position as Employee #57 is going to make them real founder material in 8 months (because the CEO will just give them investor contact). It don't work that way.

<comment><USER7> > in order to become founders for real

The first 1000 people at Facebook are millionaires. [http://www.washingtonpost.com/business/technology/facebook-1...](http://www.washingtonpost.com/business/technology/facebook-1000-new- millionaires/2012/02/02/gIQAmr9GkQ_story.html)

Any early Facebook employee has both the money and the name brand to be a credible founder.

By contrast, have you founded a successful startup? Have you raised money from investors? If not, why would you feel qualified to offer advice on the matter?

<comment><USER6> Read the article. That 1000 figure is pure speculation. It might be that many, and it might not be.

Just being "early" at Facebook isn't enough to create credibility. A person also needs a track record of promotions. Millionaire or not, no one's going to fund someone who joined Facebook in 2007 and _didn't_ get promoted in the interim.

Startups are a lot worse than people assume when it comes to internal promotion. The selling point of a position at a startup is the ability to get in early and have promotions be "inevitable" with growth, but it's equally common that as the company needs to scale, it has to bring on more established people, and those people tend to want leadership roles if they are going to join.

It does sometimes happen that someone joins a startup out of college and is a VP within five years, but that's not the norm. Just as common is for a person to end up a "paper millionaire" but languish in vesting twilight, not getting the raises and promotions that would be available in a more stable company with a better sense of career development.

<comment><USER8> You didn't answer the question: By contrast, have you founded a successful startup? Have you raised money from investors? If not, why would you feel qualified to offer advice on the matter?

</comment></comment></comment></comment></comment><comment><USER9> I don't disagree with Fred Wilson, but I'm closer to pg's perspective on this. The bubble, to the extent that there was one, burst while we weren't looking.

Facebook's IPO is not really a huge issue in and of itself, and as Wilson points out the numbers they have are staggering. Other IPOs, like GroupOn's, have had similar issues and FB will probably look pretty awful by the time they reach the end of their lock-up period too. But this stuff is largely all indicative of market sentiment, and that's the issue.

People aren't necessarily disappointed with the performance of any of these companies, but they are getting very twitchy as investors. When people stop investing, and sentiment becomes increasingly bearish, it's like the tide going out and inevitably some boats will end up getting beached.

I know from companies attempting to raise capital in London right now that things have been difficult for a while now, and look set to get even more difficult (not that London is necessarily the greatest place for doing this, or a good barometer) - so those companies that have done decent rounds recently (HailO, BagThat, etc) will probably need to baton down the hatches somewhat, and those who were expecting to raise later this year / early next are probably in for a shock - a nasty one, if they can't operate without a raise (I know at least a couple of companies in that exact position).

</comment><comment><USER10> From what I understand, Facebook's main problem is a lack of a stable income source. It's becoming more and more apparent that advertising is not going to be the panacea that it was thought to be, what with numerous studies showing poor facebook ad performance and companies like GM pulling their facebook ad campaigns altogether. Sure, they booked $1B last quarter, but annualizing that number requires some confidence that they can pull that off regularly, and I don't think people have that confidence. As an investor, I'd be worried.

<comment><USER11> As much as I think FB's valuation was high, they have the advantage of having a Product That People Really Want. This means that they have a lot of room to adjust their business model (so long as they don't screw up the UX/product while at it).

Contrast this with GroupOn, whose product IS the business model...

<comment><USER10> Are you familiar with the following phrase?

> If you're not paying for it, then you're not the customer; you're the > product.

Facebook's product is it's database of user information. If the actual customers, which currently consist mostly of ad companies, aren't interested, then they have a serious problem indeed.

<comment><USER12> While there is a nugget of truth in that quote, it is also a vast simplification. There is a (somewhat) symbiotic relationship between FB, you, and FB's advertisers. If any one of them are abused too badly, the combined organism will die.

That means FB _has_ to create a product people are interested in using and has to protect their privacy _just_ enough while giving their advertisers what they need to successfully market products.

</comment></comment></comment></comment><comment><USER13> Investors will become more conservative and seek better deals for themselves. I don't think it's anything to do with Facebook. Facebook might just be the excuse they're looking for.

My unsolicited advice to all startups is to put your energy into the things which matter. Debating 3-6% more/less dilution with investors is not a good place to be investing your time and energy.

I suspect the companies who go into this bubble focusing on convertible notes and caps will be the companies who suffer most.

<comment><USER14> Negotiating with investors is somewhat like negotiating your salary after a job offer. The per hour ROI can be insane, but you need alternatives before you have real leverage and you want some deal to go though even if it's not with them.

</comment></comment><comment><USER15> Build something people want and will pay for. Stop worrying about Facebook and IPO's. Waste of time.

<comment><USER16> I see this attitude all the time in SV techies - lets just ignore the finance because its all chatter anyway. Frankly, this line of thinking is counter- productive and quite dangerous. Macro matters much more than slapping together some code to build widgets people will want & will pay for. For one thing, most of those people who want & will pay are getting their dough from boring non-tech ventures affected entirely by macro. When things head south, people will batten down the hatches. They will neither want nor pay for, because they simply can't afford to. All of this wanting and paying for is mostly discretionary spending driven by a upbeat macro signalled by IPO markets & especially FB. Once those signals flash red, the wallet stays shut. No more app store purchases, cloud drive subscriptions, ipads, servers, what-have-you. Huge giants ( Sun, SGI, Cray...) fell by the wayside because they collectively put their head down & built what they thought people would want & would pay for. People did want those things initially, but once the economy went into a tailspin, the dot in dotcom became the dot in dot-bomb. I still have those Sun tshirts proudly proclaiming our red hot dotness. I wear them on the weekends when I take out the trash. The kids snigger and say "dot in dot com...wtf ?" and I realize...yeah, wtf were we thinking.

<comment><USER15> Well our country and economy is already over inflated with debt, so it wouldn't be such a bad thing if discretionary spending halted.

really, would that be such a bad thing to the overall economy? People tightening their spending, instead of recklessly borrowing debt, and buying nice things that ultimately aren't necessary? I guess if you're a company that targets discretionary spenders, you're doomed.

<comment><USER16> > guess if you're a company that targets discretionary spenders, you're > doomed.

other than food clothes & shelter, everything in the world is by definition discretionary spending.

<comment><USER17> My medications are not optional.

</comment></comment></comment></comment></comment><comment><USER18> This is deceptive. The entire reason the late stage guys invested in higher valuations is because the early stage guys convinced them it was worth more.

You can't say before the IPO that the company is worth 75 B or 100B and then after the fact say it's their fault for investing at those valuations. That destroys the integrity of the silicon valley investment environment.

<comment><USER19> i am an early stage "guy" and I can assure you i never "convinced" a later stage investor of anything. they did all the convincing to themselves. it was like feeding pigs at a trough.

<comment><USER18> I don't think you directly told anyone that Facebook would be a $100B company. There are plenty of wall street analysts (like Lou Kerner from Wedbush, who called for $200B facebook) to do that dirty work.

But if some analysts are pumping Facebook and no one from the silicon valley is trying to temper expectations, people assume that the valley believes the same valuation numbers. The result is long-term damage to the credibility of SV and a contraction of the investment supply. After all, if someone comes up next year and describes DuckDuckGo as a $100B company, why would anyone believe the valuation? Everyone would point to Facebook and give it a much lower valuation even if it probably deserves a much higher one.

To make it clear, I think that this type of chicanery from wall street is scorned yet expected in the eyes of most people. We have all accepted the fact that they will pump stocks, especially at the top (<http://www.scribd.com/doc/86194691/Long-Good-Buy> was Goldman's paper which essentially gave a bullish case for equities at the top). But there is still some credibility lent to silicon valley, which people should not squander in the interest of one investment.

</comment></comment></comment><comment><USER20> "...the Facebook IPO will hurt the funding market for earlier stage startups. But no one knows yet how much. Possibly only a little. Possibly a lot, if it becomes a vicious circle." - PG [1]

"I think it will be particularly impactful on the late stage and secondary markets where most of the IPO valuation speculation is happening." - AVC [2]

We are now in a contracting market where funding for earlier stage startups, late stage and secondary markets is drying up.

AVC referenced PG's letter, but didn't address the letter. Now that we are in a post-frothy market and the froth is drying up, where does this leave early stage startups that are feeding the late stage startups with talent? It would be nice for AVC to address PG's letter directly and not just provide financial analysis to the Facebook valuation.

[1] <http://news.ycombinator.com/item?id=4067297>

[2] <http://www.avc.com/a_vc/2012/06/some-perspective.html>

<comment><USER21> > We are now in a contracting market where funding for earlier stage startups, > late stage and secondary markets is drying up.

Have some data for that assertion? PG's letter never said that. He just identified sentiment and provided warning advice. I think it's still too early to see if there is a material impact.

<comment><USER20> "Jessica and I had dinner recently with a prominent investor. He seemed sure the bad performance of the Facebook IPO will hurt the funding market for earlier stage startups." - <USER2>

What part of this is unclear? PG was sure enough to write a letter to the startups warning of the oncoming contraction. I am guessing the VC was someone of the caliber of Ron Conway.

I do not have data as data is a historical record (in this context), not a prediction of the future. This is why it is a warning of thing will come, but the question is HOW MUCH will the market contract, not IF if will contract.

"I think it's still too early to see if there is a material impact."

I believe this should read, "I think it's still too early to know the extent of the impact."

EDIT: I don't have any hard data, I am using PG and AVC to assert that what they say is true based on the information they know.

<comment><USER21> "He seemed sure" is not data.

You said "late stage and secondary markets is drying up." You need actual data (even if it is a few months old) to back that up.

What actually happened in the case of Facebook is that the price was run up so high on the secondary markets that the public markets missed out. That's not the same thing as drying up. It could lead to that in the future but I think it's still premature to say it is happening now (especially with no data).

</comment></comment></comment></comment><comment><USER22> My personal thoughts are that the greatest near term impact we'll see is in angel investment $$ in seed rounds. At least here on the East Coast there has been a boom of relatively unsophisticated Angels driven by hype. It is these individuals that, in my mind, will react more emotionally to a poorly performing Facebook IPO.

Not that one shouldn't be concerned about the broader venture market, but I'm a little less worried about the institutional money than I am about the Angels disappearing.

</comment><comment><USER23> I needed to google what EBITDA is in order to understand the artice. EBITDA means "earnings before interest, taxes depreciation and amortization" ([http://en.wikipedia.org/wiki/Earnings_before_interest,_taxes...](http://en.wikipedia.org/wiki/Earnings_before_interest,_taxes,_depreciation_and_amortization)). Id est, AFAIK, the money they get, without taking into account the money they spend because their "thigs" age.

I hope it helps fellow hackers who don't know finance (like me) to understand the article a little better.

Edit: Better explanation of what I mean by spend.

<comment><USER24> EBITDA is a form of profit. Whenever someone says they made X in profit - <USER3> should immediately ask what kind - net income, operating profit, etc. Depending on the business, different definitions of profit can produce wildly different numbers.

It's a generally accepted proxy for cash earnings since it looks at profit and takes out:

\- non-operating costs such as interest and tax. These are "non-operating" because they have nothing to do with delivering your service/product.

\- non-cash costs such depreciation and amortization.

It is worth noting that EBITDA is non-GAAP, which is to say that it's not an officially recognized accounting term. You won't see it in an audit and if you do there will be a big disclaimer next to it. The term gained popularity in the 80s with the rise of private equity. It's used in debt agreements to approximate how a business will pay back loan principal and interest.

</comment></comment><comment><USER25> "In its last quarter Facebook had $1bn of revenue and 40% pre-tax operating margins"

The key execs and advisors involved in IPO were not conservative with the valuation. Do not be surprised if those same biases influenced some of the pre-float numbers.

A cautious CFO may not always tell people what they want to hear short-term - but they will deliver a much stronger performance over the long.

</comment><comment><USER26> "But even at half those numbers there are fantastic returns for investors and entreprenuers to be had."

What about at 0.1% of those numbers?

Facebook (while it obviously has a ways to go on direct customer monetization), is an extreme outlier whose numbers across virtually any metric are far more extreme than most startups will ever come close to. IMO it is their outlier status combined with the lackluster performance relative to that status that is the killer.

Trying to anchor other startups to Facebook's numbers at something like "half" or even a "quarter" is kind of handwavey because a startup would have to be improbably, insanely successful just to get a small fraction of the userbase Facebook enjoys.

</comment><comment><USER27> I don't see why FB's IPO should be considered a failure, from the perspective of earlier investors. They sold stock at an IPO price even higher than the market could support. What's not to like?

Of course institutional IPO investors don't like it, because they want to buy stock at a discount and sell it with a big bump the next day. But the early investors are the losers in that scenario.

I guess you could argue that the IPO investors just won't play ball if they can't get their free money, but I think more likely they'll just be more careful about pricing next time.

<comment><USER28> I agree completely with your view, can someone explain to me why this is a bad thing?

</comment></comment><comment><USER29> From the article: "That means that Facebook's enterprise value is greater than 10x current revenue run rate and greater than 25x EBITDA. These are big multiples folks. I am happy to take those numbers for any company out there."

The bigger those multiples are, the more "overpriced" a company is, so it should actually be less attractive of an investment.

<comment><USER30> _The bigger those multiples are, the more "overpriced" a company is, so it should actually be less attractive of an investment._

Right. The OP is considering the situation as a seller, not a buyer. He would be overjoyed if everything he sells is overpriced similarly.

</comment></comment><comment><USER24> Despite market fluctuations, pundits and haters - there is an objective truth that Facebook's financial performance is exceptional.

Facebook full year 2011 EBITDA was roughly 55%, demolishing google's 37% and apple's 42%. Wilson approximates a 40% margin in Q1, but ad businesses tend to be Q4 heavy due to holiday shopping. Facebook has demonstrated exceptional leverage in its model.

Facebook has growing pains for sure, but that is likely a result of being the first to scale in its market.

Who knows what the market will do, the general sentiment here and in other places seems to be largely emotional and indicate that it will go down further. But even if you strip away Facebook's brand name and sexy market, the numbers are impressive and the business performs very very well.

<comment><USER31> The problem isn't that Facebook doesn't have earnings, but rather their incredible P/E ratio.

Also, the profit margin doesn't say much about a company that doesn't do much other than its core product, while Google and Apple have their hands in other products as well. If anything the chances for long-term survival look better for companies that diversify successfully and Facebook hasn't demonstrated an ability for that.

</comment></comment><comment><USER32> What is "enterprise value" and how does he come up with 43B?

<comment><USER33> _Enterprise value_ is

      market cap + debt - <USER4>

It reflects how much it would cost to buy a company out.

</comment></comment><comment><USER34> It seems to me this whole thing is more about sentiment than numbers. How it is perceived and the effects of that perception, rather than "does it add up"...

</comment><comment><USER35> What if the stock now bounces back? Nobody can deny that the company is generating some solid revenues with lots of potential. Investors might think this is really low valuation and we might see surge in buying.

(Disclaimer: I do not own FB stock and this is just my speculation)

<comment><USER36> I will deny that the company is generating solid revenues with lots of potential.

I don't see a lot of potential in Facebook. They're just another rung on the ladder of social network churn, and luck may have played strongly into that.

Facebook is generating revenue, but nothing I would consider 'solid' for a company with a ~85 billion market cap.

The company is incredibly overvalued, and time will show that to be the case.

</comment></comment><comment><USER37> I'm glad to see FB come down, just so I can invest on FB at reasonable price. As for FW he is right. FB used the hype to raise money at great valuation. If anything, there is now a lot of liquidity among potential investors.

</comment><comment><USER38> The Articles argument seems to be that FB got 10x revenues and if new startups got just half that it would be great

sadly that's a common fallacy on any business plan - the Market is x million and we could get 10% of that then ...

So what's a better argument?

</comment><comment><USER39> Did he just say, in very nice terms, that Facebook stock is still overvalued?

</comment><comment><USER40> Could somebody tell me what is Facebook's intrinsic value?

<comment><USER41> Several hundred million people are willing to invest a portion of their finite time every day visiting and interacting with content only available via Facebook. Winning people's attention is a zero sum game (if you gain it your competitors lose it) and attention is a scarce resource. The strong network effects of having all your friends in one place makes facebook's position very defensible. All that adds up to high intrinsic value.

</comment></comment><comment><USER42> I'm wondering about the "even at half those numbers" bit, if Fred actually thinks it will go that low.

</comment><comment><USER43> Great perspective on price. It is still a success, but perhaps also still overpriced.

</comment><comment><USER44> I don't really see the relation with the pg's letter unless facebook' ipo and valuation. It's interresting anyway.</comment>


How the Tesla Model S is Made - <AUTHOR> http://www.youtube.com/watch?feature=player_embedded&v=8_lfxPI5ObM

<comment><USER2> This is a great video. And the narrator's comments about it being the wave of the future aren't exaggerated in the least. The use of robots greatly improves the rate of manufacture as well as assuring consistent quality.

It's hard to be discouraged about American business when watching a video like this.</comment>


Fast Deterministic Selection [pdf] - <AUTHOR> http://erdani.com/research/sea2017.pdf <comment><USER2> > Floyd and Rivest created the randomized SELECT algorithm [12] in 1975. > Although further improved and benchmarked with favorable results by Kiwiel > [19], at the time of this writing we found no implementation available > online and no evidence of industry adoption.

A search for "floyd rivest select" found a few different implementations, like

\- [https://softwareengineering.stackexchange.com/questions/2847...](https://softwareengineering.stackexchange.com/questions/284767/kth- selection-routine-floyd-algorithm-489)

\- [https://github.com/mourner/quickselect/blob/master/index.js](https://github.com/mourner/quickselect/blob/master/index.js)

\- [http://dhost.info/zabrodskyvlada/3alg.html](http://dhost.info/zabrodskyvlada/3alg.html)

A while ago, I also found that [http://people.csail.mit.edu/rivest/pubs/FR75b.pdf](http://people.csail.mit.edu/rivest/pubs/FR75b.pdf) is a more easily implementable description of SELECT, and also that it was significantly faster (3-4x) than quickselect (with naive pivot selection) when benchmarking the two on random data.

<comment><USER3> There is also an implementation here:

[https://github.com/rauhs/fast-weighted-median](https://github.com/rauhs/fast- weighted-median)

In addition to a faster algorithm.

<comment><USER4> That one only seems to deal with the median, though.</comment></comment></comment>


C++ tricks - <AUTHOR> http://codeforces.com/blog/entry/15643

<comment><USER2> 'tricks' indeed. Don't get me wrong, if one is still stuck in the pre-C++-11 era this could open a lot of gates into unexplored yet exciting new territory and it does provide reasonable code samples, yet I wouldn't recommend this for learning C++ as it also introduces some bad habits. For example

\- in 1 all variable declarations and initializations are split. That seems to stem from pre-C99 and makes no sense, especially not when they are on consecutive lines anyway.

\- 3 'simply use #include <bits/stdc++.h>' No, don't do that. Instead properly learn what each header is for. Moreover it's not even a standard header so non-portable.

\- 4 'hidden functions' Again non-portable and doesn't have much to do with c++ anyway

\- '" \n"[j == m]' yes that's a trick to have save one line of code at the expense of being hard to understand and way more error prone

\- '#define mt make_tuple' why would you obscure your code like that by saving 8 or so characters

</comment><comment><USER3> >#include <bits/stdc++.h>

This is a very cool trick to turn your compile time from seconds to minutes.</comment>


So Called Women's Rights - <AUTHOR> http://micheleincalifornia.blogspot.com/2016/12/so-called-womens-rights.html <comment><USER2> I'm not quite sure what you're saying regarding career women being saddled with a heavy load of domestic work as well. You immediately follow that with a statement about American policies in general.

Were you implying that the division of domestic workload between husbands and wives should be treated as a matter of government policy?

<comment><AUTHOR> I am not politically oriented, but I was a homemaker and full time mom for a long time. To my mind, child bearing, child rearing and "women's work" generally are not readily and easily separable. I believe it makes more sense to treat women as, in a sense, handicapped (in the way that word gets used in horse racing: carrying extra weight) and help them carry that load. This has a better track record of getting more paritable outcomes than the American approach to this problem space.

I am interested in culture, not politics per se. But political policy grows out of culture. So if American culture changes in this regard, policy changes are likely to follow. But I do not have a political agenda per se.</comment></comment>


Why does MPAA approve both parties' stances on Internet freedom? - <AUTHOR> http://www.dailydot.com/news/sopa-chris-dodd-mpaa-internet-freedom/

<comment><AUTHOR> Obama responding on Internet Freedom question on Reddit: [http://www.reddit.com/r/IAmA/comments/z1c9z/i_am_barack_obam...](http://www.reddit.com/r/IAmA/comments/z1c9z/i_am_barack_obama_president_of_the_united_states/c60mlwx)</comment>


Ask HN: How do you use Docker in production? - <AUTHOR> I know what Docker is and how it works. What are some problems that get solved better when using Docker? <comment><USER2> Here's the problems we're solving with Docker:

* Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?"

* Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying what I want running across a cluster of machines, rather than procedurally specifying the steps to deploy something (e.g. Chef, Ansible, and the lot). There's been other attempts for declarative deployments (Pallet comes to mind), but I think Docker and Fleet provide even better composability. This is my favorite gain.

* Managing Cabal dependency hell. Most of our application development is in Haskell, and we've found we prefer specifying a Docker image than working with Cabal sandboxes. This is equally a gain on other programming platforms. You can replace virtualenv for Python and rvm for Ruby with Docker containers.

* Bridging a gap with less-technical coworkers. We work with some statisticians. Smart folks, but getting them to install and configure ODBC & FreeTDS properly was a nightmare. Training them in an hour on Docker and boot2docker has saved so much frustration. Not only are they able to run software that the devs provide, but they can contribute and be (mostly) guaranteed that it'll work on our side, too.

I was skeptical about Docker for a long time, but after working with it for the greater part of the year, I've been greatly satisfied. It's not a solution to everything—I'm careful to avoid hammer syndrome—but I think it's a huge step forwards for development and operations.

[1]: [https://coreos.com/using-coreos/clustering/](https://coreos.com/using- coreos/clustering/)

Addendum: Yes, some of these gains can be equally solved with VMs, but I can run through /dozens/ of iterations of building Docker images by the time you've spun up one VM.

<comment><USER3> In typical virtualisation + config management you specify a base image and bunch of config files and commands.

In a Dockerfile you specify a base image and commands, may often invoke a config management tool.

How is using Docker more declarative?

<comment><USER4> If you take the steps for, say, AWS, of building a new AMI for every role you have, then it's pretty much the same.

(but in my experience with building AMI's, that process is way too slow compared to Docker)

Docker becomes closer to declarative when you build static Docker images for every role _and rebuild for every change_ and re-deploy. Even more so when your deployment is based on a tool like Fleet that declaratively specifies your cluster layout.

The point is to avoid ever having situations where you say "install package foo on all webservers". Instead you say "replace all webservers with a bit-by- bit identical copy of image x".

The benefit is that you can have already tested a container that is 100% identical, and know that the deployed containers will be 100% identical, rather than hope the commands you pass to the config tool handles every failure scenario well enough.

<comment><USER5> I blogged on automating deployment to AWS with Docker here:

[http://zwischenzugs.wordpress.com/2014/08/09/using-shutit- an...](http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-and-docker- to-play-with-aws-part-one/)

[http://zwischenzugs.wordpress.com/2014/09/15/using-shutit- an...](http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-and-docker- to-play-with-aws-part-two/)

</comment></comment></comment></comment><comment><USER6> I used Docker to solve a somewhat unconventional problem for a client last week. They have a Rails application that needs to be deployed in two vastly different situations:

* a Windows server, disconnected from the internet

* about 10 laptops, intermittently connected to the internet

Docker let us build the application once and deploy it in both scenarios with much less pain than the current situation, which basically consists of script to git-pull and over-the-phone instructions when dependencies like ruby or imagemagick need to be upgraded.

We run VirtualBox with a stock Ubuntu 14.04 image with docker installed from the docker-hosted deb repo. We use the Phusion passenger Ruby image[1], which bundles almost every dependency we needed along with a useful init system so we can run things like cron inside a single container along with the application. This makes container management trivial to do with simple scripts launched by non-technical end users.

[1]: [https://github.com/phusion/passenger- docker](https://github.com/phusion/passenger-docker)

<comment><USER7> What value does Docker add if you are already running a VM? Are the laptops Linux, so Docker provides a lighter alternative to a full vm environment?

<comment><USER8> Docker also enforces immutability. With a VM there's always the temptation to manually fix any issue that arises, and if you don't have some bulletproof way to document that then you'll have issues when you go to recreate the environment on a new machine. Docker kind of forces you to solve the original problem via the dockerfile, which is what will spawn images for any future installs anyway.

<comment><USER9> Could you explain this more? I think my confusions stems from where the config comes from. Regardless of whether I have a bit-for-bit image or a vm created from a bunch of script commands, the immutability disappears when I apply the config.

So for my example If I have a role that specifies one instance of a a galera server. I have to config each one with the other servers in the pool. And each config will be dependent on the other server's config. So is Docker the first part (get the galera server instance running) and then there is some 2nd part that does the config so the instances in the cluster work together?

<comment><USER8> To your first question: for me it's a on-paper vs reality difference. On paper you're exactly right re "vm created from a bunch of script commands" will end in the same state.

The reality is that once the VM is built there is the temptation/opportunity to make ad-hoc changes for any variety of reasons. Those ad-hoc changes sometimes make it back into the official build process, but sometimes they get forgotten in the heat of the moment. With docker you can't do this...to make the necessary change you are also changing the official build process. No opportunity for the two to deviate.

Second question: Yes, that is my understanding (though not a use case I have atm).

</comment></comment></comment></comment></comment><comment><USER10> At Shopify, we have moved to Docker for deploying our main product. Primary advantages for us are faster deploys, because we can do part of the old deploy process as part of the container build. Secondly: easier scalability, because we can add additional containers to have more app servers or job workers. More info at [http://www.shopify.com/technology/15563928-building-an- inter...](http://www.shopify.com/technology/15563928-building-an-internal- cloud-with-docker-and-coreos)

<comment><USER11> wvanbergen, forgive me for veering off topic. I'm planning on applying to Shopify (Toronto) as a software developer before the end of the weekend. Any advice you're willing to share?

<comment><USER10> MattyMc: sure. Primarily: be yourself, show what you are passionate about, and be willing to adopt change. When applying: cover letter > resumé, and try to stand out because we get many applications. Email me at willem at shopify dot com if you have any specific questions.

<comment><USER11> Thanks so much Willem!

</comment></comment></comment></comment><comment><USER12> We've been using Docker for YippieMove (www.yippiemove.com) for a few months now, and it works great.

Getting your hand around the Docker philosophy is the biggest hurdle IMHO, but once you're there it is a delight to work with. The tl;dr is to not think of Docker as VMs, but rather fancy `chroots`.

In any case, to answer your question, for us it significantly decreased deployment time and complexity. We used to run our VMs and provision them with Puppet (it's a Django/Python app), however it took a fair amount of time to provision a new box. More so, there were frequently issues with dependencies (such as `pip install` failing).

With Docker, we can more or less just issue a `docker pull my/image` and be up and running (plus some basic provisioning of course that we use Ansible for).

<comment><USER13> how do you do restarts when you update the app ? I assume you have to take the app server out of the server pool (remove from load balancer or nginx) and shut it down, then docker pull your image.

I'm doing deploys with ansible and its just too slow

<comment><USER12> Actually, we have Nginx configured with Health Check ([http://nginx.org/en/docs/http/load_balancing.html#nginx_load...](http://nginx.org/en/docs/http/load_balancing.html#nginx_load_balancing_health_checks)). Hence, it will automatically take a given appserver out of the pool when it stops responding. Once the node is back again, Nginx will automatically bring it back into rotation.

Also, we actually use a volume/bind-mount to store the source code on the host machine (mounted read-only). That way we can roll out changes with `rsync` and just restart the container if needed.

The only time we need to pull a new update is if the dependencies/configuration of the actual container change.

<comment><USER14> How do you deal with connections that are in progress to the app server? If you just take it down, you're potentially throwing away active connections.

<comment><USER12> Yes, that's absolutely true and something we're aware of. It would of course be possible to solve, but would increase the complexity by a fair amount.

It is also worth mentioning that it is a more back-end heavy service, than front-end heavy. Since each email migration runs isolated in its own Docker container, a given customer can generate 100s of Docker containers.

Hence, given the relatively low volume of users on the web app, and the fast restart time, the chance of throwing away an active connection is relatively low.

<comment><USER13> ok thanks. I have several app servers and I take them out of nginx server list, stop it gracefully, git pull and configure (slow, I want to get rid of this step), put it back in nginx servers, move onto the next one.

tedious, although my whole deploy-to-all-servers is a single command.

<comment><USER12> Yeah, that sounds pretty tedious, but I guess it could still be automated (but somewhat tricky).

Once CoreOS becomes more stable, we're looking to move to it. The idea is then to use `etcd` to feed the load balancer (probably Nginx) with the appserver pool. That way you can easily add new servers and decommission old ones.

<comment><USER14> We automated this pretty trivially at my last job using Fabric[0]. All we had to do was cycle through a list of servers and apply the remove from LB, update, add to LB steps. Removing from the LB should simply block until connections drain (or some reasonable timeout). It makes deploys take longer for sure, but avoiding the inevitable killing of user connections was worth it.

[0] [http://www.fabfile.org/](http://www.fabfile.org/)

<comment><USER14> I will add that if you're using Docker (which we weren't) it might be easier to deploy a new set of Docker containers with updated code and just throw away the old ones.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Good question.

I have learnt enough about Docker to know it's not something which solves any problem I have, but finding out concrete facts about what others are actually doing with it was one of the hardest parts of the learning process.

The official Use Cases page is so heavily laden with meaningless buzzwords and so thin on actual detail that I still feel dirty just from reading it. [https://docker.com/resources/usecases/](https://docker.com/resources/usecases/)

<comment><USER16> I asked the same question a month ago:

[https://news.ycombinator.com/item?id=8324138](https://news.ycombinator.com/item?id=8324138)

Some of the answers are interesting. I agree with you that most of the companies they mention on their page are so big that it makes you think that Docker is a thing for big companies, and not relevant to what I do.

<comment><USER4> For my part, I use Docker for my personal home server to keep dependencies documented and keep everything cleanly isolated.

Currently I have 8 images running, and more sitting around that I spin up as needed, running everything from a minecraft server, to AROS (an AmigaOS re- implementation) , haproxy, a dev-instance of my blog, a personal wiki, my dev environment (that I use to run screen and ssh into for when I want to edit stuff - it bind mounds a shared home directory, but means I don't mess up to host server with all kinds of packages I decide to install).

It's gotten to the point where the moment I find myself typing "apt-get install" I pause to consider whether I should just put it in a Dockerfile instead. After all, if this is a package I'll need once, for a single program, the Dockerfile does not take much longer to write, and it saves on the clutter.

I have a draft blog post about how I'm using it I keep meaning to post - probably after the weekend.

</comment></comment></comment><comment><USER17> We're moving all of production in EC2 from an old CentOS 5 image managed by capistrano to CoreOS, with fleet deploying images built by the docker.io build service and private repo. I love it.

Every week, we rebuild our base image starting with the latest debian:stable image, apply updates, and then our apps are built off of the latest base image. So distro security updates are automatically included with our next deploy.

We had been deploying multiple apps to the same EC2 instances. Having each app's dependencies be separate from other apps has made upgrading them easier already.

This also means all containers are ephemeral and are guaranteed to be exactly the same, which is a pretty big change from our use of capistrano in practice. I'm hoping this saves us a lot of debugging hassle.

Instead of using ELBs internally, I'm using registrator to register the dynamic ports of all of my running services across the cluster in etcd, with confd creating a new template for NginX and updating it within 5 seconds if a service comes up or drops out. Apps only need to talk to their local NginX (running everywhere) to find a load-balanced pool of whichever service they are looking for. NginX is better than ELB at logging and retrying failed requests, to provide a better user-experience during things like deploys.

Some of these things could be solved by spinning up more EC2 instances. However that usually takes minutes, where docker containers take seconds, which changes the experience dramatically.

And I'm actually reducing my spend by being able to consolidate more. I can say things like "I want one instance of this unit running somewhere in the cluster" rather than having a standalone EC2 instance for it.

<comment><USER18> The biggest problem I have overall is pushing new code. When you push new code to git, do you then stop a container and restart it to get a new container working? (Assuming you do something like git clone in the Dockerfile)

<comment><USER17> I grant the docker.io build and private repository service access to my github repo, drop a Dockerfile at the root of my git repo, and the build server does the checkout outside of the Dockerfile and then executes the Dockerfile. I then use a github webhook to trigger a build when there's a new checkin to the master or qa branches. If the dockerfile completes successfully (based on exit status codes), it then spits out new docker images tagged with either "master" or "qa".

My fleet unit does a docker pull before it starts the container. So I just stop and start an individual unit to get it to run a new version.

Though fleet has a concept of global units (that run on all available machines), there's no way to do a rolling restart with them yet. Instead, I use unit templates to launch multiple instances of the same unit, and then stop and start each instance individually, and wait for it to respond before continuing to the next one. I intend to catch a webhook from the build server and do this automatically, but haven't written this yet.

</comment></comment></comment><comment><USER19> Docker, CoreOS, fleet, and etcd have completely changed how I build projects. It's made me much more productive.

I'm working on Strata, which is a building management & commissioning system for property owners of high-rise smart buildings. It's currently deployed in a single building in downtown Toronto, and it's pulling in data from thousands of devices, and presenting it in real-time via an API and a dashboard.

So in this building, I have a massive server. 2 CPUs, 10 cores each, 128GB of RAM, the works. It came with VMWare ESXi.

I have 10 instances of CoreOS running, each identical, but with multiple NICs provisioned for each so that they can communicate with the building subsystems.

I built every "app" in its own Docker container. That means PostgreSQL, Redis, RabbitMQ, my Django app, my websocket server, even Nginx, all run in their own containers. They advertise themselves into etcd, and any dependencies are pulled from etcd. That means that the Django app gets the addresses for the PostgreSQL and Redis servers from etcd, and connects that way. If these values change, each container restarts itself as needed.

I also have a number of workers to crawl the network and pull in data. Deployment is just a matter of running 'fleetctl start overlord@{1..9}.service', and it's deployed across every machine in my cluster.

With this setup, adding machines, or adding containers is straightforward and flexible.

Furthermore, for development, I run the same Docker containers locally via Vagrant, building and pushing as needed. And when I applied for YC, I spun up 3 CoreOS instances on DigitalOcean and ran the fleet files there.

As I said, I've been able to streamline development and make it super agile with Docker & CoreOS. Oh, and I'm the only one working on this. I figure if I can do it on my own, imagine what a team of engineers can do.

Very powerful stuff.

<comment><USER20> > They advertise themselves into etcd, and any dependencies are pulled from > etcd. That means that the Django app gets the addresses for the PostgreSQL > and Redis servers from etcd, and connects that way. If these values change, > each container restarts itself as needed.

Could you explain a bit more how that works?

<comment><USER19> Take Postgres for example. I use the official Docker image, and run it via a fleet .service file, having it store its data in a Docker data-only container, also launched from a fleet unit file. Finally, there's a third unit file that runs a slightly customized version of the docker-register image from CoreOS's polvi. This Dockerized app polls the Docker socket every 10s or so to get the IP and port information for the Docker container it's monitoring, in this case Postgres. It PUTs this value into etcd.

Afterwards, when my Django containers start, they pull their configuration from etcd using python-etcd. It will get the IPs and ports for the services, including Postgres, from etcd, and configure itself using that. Finally, it will keep these values in a dictionary. If these values ever differ from what's currently in etcd, then my Django app will send a signal to cause uwsgi to gracefully restart the Django app, so that it can reload itself with the new configuration.

For other Dockerized apps like nginx, I use kelseyhightower's confd-watch to monitor the etcd keys I'm interested in. confd-watch is great because it will use golang's text/template package to allow me to generate configuration files, like nginx.conf, with the values from etcd. So as these values get updated, so will nginx as confd-watch will force a graceful reload.

Hope that helps.

<comment><USER21> "If these values ever differ from what's currently in etcd, then my Django app will send a signal to cause uwsgi to gracefully restart the Django app, so that it can reload itself with the new configuration"

You could probably avoid the restart/reload by using skydns ([https://github.com/skynetservices/skydns](https://github.com/skynetservices/skydns)), it is a local dns service built on top of values in etcd. You can configure your django app to access the other service containers by dns name and it will be translated to the correct ip all the time.

</comment></comment></comment></comment><comment><USER5> This site:

[http://themortgagemeter.com/](http://themortgagemeter.com/)

is completely dockerized, and rebuilds from scratch daily (phoenix deployment).

I've written a few blogs on this:

[http://zwischenzugs.wordpress.com/2014/06/07/phoenix- deploym...](http://zwischenzugs.wordpress.com/2014/06/07/phoenix-deployment- with-docker-and-shutit/)

[http://zwischenzugs.wordpress.com/2014/07/16/phoenix- deploym...](http://zwischenzugs.wordpress.com/2014/07/16/phoenix-deployment- pain-and-win/)

The tool I talk about there is here:

[http://ianmiell.github.io/shutit/](http://ianmiell.github.io/shutit/) [https://github.com/ianmiell/shutit](https://github.com/ianmiell/shutit)

I've also used Docker to provision AWS:

[http://zwischenzugs.wordpress.com/2014/08/09/using-shutit- an...](http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-and-docker- to-play-with-aws-part-one/)

[http://zwischenzugs.wordpress.com/2014/09/15/using-shutit- an...](http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-and-docker- to-play-with-aws-part-two/)

</comment><comment><USER22> We're using Docker to solve these kinds of problems:

\- Running Jenkins slaves for some acceptance/integration tests that runs in the browser, previously we had to configure multiple chromedrivers to spin up on different ports or be stuck running 1 test per machine. Now we have 6 machines (down from 9) which runs 6 slaves each, so we can parallelize our tests as 36 tests run concurrently. That has significantly improved our deployment time (as these tests are necessary to do a deployment) while reducing costs.

\- Migrating our infrastructure (around 70 instances) to AWS VPC, we had our machines running on EC2-Classic. While I had previously done some work automating most applications using Chef we have really managed to fully automate our machines with Docker, it was way easier than solving cookbook dependency and customization issues. We have a couple dozen Dockerfiles that fully explain how our systems run and what are the dependencies for each application.

And that is only in the last month and a half that I began using Docker, I was pretty skeptical before as it was touted almost as a silver bullet. And it comes close to that in many scenarios.

<comment><USER5> Interesting, we've been using docker containers as Jenkins slaves, dependencies managed using ShutIt.

</comment></comment><comment><USER23> I honestly find it really depressing to see all these folks taking code and applications that would otherwise be entirely portable, and rebuilding their entire deployment and development environment around a hard dependency on Linux.

If Docker becomes sufficiently popular, it's going to put HUGE nails in the coffin of portability and the vibrancy of the UNIX ecosystem.

<comment><USER24> It is not a code portability issue - it is a configuration and environment and dependency volatility issue. Everyone can use cross compilable C and still have deploy and lifecycle headaches.

</comment></comment><comment><USER25> We use docker for:

\- running graphite (can't say it was less pain launching it, since Dockerfile was outdated a bit, and I also had to additionally figure out persistency issues, but overall I'm happy it's all virtualized and not living on server itself)

\- building our haskell projects for specific feature (your run a container per feature, this way you omit pain switching between features when you need to build one)

\- running tests (per each feature we start container with whole infrastructure inside (all databases, projects etc.))

\- running staging, also container per feature

Very useful stuff, comparing to alternatives, I should say. And quite easy to work with after you play a bit with docker's api.

<comment><USER26> So you're using containers in only staging? I can see why it would be appealing, but have you run into complications with staging being structured so differently from production?

<comment><USER25> I had no problems with staging being different than production (which is kind of multi-machine multi-environment rather than "everything in one docker"), because it all uses same fabric scripts and supervisor configs for deploy and maintainance.

</comment></comment></comment><comment><USER27> We use it for everything.

We use the Google Compute Engine container optimised VMs, which make deployment a breeze. Most of our docker containers are static, apart from our application containers (Node.js) that are automatically built from github commits. Declaring the processes that should run on a node via a manifest makes things really easy; servers hold no state, so they can be replaced fresh with every new deployment and it's impossible to end up with manual configuration, which means that there is never a risk of losing some critical server and not being able to replicate the environment.

</comment><comment><USER28> Docker revolutionized our server deployment. My company has 50 nodejs services deployed on VPS providers around the world. It allows us to completely automate the deployment of these servers regardless of the provider's APIs. When we roll out updates, we never patch a running box, we just bring the new container up and remove the old one. Super easy, super reliable, and best of all, totally scriptable.

We also have a pretty sophisticated testing environment using Docker which creates a simulation of our server in on any developer's laptop. It's really remarkable actually.

</comment><comment><USER29> We have a stateless worker process that previously required a separate EC2 instance for each worker. Even using small instances, this meant a pretty cumbersome fleet in AWS with lags for spin up and excess costs due to workers that were brought online and finished their jobs well before the use hour was complete.

Using Docker, we can have several of these workers on a single box with near instantaneous spin up. This means that we are able to use fewer, larger instances instead of several small ones. In turn, this makes the fleet easier to manage, quicker to scale and less costly because we aren't over paying for large portions of AWS hours that go under utilized.

I am not entirely sure that Docker was a necessity in building this as I sort of inherited the technology. I originally was pushing for a switch to pure LXC, which would have fit the build system that was in place better. However, given the fervour over Docker there is a lot of information out on the web and so changing the build and deployment systems has been relatively easy and quick. I bring this up because I think some tasks are better suited to pure LXC, but people seem to be defaulting to Docker due to its popularity.

</comment><comment><USER30> We actually started using Docker a few months ago and it really sped up our deployment process. It's not only incredibly faster than using virtual machines for testing; it allows you to host multiple apps on one server and to have all versions of your app ready to download and run. More info at [http://www.syncano.com/reasons-use-docker/](http://www.syncano.com/reasons- use-docker/)

</comment><comment><USER31> We use docker extensively to ship a large and complex legacy platform that was designed to run as a hosted service, but was transformed into an on-premise product.

The system is composed of several components originally designed to run on separate VMs for security reasons. Luckily, we were able to translate VM <-> docker container, so now each component has its own Dockerfile + shell script for booting up and providing runtime configuration.

Docker helps us solve several problems:

* A canonical build. It provides a way to configure the build system, fetch all dependencies and execute a reproducible build on different machines/environments. It's also used as documentation when engineers have no clue, where settings/parameters come from.

* A super fast build pipeline and release repository. We use maven -> nexus, docker -> docker-registry, vagrant -> local export for a completely automated way to bootstrap an ovf-file that can be deployed at customer site. Releases for the old platform were not automated and took the previous teams weeks (!) on a single platform.

* A way to restrict resources. Given some security constraints from the product, lxc + docker helps us restrict memory and networking.

* Shipping updates. We deliver automated updates through a hosted docker registry for customers who open up the appliance to the internet. Previous teams were not able deliver updates in time for a single hosted platform. We can now ship new releases and have them deployed at several customers data-centers in a matter of hours.

We have been using docker in production for almost a year now and despite headaches in the beginning it's been absolutely worth it.

</comment><comment><USER32> One thing I'd like to point out are OS upgrades, security patches or generally package updates. With docker I just rebuild a new image using the latest ubuntu image (they are updated very frequently), deploy the app, test and then push the new image to production. Upgrading the host OS also is much less of a problem because far fewer packages are installed (i.e. it's just docker and the base install).

<comment><USER33> But then you have many more docker images for different kinds of services that you all have to rebuild, no? Or do you just have one docker image?

And out of curiosity: is your testing of new images automated?

<comment><USER32> We have many images, and we build them in a CI setup using jenkins. I used to run jenkins inside docker and build images within that docker, but this turned out to be a problem. (Mainly more and more resources were used up until the disk was full.) Now it's just jenkins installed on the host building images, starting them and run integration tests.

</comment></comment></comment><comment><USER34> At Lime Technology, we have integrated docker into our NAS offering along with virtual machines (KVM and Xen). Docker provides a way to eliminate the "installation" part of software and skip straight to running proven and tested images in any Docker environment. With Containers, our users can choose from a library of over 14,0000 Linux-based apps with ease. Docker just makes life easier.

<comment><USER35> I'm a big fan of lime :). Nice to see you out in the wild like this.

</comment></comment><comment><USER36> I'm solving the most obvious issues that docker was meant to solve. I'm currently working alone in a company that's starting up and yesterday I needed to spin up a server and create a rest api service to integrate with a telco's system. They asked me how long it would take me to do that and I said an hour. I just spun up a digital ocean instance, cloned my api git project, built from the docker file (it's incredibly fast on ssd), and in about 30 minutes I was running a nginx->uwsgi->flask with python3.4, bcrypt, and a few other packages.

Now all this can be done with a simple bash script too but then that affects my main server environment. In this case when I want to stop the service or change something I simply edit my docker image.

My dev environment is a windows laptop and I use vagrant to spin up a server with nginx configured and docker installed. And I use docker to get my environment running for working on my apps. It's pretty awesome.

Vagrant and docker are one of the best things that has happened for me as a developer.

</comment><comment><USER37> We're using Docker for a few internal projects at Stack Exchange. I've found it to be simple and easy, and it just works.

We have a diverse development team but a relatively limited production stack - many of our devs are on Macs (I'm on Ubuntu), but our servers are all Windows. Docker makes it painless to develop and test locally in exactly the same environment as production in spite of this platform discrepancy. It makes it a breeze to deploy a Node.js app to a Windows server without ever actually dealing with the pain of Node.js on Windows.

Also, it makes the build process more transparent. Our build server is Team City, which keeps various parts of the configuration in many different hidden corners of a web interface. By checking our Dockerfile into version control much of this configuration can be managed by devs well ahead of deployment, and it's all right there in the same place as the application code.

</comment><comment><USER38> Since we are still waiting for CoreOS + (flynn.io || deis.io) to mature. I modified our existing VMWare VM based approached to setup ubuntu boxes with Docker install. Where I then use fig to manage an application cluster, and supervisor to watch fig.

When its time to update a box, jenkins sshs in calls docker pull to get the latest, then restarts via supervisor. Any one off docker run commands require us to ssh in, but fig provides all the env settings so that I don't have to worry about remembering them. The downtime between upgrades is normally a second or less.

The biggest thing I ran into is that each jenkins builds server can only build and test one container at a time. After each one, we delete all images. The issue is that if you have an image it wont check for a new image. This applies to all underlaying images. We cut the bandwidth by having our own docker registry that acts as our main image source and storage.

</comment><comment><USER39> We use Docker to deploy on Aptible, and this makes our projects entirely self- contained. With a Dockerfile in the project directory, the entire build and runtime environment is now explicitly declared.

With "git push aptible", we push the code to the production server, rebuild the project, and run it in one command.

<comment><USER40> Can you elaborate on the middle bits? How do you go from 'git push aptible' to the actual execution of the docker commands on the production server? (Setting up something similar myself and would love some direction).

<comment><USER41> You can use a git post-receive hook. See here for a similar example:

[https://github.com/nathanleclaire/laraveldocker/blob/master/...](https://github.com/nathanleclaire/laraveldocker/blob/master/hooks/post- receive)

</comment></comment></comment><comment><USER42> Docker explicitly violates the principles of the Twelve-Factor App. Docker apps don't rely on any external environment. In fact, Docker demands that you store all config values, dependencies, everything inside of the container itself. Apps communicate with the rest of the world via ports and via Docker itself. The trade-off is that apps become a little bit bulkier (though not significantly), but the benefit is apps become maximally portable.

In essence, Docker makes almost no assumptions about the app's next home. Docker apps care about where they are even less than twelve-factor apps. They can be passed to and fro across servers—and, more importantly, across virtualization platforms—and everything needed to run them (besides the OS) comes along for the ride.

<comment><USER41> Very good points, and as the author here ([http://blog.lusis.org/blog/2014/06/14/paas-for- realists/](http://blog.lusis.org/blog/2014/06/14/paas-for-realists/)) points out:

> I should state up front that I disagree with quite a few bits of the 12 > Factor model. It's important to remember that, imho, the 12 Factor model was > designed as a business strategy for Heroku. The steps follow exactly what > makes an app work best on Heroku, not what is best for an application.

</comment></comment><comment><USER43> Satoshilabs use Docker to build firmware for Trezor, allowing people to do the same and verify binaries.

[https://groups.google.com/forum/#!topic/trezor- dev/5MCyweTY4...](https://groups.google.com/forum/#!topic/trezor- dev/5MCyweTY4UA)

</comment><comment><USER44> We're using docker in part to get round the old 'works on my machine' problem: [http://www.rainbird.ai/2014/08/works- machine/](http://www.rainbird.ai/2014/08/works-machine/)

</comment><comment><USER45> One of the main things I'm using it for are reproducible development environments for a rather complex project comprising nearly ten web services.

We have a script that builds a few different docker images that the devs can then pull down and get using straight away. This is also done through a dev repo that they clone that provides scripts to perform dev tasks across all services (set up databases, run test servers, pull code, run pip etc.).

It used to take a day to set up a new dev enviroment, now it takes around 30 mins and can be done with almost no input from the user and boils down to: install docker, fetch databases restores, clone the dev repo, run the dev wrapper script

<comment><USER46> This is approximately what I'm using it for too. I'm working on my MSc, and I'm using it to make reproducible experimental environments. Packages locked to specific versions, all required libraries installed, isolated from the rest of the system. Working pretty well in that capacity!

</comment></comment><comment><USER47> We're been using Docker and coreos+fleet for our production environment at GaiaGPS for a few months now, and have been very impressed. We use quay.io for building our repositories, triggered by a github commit.

I agree with what others have said, and for us, the biggest benefit we see is keeping our production environment up to date, and stable. We're a small shop, and want to waste as little time as possible maintaining our production environment. We were able to go from 1 host (that occasionally went down -- and downtime for every deploy) to a 3-node coreos cluster fairly easily. We can also scale up, or even recreate the cluster, very easily.

</comment><comment><USER48> At Shippable(shippable.com) we've been using docker for over an year now for the following use cases:

1\. deploying all our internal components like db, message queue, middleware and frontend using containers and using a custom service discovery manager. The containerization has helped us easily deploy components separately, quickly set up dev environments, test production bugs more realistically and obviously, scale up very quickly.

2\. running all the builds in custom user containers. This helps us ensure security and data isolation.

We did run into a bunch of issues till docker was "production-ready" but the use case was strong enough for us to go ahead with it

</comment><comment><USER49> I've used docker for process isolation at two companies now. In both cases, we were executing things on the server based on customer input values, and desired the isolation to help ensure safety.

In the first company, these were one-off import jobs that would import customer information from a URL they provided.

In the other, these are long-running daemons for a multi-tenant service, and I need to reduce the risk that one customer could exploit the system and disrupt the other customers or gain access to their data.

I have some other experiments in play right now in which I am packaging up various services as docker containers, but this is currently non-production.

</comment><comment><USER50> Deployment. We have a legacy application that would take about a day of configuration to deploy properly. With Docker (and some microservices goodness) we've reduced the deploy down to an hour, and are continually improving it.

</comment><comment><USER51> We are running our app[1] in instances of Google Compute Engine. We installed Docker in those instances.

Our app is a bunch of microservices, some Rails Apps each one running with Puma as webserver, HAProxy, some other Rack app (for Websockets). We also use RabbitMQ and Redis.

All the components are running in their own containers (we have dozens of containers running to support this app).

We choose this path because in case of failures, just 1 service would be down meanwhile the whole system is nearly fully functional. Re-launching a container is very straightforward and is done quickly.

[1]: [https://dockerize.it](https://dockerize.it)

</comment><comment><USER52> We use docker at stylight for deploying our frontend app (wildfly). We use the docker hub for storing images. When we do a release we basically push to the hub, pull on all upstreams and restart the containers with the new image. We have a base application image (containing java, wildfly etc.) which basically never changes so builds and distribution are super fast. We really like the fact that the containers are isolated! We ran into an issue the other day where we wanted to dump the heap of the JVM to debug some memory leak issue, this should be easier with 1.3!

</comment><comment><USER53> We are a small startup and host on Softlayer (we are part of their startup program).

I would postulate this - if you are using AWS, you will not need a lot of what Docker provides. But if you are hosting your own servers, then Docker provides close-to-metal performance with stateless behavior.

For example, when Heartbleed or Shellshock or POODLE hit the ecosystem, it took us 1 hour to recreate all our servers and be compliant.

My biggest complaint and wishlist is for Docker to roll-in Fig inside itself. The flexibility to compose services/stacks is very useful and Fig claims to be too closely tied to Orchard.

</comment><comment><USER54> Not technically in production yet, but I use Docker for the following scenarios:

\- Build agents for TeamCity, this was one of the first scenarios and it's been amazingly helpful so far.

\- Building third-party binaries in a reproducible environment

\- Running bioinformatics pipelines in consistent environments (using the above tools)

\- Circumventing the painfully inept IT department to give people in my group easy access to various tools

I've also been contemplating building a Docker-based HPC cluster for a while now, though unfortunately I'm currently lacking support to make that happen.

<comment><USER55> > \- Build agents for TeamCity, this was one of the first scenarios and it's > been amazingly helpful so far.

Can you expand on what you've done with them and how it's been helpful?

<comment><USER54> The image basically contains (on top of the TeamCity agent itself of course) all the required dependencies. These dependencies are built in exactly the same way (and in the same context) as the ones used for running the code itself (i.e. after building/testing). This basically ensures that the code consistently runs in the same conditions.

Using Docker for this also means I can roll out the agents rather painlessly across a variety of machines. For instance, we have some pretty serious hardware used for HPC and similar stuff, so whenever possible I like running builds on that, since it takes a fraction of the time it would on the more common hardware. Sometimes however those machines aren't available for a number of different reasons, so I can very quickly move my build agents to another machine, or better even, multiple machines.

<comment><USER55> Very cool, thanks!

</comment></comment></comment></comment><comment><USER56> At Pusher we use Docker for CI.

I've developed a little command-line tool ([https://github.com/zimbatm/cide](https://github.com/zimbatm/cide)) that can run the same environment on the developer machine and Jenkins. It also makes the Jenkins configuration much easier since build dependencies are all sandboxed in different docker boxes. The tool is mainly for legacy apps and is able to export artefacts back to Jenkins instead of publishing Docker images.

</comment><comment><USER57> I've used Docker in semi-production environments.

Configuration abd dependency management is much improved, and more efficient than VMs.

YAML configuration is easy to hand edit.

Docker doesn't have to rebuild an entire image for a minor application code or conf change. Incremental cache speeds up the build process.

Scaleout with "worker" instances is quite easy to manage.

For full production Elastic Beanstalk is worth a look. I prefer to host on DigitalOcean VMs for dev staging.

Docker has a great local community in San Francisco.

</comment><comment><USER58> Created own tool for this: [https://mcloud.io](https://mcloud.io).

Cool thing about this, you don't need to change anything in config when deploying. \+ it follows docker's best practices like one process per container.

Already can't imagine I will deploy something without it. It's OpenSource (MIT, contributions are welcome) and current functionality will stay free forever.

Hope will be useful for somebody, not only for our team.

</comment><comment><USER59> I recently 'Docker-ized' [http://greptweet.com](http://greptweet.com) with [https://github.com/kaihendry/greptweet/blob/master/Dockerfil...](https://github.com/kaihendry/greptweet/blob/master/Dockerfile)

The main thing I really like is that Dockerfile. So if Greptweet needs to move, it's a `docker build .` to setup everything on a CoreOS VPS.

</comment><comment><USER60> At UltimateFanLive we use docker on Elastic Beanstalk to speed up the scaling process. Our load goes from 0 to 60 in minutes, as we are connected with live sports data. Packages like numpy and lxml take way too long to install with yum and pip alone. So we pre-build images with the dependencies but we are still using the rest of the goodies on Elastic Beanstalk. Deploy times have plummeted and we keep t2 cpu credits.

<comment><USER61> FYI, the download link has an unknown character before it. Win 7, Chrome 37.

</comment></comment><comment><USER62> We use Docker to set up our testing environments with Jenkins and install the application in it. Every build will be installed in a Docker Container automatically. The Container is used for acceptance tests. The Docker Containers are set up automatically with a Dockerfile. Its an awesome tool for automatating and deployment and used to implement the concepts of "Continuous Delivery".

</comment><comment><USER63> I'm considering Docker for a small side project I have where I want to deploy a Runnable Java Jar as a daemon. Getting Java paths right across different Linux distributions can be a hassle, hoping Docker will help me solve this. For that matter, getting a daemon (service) running correctly on different Linux'es is one more thorn I'd rather not have to deal with.

<comment> chroem- So you're going to add a whole virtualization layer instead of just using "java -jar myapp.jar &"? Sorry, but what?

And what do you mean about getting class paths right? Somehow I don't think best practice Java development necessarily calls for virtualization.

<comment><USER64> Docker is not a virtualization layer.

<comment> chroem- >Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating system–level virtualization on Linux.

<comment><USER65> Docker is based on LinuX Containers (LXC), which are much more lightweight than a full OS VM. Containers are basically namespaces for processes, networks so I would expect way lower overhead than a full fledged VM.

More details here - [http://stackoverflow.com/a/16048358/803923](http://stackoverflow.com/a/16048358/803923) [http://blog.dotcloud.com/under-the-hood-linux-kernels-on- dot...](http://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud- part)

It is a virtualization layer, but not nearly as heavyweight (and perhaps not as well isolated) as a full VM. As to the isolation - I don't know how "good" it is, but I expect it will only get better. I think this is what PG means by "do things that don't scale".

<comment> chroem- But for the case of deploying Java applications, it seems particularly redundant. The JVM already has a very extensive security manager framework, and since it's Java it's already write once run everywhere. You can even easily bundle your entire project into a single executable .jar for deployment.

As a Java developer, I can't fathom why someone would want to add a redundant layer of cruft on top of their project. Docker may be the latest trendy thing, but it seems like many of its users aren't entirely sure why they need it.

Edit: I should clarify that I have nothing against hypervisors or other virtualization and sandboxing schemes. However, a lot of people seem to be running Docker, under an outside hypervisor, in order to run their also virtualized language runtime. That strikes me as a bit pointless.

<comment><USER63> It's the daemonizing part that complicates things. Running java -jar MyApp.jar is easy, running it under the control of a system init script, dealing with how to ensure it's restartable as other daemons, logging, log rotation, where Java is really located on the system are all variables that affect any daemonized application; not just Java apps but ones written in any language, Ruby, Python, C or C++.

Docker seems like a good way to "contain" the problem domain challenges I outlined, hoping anyway.

</comment></comment></comment></comment></comment></comment></comment><comment><USER66> I don't know if docker would be the right service for my use case, but considering the user experience on this thread I thought I'd ask...

I'm looking to deploy a python based analytics service which runs for about 12 hours per job, uploads the results to a separate server then shuts down. At any given time there could be up to 100 jobs running concurrently.

Is this 'dockable' ?

</comment><comment><USER67> It seems like a bunch of people are using docker + CoreOS, is anyone using Docker with Marathon in production?

</comment><comment><USER68> We use docker at [https://cloudfleet.io](https://cloudfleet.io) to separate the application logic from the data and create a simple interface for additional apps.

As we deploy on low power devices the minimal overhead of docker is crucial for us.

</comment><comment><USER69> Dokku is a great way to move off Heroku and onto something way more cost effective and useful: [http://quaran.to/blog/2014/09/09/dynos-are- done/](http://quaran.to/blog/2014/09/09/dynos-are-done/)

</comment><comment><USER70> Most people seem to be using Docker with distro-based images, ie. start with ubuntu and then add their own app on top etc. Is anyone using more application-oriented images, ie. start with empty image and add just your application and its dependencies?

<comment><USER17> I'm doing this, but starting with the minimal 80MB debian:stable image and then using apt-get to grab my dependencies. The 80MB covers the dependencies for apt-get.

I believe the centos images are also minimal, but the ubuntu image starts out much larger.

</comment></comment><comment><USER71> I've used to to make an Ubuntu packaged app available on CentOS machines. The compile-from-source was a bit of a headache (lots of dependencies which also had to be compiled from source) so being able to deploy like this saved a lot of hassle.

</comment><comment><USER72> Right now, SFTP as a service ([https://github.com/42technologies/docker-sftp- server](https://github.com/42technologies/docker-sftp-server))

I also used it when our landing page was wordpress-based.

</comment><comment><USER73> we use docker to run tests, honestly we could deploy the resulting images to our production infrastructure now quite happily however we haven't got round to it yet.

</comment><comment><USER74> I'm really interested in using Docker but I'm having trouble understanding how to manage stateful applications, like databases.

<comment><USER32> There are two ways:

1\. You run the db and its files inside a container and regularly export a DB dump like so (example for postgres):

docker run --volumes-from db -v $(pwd):/backup ubuntu:trusty sh -c "cd /var/lib && tar zcvf /backup/backup.tgz postgresql"

(I don't recommend this)

2\. You run the db inside a docker container and mount a volume for /var/lib/postgresql into docker. This I find is the best way. the db files remain on your host and you can easily maintain the DB (runtime) and files separately.

Adjust to whatever DB you're using.

</comment></comment><comment><USER75> I'm running firefox in docker right now using subuser[1].

[1] [http://subuser.org](http://subuser.org)

<comment><USER76> Wasn't aware anyone had done this with docker. Going to give this a try. It would be a nice way of running some software.

</comment></comment><comment><USER77> I use it to grade homeworks, no more open TCP sockets, message queues, open files, some naughties trying to delete my home.

<comment><USER78> Docker is not safe for untrusted code. If the client can get local root privileges (e.g. CVE-2014-4699, CVE-2014-4014, CVE-2014-0196, unix-privesc- check, many more) they can then escape the docker container.

But it's definitely better than running as your own user!

<comment><USER77> Yes, I am aware, they are run in non root users.

</comment></comment></comment><comment><USER79> How do you make a database run on multiple containers and get redundancy with something like postgresql?

</comment><comment><USER80> with chef [https://docs.getchef.com/containers.html](https://docs.getchef.com/containers.html)

<comment><USER81> It's interesting to hear people are using this. Stories would be great!

</comment></comment><comment><USER82> Using Docker for hands on workshops:

next.ml

</comment><comment><USER83> Not yet .

</comment><comment><USER84> I'd be interesting in hearing about others production use case scenarios.</comment>


Show HN: JSPkg.com - host javascript packages (like gemcutter for js) - <AUTHOR> http://jspkg.com/

<comment><AUTHOR> I'll try to keep this short, since I'd like to get people's first impressions from the site itself, but I'll give a little background. I started building this in May. Since plugins.jquery.com was shut down a week and a half ago, I pushed it live so I could have somewhere to host my own plugins.

Even though it's smart enough to single out jquery plugins and label them as such, my stance is that all plugins are just scripts with a dependency on some library. So this site is meant to be a host for ALL javascript projects, whether they're libraries, frameworks, plugins, or standalone scripts, and whether they're front-end or back-end.

It follows the CommonJS spec for reading data from a package.json file, but also provides on-the-fly creation for projects that don't have one (with a package.json generator).

Any and all feedback welcome. For the curious, it's a Rails 3.1 app with a js- heavy front-end (being on the jquery-rails / jquery-ujs team, it's what I know best), though I've been considering switching the package uploader and processor mechanism to node.

<comment><USER2> What would be awesome of you is to generate a .js instead of a zip.

For example I could include <script src="jspkg.org/coffeescript/xregexp/.../.js"> and it would make a single .js file with all the dependencies sorted out.

If you could make it work with npm packages that would be even more awesome :)

<comment><AUTHOR> Thanks for the feedback, that's definitely in the plans, for building out basically a cdn where you can directly link to the files. I just need to figure out how that works with scripts that require css, images, etc.

</comment></comment></comment><comment><USER3> I had a little sneak peak at this site, and still think it's very cool. One of the cool things is that after this was pushed live, the jQuery team announced that they were updating the plugins.jquery.com site and many of the features were very similar.

Continue to market it as library agnostic - I think that is one of the key differentiators of this site. The idea of a CDN is very cool as well, although I'd worry about bandwidth costs doing something like that. Maybe that is the premium version in a freemium model? (No idea if you plan to make this a commercial venture at some point.)

</comment><comment><USER4> I think it's important we have a host for ALL javascript projects, not just jQuery projects, and I think this site does a pretty damn good job of getting us there. Very nice work.

</comment><comment><USER5> Awesome work, looks good so far.</comment>


HsQML – Haskell bindings for Qt Quick now with Qt 5 - <AUTHOR> http://blog.gekkou.co.uk/2014/05/hsqml-0300-released-now-with-qt-5.html

<comment><USER2> That's awesome. I've been looking into doing something like this a couple years ago.

</comment><comment><USER3> Cool, I was just thinking.. if only Qt Quick bindings existed.. and there it is.. just wow!</comment>


MSSQL TPC-H on Linux Bests Windows - <AUTHOR> http://www.tpc.org/tpch/results/tpch_last_ten_results.asp <comment><USER2> One day, I believe MSFT will just have a runtime of libraries that can run on any platform.

Windows will be dead, but the windows API will live on as a set of developer libraries, just like a QT on steroids would be.

This is step one.</comment>


Stop Calling it a $600 Phone - <AUTHOR> http://ruswick.tumblr.com/post/29638203235/stop-it

<comment><USER2> Its a 600$+ phone! 200$ and then, during your contract time, you pay the rest.

<comment><AUTHOR> No. The price of mobile service is the same for both subsidized and unsubsidized users.

When you buy a subsidized phone, you don't redistribute the cost. You eliminate part of the cost and in return forfeit a number of freedoms to your carrier.

<comment><USER2> And then, you save it by getting a prepaid plan.</comment></comment></comment>


This guy rap-pitched his product and got viral - <AUTHOR> https://twitter.com/ProductHunt/status/927611573824241664 <comment><AUTHOR> This guy from Berlin invented a music app and created a rap-pitch video, where he is using his app and rapping about his project. And doing it not only fun, but also rather sharp and straight to the point. A few days after, the story was picked up by Product Hunt, who named it "The Best Demo Video Ever". After the Product Hunt's mention the video is getting viral with a lot of influencers reposting and commenting on it. It looks like the lucky dude is going to have his exit soon...</comment>


Why is Rails still relevant in 2019 - <AUTHOR> https://devbrett.com/2019/03/why-i-believe-rails-is-still-relevant-in-2019.html <comment><USER2> Good points on the _why_ is relevant for Architecture, configuration, and environments.

I love ruby and rails; _but_ I still have fear of plugins that do the work for me... until I upgrade something and suddenly all falls down.

Not a problem specific to Rails; but to everything in software, really.</comment>


Reddit Cooperating with Russia Investigations. Have Handed Over Zero Documents - <AUTHOR> https://www.thedailybeast.com/exclusive-reddit-says-its-cooperating-with-russia-investigations-theyve-handed-over-zero-documents <comment> noah-kun Given how much the Russian election "rigging" and "hacking" story has focused on Twitter posts, one could be mistaken for thinking they run the elections.</comment>


MIT's New programming framework for reinforcement-learning experiments - <AUTHOR>

MIT's New programming framework to make it easier to set up & run reinforcement-learning experiments<p>http://web.mit.edu/newsoffice/2013/machine-learning-algorithm-outperforms-predecessors-0529.html <comment><USER2> [http://web.mit.edu/newsoffice/2013/machine-learning- algorith...](http://web.mit.edu/newsoffice/2013/machine-learning-algorithm- outperforms-predecessors-0529.html)</comment>