11 ms·

It's the Future

583 points by ctoth 11y ago

fredsters_s 11y ago
hilarious and true.
- deleted 11y ago
  [deleted]
Animats 11y ago
Ah, l33t for system architects. A few days ago, the CTO of Soylent, the food drink, was describing their elaborate computer infrastructure. They have one (1) product and a simple web site. Based on their sales volume, they do about two sales a minute. That could run on a HostGator "Hatchling" account for $4/month, using one of the seven off the shelf shopping cart/payment programs HostGator offers.
- lukasm 11y ago
  Maybe it's for internal apps, managing production of soylent, inventory
  - beat 11y ago
    Production workflow and inventory management are totally greenfield. No one has ever written apps for that stuff before, nope.
    - stephengillie 11y ago
      Can we make it cheaper than we can buy it? Is their purchase price more expensive than my hourly wage for a few months?
      - beat 11y ago
        Can you guarantee success at development? And even if you can, is it a good idea? The coolest software project I've ever been on was also the dumbest. We were trying to build a bios in-house - something that can be bought off-the-shelf for a buck. In theory, it could have saved us millions in the long run. In the short run, we were wasting man-months of engineering on something that was not our business, when the clock was ticking loudly. Fun as heck, but if I caught my own employees doing such a thing today, I'd at least threaten to fire them if they even thought about it again. Likewise, Soylent is not in the inventory management business. Why should they be writing inventory management software? Buy that stuff. Focus development money on the core business.
        hueving 11y ago
        >I'd at least threaten to fire them if they even thought about it again. Blame the employees for crappy management. Sounds like fun!
        beat 11y ago
        It's not crappy management for engineers to have technically cool ideas that are bad business, and then rationalize their value. It's bad management to let them execute on them (except if you have some sort of do-what-you-want time for developers, which is a good way to compensate and balance for this).
        15155 11y ago
        On the other side of the coin, you have the semi-technical manager who has ideas that are unassailable, because they are able to make "do this that way or you're fired" decisions. These kinds of managers are utterly toxic. At the slightest hint of this kind of behavior, I'd be reaching out to my contacts to find new employment, where I would certainly be paid better, but hopefully don't have a feudal work environment.
        HeyLaughingBoy 11y ago
        Funny you say that. I just had a conversation about a meeting I was involved in a few years back when our EE's didn't understand why we thought it was a spectacularly bad idea to design our own Pentium-class CPU boards vs. just buying them off the shelf. Cost advantage? What's that? We just want a cool project!
  - smacktoward 11y ago
    Or maybe it's a clever ploy by their sysadmins to avoid being ground up into Soylent themselves
    - lukasm 11y ago
      or they are building infrastructure for Big Data, because it's the Future ;)
- jbigelow76 11y ago
  What else would the Soylent team do with all the free time not spent preparing and chewing their food like neanderthals?
  - theVirginian 11y ago
    I like to think its more akin to the Jettsons but I digress...
    - protomyth 11y ago
      You both could be right as that is a bit of a conspiracy http://www.visualnews.com/2013/07/16/flintstones-living-with-jetsons-its-a-toon-conspiracy/ http://www.visualnews.com/2013/07/16/flintstones-living-with... // feature request: poster flag's own posts as tangents that start new topics leaving only a graphic (arrow leaving square) in original thread
      - JoshTriplett 11y ago
        There's an "off-topic/meta" flag sometimes applied to posts that are more about HN than about the topic, which causes them to float to the bottom (above the stuff greyed-out into oblivion, but below the top comments). Seems reasonable that people could apply that to their own posts.
- nether 11y ago
  Soylent had exceptionally poor order handling prior to their latest round of funding. The way they've run their business and development seems like a total joke. 6-10 month order delays over a year since they started selling? (Not to mention charging orders before shipping) "Most scientific food" - zero clinical trials? Are you shitting me?
  - joezydeco 11y ago
    Might want to read this: https://medium.com/@alando46/how-we-spent-500-on-tech-to-ship-2-6m-of-soylent-3abfdcebee78 https://medium.com/@alando46/how-we-spent-500-on-tech-to-shi... If you knew how most modern warehouse/shipping facilities ran their IT, your head would spin.
    - Animats 11y ago
      Figures. They overbuilt their public-facing web system, and underbuilt their fulfillment system. Reading that, you can see the problem - their order system, fulfillment system, and order tracking system didn't talk to each other properly. You don't just ship stuff blind; you read back the carrier's online shipping data and match it with the orders, so you know you didn't miss anything. Otherwise, you don't know you screwed up until the angry customer calls you.
  - S4M 11y ago
    It's also crazy that they don't let you order one sample to test it. There is no way I will pay $70 for 28 meals if I don't know if I will like it.
    - redsparrow 11y ago
      I think the expectation that you'll like it on the first try is low. Maybe they're hoping you'll get used to it. :)
  - john3263 11y ago
    Their order times are actually really low now (a few days). Customer satisfaction is much higher now as well.
- mtbcoder 11y ago
  Doesn't really seem that elaborate if this is correct: https://twitter.com/stackshareio/status/578629809242312704 https://twitter.com/stackshareio/status/578629809242312704
akanet 11y ago
It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com https://www.docker.com, you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-benefit make sense? What new things can I do that I couldn't do before? They made a separate page just to address this giant "Huh?": https://www.docker.com/whatisdocker https://www.docker.com/whatisdocker, which I feel is equally obtuse. Luckily, the product itself is fantastic, so that gives you a lot of wiggle room on your website and documentation. Like, a lot.
- ezy 11y ago
  The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.
  - akanet 11y ago
    I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ https://www.ruby-lang.org/en/. There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. There's an example embedded on the page. There's also recent news that intermediate users might be interested in. On Docker's website, there's a huge amount of confusion about what Docker even is. A platform? A runtime? Both? Which is the one I should care about? The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy. It's that attitude towards UX that has lead to the following one-liner to being the only way to do something so mundane as "removing all your untagged images": docker rmi $(docker images | grep "^<none>" | awk "{print $3}") Any business that interacts with other humans needs to concern itself with messaging, and I don't think computer industry types are exempt in any way.
jbigelow76 11y ago
Only made it about a third of the way through but it seemed like latter day Xtra Normal MongoDB/web scale shtick[1]. [1] https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- latchkey 11y ago
  Yea, too bad xtranormal is no longer around.
aerovistae 11y ago
This is exactly how I feel whenever people start talking about this stuff. Is that bad? I know this is a satirical post but it seems like a pretty faithful depiction of reality.
- fennecfoxen 11y ago
  If people are talking about breaking up a simple web application and saddling it with all sorts of crazy complexity, then this is the correct reaction and you should feel bad. If people actually have a legitimate need for really high availability and really high scalability and are willing to pay through the nose for the software development necessary to make a straightforward system into a distributed system... well, you should still feel just bad about all the complexity, but you're basically stuck with it :)
- unoti 11y ago
  This is really nothing new. It's a DevOps version of Joel on Software's famous essay about Architecture Astronaughts from 2001: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html
  - aerovistae 11y ago
    From that article: "The Architecture Astronauts will say things like: "Can you imagine a program like Napster where you can download anything, not just songs?" hahahahahhaha bittorrent.
    - digi_owl 11y ago
      Even Napster was used for non-music stuff towards the end, by renaming archives as mp3. And the basic protocol was later adopted for more generic sharing systems, never mind the number of clones that came about after Napster was lawyer bombed. Bittorrent is just the latest in a long string of P2P systems, with the biggest difference being the lack of a central search server.
      - 11y ago
mmanfrin 11y ago
Rails? That's so yesterday. New hotness is React! React? I thought we were doing Angular? Come on man, you're stuck in the past!
- canistr 11y ago
  New, new hotness is React Native (or whenever FB decides to make it also available on Android) and JSBlocks.
  - thinkdevcode 11y ago
    New, new, new hotness is Aurelia! Get with the times! http://aurelia.io/ http://aurelia.io/ Edit: just wanted to point out that this post was only partially satirical. I absolutely am in love with Aurelia atm.
    - rdsubhas 11y ago
      atm
    - devuo 11y ago
      atm
    - deleted 11y ago
      [deleted]
VieElm 11y ago
Well these technologies are there to help bring Google type infrastructure for businesses that need it. If you're running a CRUD app just fine on Heroku you don't need to do any of this and you shouldn't. When your availability starts having problems or your data is getting too much for one machine, you start having problems of scale. Where you are in terms of scaling issues should lead you to the next iteration of technology required to keep your service up. Starting out of the gates with that one idea you're not sure anyone will be interested in? Just stick to deploying something fast and not worry about Google style scaling solutions.
- jakejake 11y ago
  Seems to be the problem with a lot of technologies. If you're a HN reader, you can start to get the feeling that you're falling behind if you're not doing these things. Even though they are totally inappropriate for the majority of us who are working on smaller systems.
  - digi_owl 11y ago
    Thats not limited to HN. Outsorcing became a Wall Street fad once a few big name companies did the numbers and found they could reduce costs by doing so. Soon "everyone" was doing it, or announcing that they were going to, even though they had little to nothing to gain from it. As that saying goes: when all you have is a hammer, every problem looks like a nail. And right now that hammer, at least in terms of IT, seems to be containers.
  - serve_yay 11y ago
    Sure. But it's incorrect to blame, say, Docker for that.
  - VieElm 11y ago
    As an engineer I feel an obligation to know about these things and how they work. It might be appropriate for my work. For my own projects I am just going to start out with a Django or Meteor app and if I'm lucky enough to have to worry about scale I'll have some idea of what to do next.
thebouv 11y ago
Reading this made my brain feel itchy. Because it's too close to some conversations I've had.
- plaguuuuuu 11y ago
  You might also have parasites :3
deleted 11y ago
[deleted]
nchelluri 11y ago
This is one of my favorite blog posts of all time. I love it. Thank you, CircleCI, for posting this!
smadge 11y ago
Ughhh this. I just want to give my project to a PaaS and let them figure out everything. I was looking into Google App Engine, but they didn't support some language features I wanted (e.g. Java 1.8, Servlet 3.X["I know, programming in Java? You're stuck in the past"]). So I looked into their new Container Engine. But like this article points out, it makes deployment 500000000 times more complicated than it should be.
- twic 11y ago
  How about: https://run.pivotal.io/features/ https://run.pivotal.io/features/ ? Java 1.8 and Tomcat 8.0.x, so Servlet 3.1. On a good day, deployment is one command which just does its thing. It's not without its quirks, but in my experience they're fairly minor.
- icebraining 11y ago
  Isn't Elastic Beanstalk what you need? I've never used it, but they support Java 8 and Servlet 3.
- kordless 11y ago
  Check out https://giantswarm.io/ https://giantswarm.io/.
msane 11y ago
To the position that containerization is needless complexity for simple or non-scaling apps: one of the benefits of containers is it can create development environments which can be identical to your production environment(s); no matter what platform you're always running the same code, same artifacts, same images. Virtualization does this too, but at great cost. I wish the kinks were better worked out at this point as well, and hope we start to converge around a few well-working patterns and toolsets. I expect it to happen. In the meantime it is chaos and easy to laugh at.
- pbiggar 11y ago
  But (and this is a thing I've been working on) do you really want your dev environment to be identical to your production environment? I think you don't. As an example, suppose you use Go. Your dev environment is 500mb of compilers and toolchain. Your production environment is (hopefully) a container with a single static binary on it.
  - lstamour 11y ago
    The point is not that dev and production environments are identical, but that dev staging and production environments are identical. Your dev box can have whatever you like on it, but if it can't fake production behaviours, it's not going to help you catch and debug bugs in production. Of course there are limits. You could, it's perfectly valid, buy twice as much capacity in production and run it twice there. And use remote debugging tools. The point, especially with ops involved, is that your dev box is a snowflake and you want the least amount of manual configuration possible. It's not a requirement. Your app will run fine in production without it simply by testing in production. But few people willingly recommend that approach, even as pretty much everyone does it at some point or another. Even the best emulation of production won't prevent the need for debugging in production when a bug isn't caught before it gets deployed ;-)
    - pbiggar 11y ago
      Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.
noonespecial 11y ago
Meanwhile, the last two web applications I've consulted on are now more than 12 years old, use SOAP and where written in Delphi. They work surprisingly well to this day and despite being horrified upon hearing that this was what they were built on, I found them surprisingly well done. I wonder what will still be running 12 years from now and what it will look like.
hawski 11y ago
Reading this I keep my fingers crossed for http://sandstorm.io/ http://sandstorm.io/ or another Android-of-services.
vbezhenar 11y ago
I may be old guy but I never get it. Why do I ever need all this virtualization stuff? I just buy a server, install CentOS, install postgresql, create another user, install java, download&unarchive tomcat and write some simple bash scripts. Voila. Everything works, everything is protected, performance is superb and I can do all that within one day. Good enough to serve few thousand requests per second. May be not enough for Facebook, of course.
- imaginenore 11y ago
  And then that data center has a fire, your server is gone, your data is gone, your business loses X thousands of dollars per day, all because everything was on one server.
  - icebraining 11y ago
    If you have continuous backups, it's actually not that bad. You can recreate a server fairly rapidly from a full system backup.
  - vbezhenar 11y ago
    I usually have backups to a cloud, so thats's really not a problem.
    - imaginenore 11y ago
      Yeah, but it still takes time to set up a new server, launch it, update the DNS. And you lose all the data since the last backup.
- peu4000 11y ago
  That's great if it's just you and you don't care about your site breaking because you didn't test your code outside of your Mac. More users, more developers, larger sites require more than just Jim Bob installing CentOS and tomcat on a pizza box. It doesn't always require Docker + this tech or that tech, but you will have to put some automation in place.
facepalm 11y ago
A seeming eternity ago I let Maven convert apps into war files that supposedly could be deployed into any web application server. What do the new containers add on top of that (or other than that)? Only the option for more services (not just web app, but database, different languages, whatever)? It seems odd having to worry about that kind of thing.
- eurleif 11y ago
  >It seems odd having to worry about that kind of thing. It seems odd having to worry about things that aren't Web apps? Why? Containers are also language-agnostic. .war files are only for JVM languages.
  - facepalm 11y ago
    Mabye it is either a ploy of admins to make programmers do their work for them, or a ploy of programmers to put admins out of their jobs? I don't really know docker yet. So if I need a database, rather than instantiating a server with a database, I would create a docker image that runs a database? Then deploy it to some server that can digest docker images (is there a docker image for that)? The point of war files was not having to worry about the server.
serve_yay 11y ago
So you posited a totally dumb guy to talk to, then you talked to him and he said dumb stuff. Cool.
icebraining 11y ago
This hits home. While everyone is talking containers, we're running simple processes with a Linux user per instance, and I feel no need to add more complexity to our system, except I'm really struggling to automate stuff. It seems that if you aren't running a full dockerized cluster of services or outsourcing everything to a PaaS, you're left with building all the infrastructure yourself. What did people use before this great new wave?
- walterbell 11y ago
  A couple of decades of experience is encoded in CFEngine: http://en.wikipedia.org/wiki/CFEngine http://en.wikipedia.org/wiki/CFEngine http://cfengine.com/product/community/ http://cfengine.com/product/community/
  - icebraining 11y ago
    Yeah, we're using configuration management, but that still seems too low level. I haven't tried CFEngine, but in the ones I have, there's no concept of an instance (essentially some configuration files and a few databases) that you should be able to treat as a single unit (e.g. delete instance or move it to another server). I wonder what's the architecture behind WPEngine and similar services. It must provide some isolation since clients can install their own plugins, but on the other hand I don't see them creating a new Docker image for each client, especially since they're self-managed.
- digi_owl 11y ago
  I think there is a mix of things being bandied about under the "container" banner. On the one hand it is about getting more bang for your hardware buck. On the other it is about someone getting so deep into netsec that they have developed gills. In the bang for bucks category you have a chain of one box pr database etc. Then noticing that the hardware sits idle most of the time, so virtualization is depolyed to pack more server on a single box to keep it in use. Then noticing that virtualization comes with a performance overhead, so it gets replaced chroot/containerization to give the impression of unshared box. In the netsec category it is really about namespace. Limiting the view of the world the processes gets. This has a superficial similarity to chroot, but can go much much deeper. And if one go deep enough, every server ends up looking like a digital fort Knox...
sebringj 11y ago
These frameworks arise from huge corporations then get preached to the masses. Problem is, they are only useful at the huge corporation level. Ironic.
jtwebman 11y ago
What no mention of running Dokku on Digital Ocean.
bch 11y ago
Anne > What’s Aphyr? Bob > -Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed systems and BDSM guy? Anne > What? Did you say BDSM? Bob > -Yeah, BDSM. It’s San Francisco. Everyone’s into distributed systems and BDSM. This hilarity demonstrates the tone, and alone is worth the price of admission. Great job with this article.
- ahelwer 11y ago
  "Paxos is like this really old distributed consensus protocol from the 70s that no-one understands or uses." I've run into this. In reality The Part-Time Parliament was published in 1998 and Paxos Made Simple in 2001.
  - Dewie3 11y ago
    Maybe they got their IT-timescale mixed up with our normal timescale. Things that happened in IT in the 70s on the normal timescale was like 200 IT years ago on the tech timescale, man.
myth_buster 11y ago
Sadly I often feel this is the state of most of the web-dev stack due to high churn. There are extremely smart people working on tools who keep forking out new frameworks/tools/components/scripts and a bigger pool of smart people who keep consuming it. Having seen in enterprise incredible amount of man-hours wasted on migrating, re-writing and creating POCs on the latest fad, I sometimes wonder whether this cycle is productive or we keep at it just to keep our brains working and not go insane thinking of geo-political/financial/meta-physical questions. Its perhaps Crack for the tech crowd.
- Dewie3 11y ago
  > There are extremely smart people working on tools who keep forking out new frameworks/tools/components/scripts and a bigger pool of smart people who keep consuming it. Well, at least they get the privilege of being regarded as very smart. Why be a lowly smart web developer when you can be elevated to the status of extremely smart framework author/designer? If they care about that kind of status. If you want them to be a bit less trigger-happy, perhaps don't praise them so much for creating their own small contributions to the fragmented landscape.
- digi_owl 11y ago
  It may have picked up a quicker cadence on the web, but i swear this has been the case on "desktop" as well.
bch 11y ago
This OP gem-of-a-story reminds me of another masterpiece, about Tcl: http://www.markroseman.com/tcl/dyingout.html http://www.markroseman.com/tcl/dyingout.html (ref: https://news.ycombinator.com/item?id=9689046 https://news.ycombinator.com/item?id=9689046) Edit: link to submitted story.
crispycret 11y ago
I read this in the voice of Randy from southpark. Best episode ever!
ninkendo 11y ago
I've always thought of the whole containerization and orchestration "hotness" (I guess we're calling it "gifee" now?) to be great for people who want to write their own PaaS. And not really anybody else. I mean, it's great that the pieces are all there and open source now. You can get to a really great place with automation by gluing together Docker/Rocket, Mesos/Kubernetes, etcd/zookeeper, etc. But for now, a complete solution still requires you to bring a lot of your own glue. I mean, by the time you've actually covered enough edge cases to make all these ops components work together in a meaningful way, in a way that doesn't doesn't fail randomly or trip over itself when some critical component breaks, you may as well just start charging other people money to use it. I say this from the point of view of someone who's done it all (implemented a private Heroku on the stack described above [1]), and although it works amazingly well (for literally hundreds of internal apps), it was not trivial... not even close. We're talking probably 1-2 man-years of effort to get it to the point where it's usable, and that's with leveraging as much existing tech as we can. To anybody else, as in, any company who actually wants to ship a product (where the product isn't just a PaaS), I just don't see how it's worth it. Just use heroku (or elastic beanstalk, or appengine, or whatever.) [1] I'd love to make all the glue open source but I'm not really in a position to do so. But I suspect I'm not the only person who's done this... I really think anybody who's gotten this whole "the future" stack working solidly is in a similar position as me: if you really did get the job done for a single app, chances are you've invented an internal Heroku of your own.
- helloiamaperson 11y ago
  Or use cloud foundry (http://cloudfoundry.org/index.html http://cloudfoundry.org/index.html) if you have a burning desire to stand up your own paas vs. just using heroku.
lafar6502 11y ago
sounds strikingly realistic for a joke
doppp 11y ago
What's funny is that CircleCI is one of a million CI deployment services out there too.
rehtona 11y ago
Now do this for the Hadoop ecosystem. I'm ripping my hair out because of the complexity of it all. I get that distributed is difficult, but this just feels like too much. Abstraction upon abstraction upon abstraction. Hadoop is this thing over here, but now we have this other thing built on top that is way better. But actually that thing also sucks, so we built a whole layer on top to abstract away the badness of that other thing plus two other alternatives to it. Oh, but that wasn't good enough, so now you can write queries in this other language. And on and on and on it goes.
BerislavLopac 11y ago
In the immortal words of David Wheeler and Kevlin Henney: "All problems in computer science can be solved by another level of indirection, except for the problem of too many levels of indirection." Feel free to substitute abstraction for indirection.
- jimbokun 11y ago
  Just saw this linked on HN yesterday: http://www.dwheeler.com/innovation/innovation.html http://www.dwheeler.com/innovation/innovation.html I think Wheeler and Henney's quote applies to a lot of the advances on this list.
deleted 11y ago
[deleted]

It's the Future

583 points by ctoth 11y ago

fredsters_s 11y ago

hilarious and true.

deleted 11y ago
[deleted]

Animats 11y ago

Ah, l33t for system architects. A few days ago, the CTO of Soylent, the food drink, was describing their elaborate computer infrastructure. They have one (1) product and a simple web site. Based on their sales volume, they do about two sales a minute. That could run on a HostGator "Hatchling" account for $4/month, using one of the seven off the shelf shopping cart/payment programs HostGator offers.

lukasm 11y ago
Maybe it's for internal apps, managing production of soylent, inventory
- beat 11y ago
  Production workflow and inventory management are totally greenfield. No one has ever written apps for that stuff before, nope.
  - stephengillie 11y ago
    Can we make it cheaper than we can buy it? Is their purchase price more expensive than my hourly wage for a few months?
    - beat 11y ago
      Can you guarantee success at development? And even if you can, is it a good idea? The coolest software project I've ever been on was also the dumbest. We were trying to build a bios in-house - something that can be bought off-the-shelf for a buck. In theory, it could have saved us millions in the long run. In the short run, we were wasting man-months of engineering on something that was not our business, when the clock was ticking loudly. Fun as heck, but if I caught my own employees doing such a thing today, I'd at least threaten to fire them if they even thought about it again. Likewise, Soylent is not in the inventory management business. Why should they be writing inventory management software? Buy that stuff. Focus development money on the core business.
      - hueving 11y ago
        >I'd at least threaten to fire them if they even thought about it again. Blame the employees for crappy management. Sounds like fun!
        beat 11y ago
        It's not crappy management for engineers to have technically cool ideas that are bad business, and then rationalize their value. It's bad management to let them execute on them (except if you have some sort of do-what-you-want time for developers, which is a good way to compensate and balance for this).
        15155 11y ago
        On the other side of the coin, you have the semi-technical manager who has ideas that are unassailable, because they are able to make "do this that way or you're fired" decisions. These kinds of managers are utterly toxic. At the slightest hint of this kind of behavior, I'd be reaching out to my contacts to find new employment, where I would certainly be paid better, but hopefully don't have a feudal work environment.
      - HeyLaughingBoy 11y ago
        Funny you say that. I just had a conversation about a meeting I was involved in a few years back when our EE's didn't understand why we thought it was a spectacularly bad idea to design our own Pentium-class CPU boards vs. just buying them off the shelf. Cost advantage? What's that? We just want a cool project!
- smacktoward 11y ago
  Or maybe it's a clever ploy by their sysadmins to avoid being ground up into Soylent themselves
  - lukasm 11y ago
    or they are building infrastructure for Big Data, because it's the Future ;)
jbigelow76 11y ago
What else would the Soylent team do with all the free time not spent preparing and chewing their food like neanderthals?
- theVirginian 11y ago
  I like to think its more akin to the Jettsons but I digress...
  - protomyth 11y ago
    You both could be right as that is a bit of a conspiracy http://www.visualnews.com/2013/07/16/flintstones-living-with-jetsons-its-a-toon-conspiracy/ http://www.visualnews.com/2013/07/16/flintstones-living-with... // feature request: poster flag's own posts as tangents that start new topics leaving only a graphic (arrow leaving square) in original thread
    - JoshTriplett 11y ago
      There's an "off-topic/meta" flag sometimes applied to posts that are more about HN than about the topic, which causes them to float to the bottom (above the stuff greyed-out into oblivion, but below the top comments). Seems reasonable that people could apply that to their own posts.
nether 11y ago
Soylent had exceptionally poor order handling prior to their latest round of funding. The way they've run their business and development seems like a total joke. 6-10 month order delays over a year since they started selling? (Not to mention charging orders before shipping) "Most scientific food" - zero clinical trials? Are you shitting me?
- joezydeco 11y ago
  Might want to read this: https://medium.com/@alando46/how-we-spent-500-on-tech-to-ship-2-6m-of-soylent-3abfdcebee78 https://medium.com/@alando46/how-we-spent-500-on-tech-to-shi... If you knew how most modern warehouse/shipping facilities ran their IT, your head would spin.
  - Animats 11y ago
    Figures. They overbuilt their public-facing web system, and underbuilt their fulfillment system. Reading that, you can see the problem - their order system, fulfillment system, and order tracking system didn't talk to each other properly. You don't just ship stuff blind; you read back the carrier's online shipping data and match it with the orders, so you know you didn't miss anything. Otherwise, you don't know you screwed up until the angry customer calls you.
- S4M 11y ago
  It's also crazy that they don't let you order one sample to test it. There is no way I will pay $70 for 28 meals if I don't know if I will like it.
  - redsparrow 11y ago
    I think the expectation that you'll like it on the first try is low. Maybe they're hoping you'll get used to it. :)
- john3263 11y ago
  Their order times are actually really low now (a few days). Customer satisfaction is much higher now as well.
mtbcoder 11y ago
Doesn't really seem that elaborate if this is correct: https://twitter.com/stackshareio/status/578629809242312704 https://twitter.com/stackshareio/status/578629809242312704

akanet 11y ago

It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com https://www.docker.com, you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-benefit make sense? What new things can I do that I couldn't do before? They made a separate page just to address this giant "Huh?": https://www.docker.com/whatisdocker https://www.docker.com/whatisdocker, which I feel is equally obtuse. Luckily, the product itself is fantastic, so that gives you a lot of wiggle room on your website and documentation. Like, a lot.

ezy 11y ago
The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.
- akanet 11y ago
  I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ https://www.ruby-lang.org/en/. There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. There's an example embedded on the page. There's also recent news that intermediate users might be interested in. On Docker's website, there's a huge amount of confusion about what Docker even is. A platform? A runtime? Both? Which is the one I should care about? The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy. It's that attitude towards UX that has lead to the following one-liner to being the only way to do something so mundane as "removing all your untagged images": docker rmi $(docker images | grep "^<none>" | awk "{print $3}") Any business that interacts with other humans needs to concern itself with messaging, and I don't think computer industry types are exempt in any way.

jbigelow76 11y ago

Only made it about a third of the way through but it seemed like latter day Xtra Normal MongoDB/web scale shtick[1]. [1] https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs

latchkey 11y ago
Yea, too bad xtranormal is no longer around.

aerovistae 11y ago

This is exactly how I feel whenever people start talking about this stuff. Is that bad? I know this is a satirical post but it seems like a pretty faithful depiction of reality.

fennecfoxen 11y ago
If people are talking about breaking up a simple web application and saddling it with all sorts of crazy complexity, then this is the correct reaction and you should feel bad. If people actually have a legitimate need for really high availability and really high scalability and are willing to pay through the nose for the software development necessary to make a straightforward system into a distributed system... well, you should still feel just bad about all the complexity, but you're basically stuck with it :)
unoti 11y ago
This is really nothing new. It's a DevOps version of Joel on Software's famous essay about Architecture Astronaughts from 2001: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html
- aerovistae 11y ago
  From that article: "The Architecture Astronauts will say things like: "Can you imagine a program like Napster where you can download anything, not just songs?" hahahahahhaha bittorrent.
  - digi_owl 11y ago
    Even Napster was used for non-music stuff towards the end, by renaming archives as mp3. And the basic protocol was later adopted for more generic sharing systems, never mind the number of clones that came about after Napster was lawyer bombed. Bittorrent is just the latest in a long string of P2P systems, with the biggest difference being the lack of a central search server.
    - 11y ago

mmanfrin 11y ago

Rails? That's so yesterday. New hotness is React! React? I thought we were doing Angular? Come on man, you're stuck in the past!

canistr 11y ago
New, new hotness is React Native (or whenever FB decides to make it also available on Android) and JSBlocks.
- thinkdevcode 11y ago
  New, new, new hotness is Aurelia! Get with the times! http://aurelia.io/ http://aurelia.io/ Edit: just wanted to point out that this post was only partially satirical. I absolutely am in love with Aurelia atm.
  - rdsubhas 11y ago
    atm
  - devuo 11y ago
    atm
  - deleted 11y ago
    [deleted]

VieElm 11y ago

Well these technologies are there to help bring Google type infrastructure for businesses that need it. If you're running a CRUD app just fine on Heroku you don't need to do any of this and you shouldn't. When your availability starts having problems or your data is getting too much for one machine, you start having problems of scale. Where you are in terms of scaling issues should lead you to the next iteration of technology required to keep your service up. Starting out of the gates with that one idea you're not sure anyone will be interested in? Just stick to deploying something fast and not worry about Google style scaling solutions.

jakejake 11y ago
Seems to be the problem with a lot of technologies. If you're a HN reader, you can start to get the feeling that you're falling behind if you're not doing these things. Even though they are totally inappropriate for the majority of us who are working on smaller systems.
- digi_owl 11y ago
  Thats not limited to HN. Outsorcing became a Wall Street fad once a few big name companies did the numbers and found they could reduce costs by doing so. Soon "everyone" was doing it, or announcing that they were going to, even though they had little to nothing to gain from it. As that saying goes: when all you have is a hammer, every problem looks like a nail. And right now that hammer, at least in terms of IT, seems to be containers.
- serve_yay 11y ago
  Sure. But it's incorrect to blame, say, Docker for that.
- VieElm 11y ago
  As an engineer I feel an obligation to know about these things and how they work. It might be appropriate for my work. For my own projects I am just going to start out with a Django or Meteor app and if I'm lucky enough to have to worry about scale I'll have some idea of what to do next.

thebouv 11y ago

Reading this made my brain feel itchy. Because it's too close to some conversations I've had.

plaguuuuuu 11y ago
You might also have parasites :3

deleted 11y ago

[deleted]

nchelluri 11y ago

This is one of my favorite blog posts of all time. I love it. Thank you, CircleCI, for posting this!

smadge 11y ago

Ughhh this. I just want to give my project to a PaaS and let them figure out everything. I was looking into Google App Engine, but they didn't support some language features I wanted (e.g. Java 1.8, Servlet 3.X["I know, programming in Java? You're stuck in the past"]). So I looked into their new Container Engine. But like this article points out, it makes deployment 500000000 times more complicated than it should be.

twic 11y ago
How about: https://run.pivotal.io/features/ https://run.pivotal.io/features/ ? Java 1.8 and Tomcat 8.0.x, so Servlet 3.1. On a good day, deployment is one command which just does its thing. It's not without its quirks, but in my experience they're fairly minor.
icebraining 11y ago
Isn't Elastic Beanstalk what you need? I've never used it, but they support Java 8 and Servlet 3.
kordless 11y ago
Check out https://giantswarm.io/ https://giantswarm.io/.

msane 11y ago

To the position that containerization is needless complexity for simple or non-scaling apps: one of the benefits of containers is it can create development environments which can be identical to your production environment(s); no matter what platform you're always running the same code, same artifacts, same images. Virtualization does this too, but at great cost. I wish the kinks were better worked out at this point as well, and hope we start to converge around a few well-working patterns and toolsets. I expect it to happen. In the meantime it is chaos and easy to laugh at.

pbiggar 11y ago
But (and this is a thing I've been working on) do you really want your dev environment to be identical to your production environment? I think you don't. As an example, suppose you use Go. Your dev environment is 500mb of compilers and toolchain. Your production environment is (hopefully) a container with a single static binary on it.
- lstamour 11y ago
  The point is not that dev and production environments are identical, but that dev staging and production environments are identical. Your dev box can have whatever you like on it, but if it can't fake production behaviours, it's not going to help you catch and debug bugs in production. Of course there are limits. You could, it's perfectly valid, buy twice as much capacity in production and run it twice there. And use remote debugging tools. The point, especially with ops involved, is that your dev box is a snowflake and you want the least amount of manual configuration possible. It's not a requirement. Your app will run fine in production without it simply by testing in production. But few people willingly recommend that approach, even as pretty much everyone does it at some point or another. Even the best emulation of production won't prevent the need for debugging in production when a bug isn't caught before it gets deployed ;-)
  - pbiggar 11y ago
    Yeah, but folks are talking about using containers for actual dev environments. Because you want to make sure everyone is using the same version of the go compilers, etc.

noonespecial 11y ago

Meanwhile, the last two web applications I've consulted on are now more than 12 years old, use SOAP and where written in Delphi. They work surprisingly well to this day and despite being horrified upon hearing that this was what they were built on, I found them surprisingly well done. I wonder what will still be running 12 years from now and what it will look like.

hawski 11y ago

Reading this I keep my fingers crossed for http://sandstorm.io/ http://sandstorm.io/ or another Android-of-services.

vbezhenar 11y ago

I may be old guy but I never get it. Why do I ever need all this virtualization stuff? I just buy a server, install CentOS, install postgresql, create another user, install java, download&unarchive tomcat and write some simple bash scripts. Voila. Everything works, everything is protected, performance is superb and I can do all that within one day. Good enough to serve few thousand requests per second. May be not enough for Facebook, of course.

imaginenore 11y ago
And then that data center has a fire, your server is gone, your data is gone, your business loses X thousands of dollars per day, all because everything was on one server.
- icebraining 11y ago
  If you have continuous backups, it's actually not that bad. You can recreate a server fairly rapidly from a full system backup.
- vbezhenar 11y ago
  I usually have backups to a cloud, so thats's really not a problem.
  - imaginenore 11y ago
    Yeah, but it still takes time to set up a new server, launch it, update the DNS. And you lose all the data since the last backup.
peu4000 11y ago
That's great if it's just you and you don't care about your site breaking because you didn't test your code outside of your Mac. More users, more developers, larger sites require more than just Jim Bob installing CentOS and tomcat on a pizza box. It doesn't always require Docker + this tech or that tech, but you will have to put some automation in place.

facepalm 11y ago

A seeming eternity ago I let Maven convert apps into war files that supposedly could be deployed into any web application server. What do the new containers add on top of that (or other than that)? Only the option for more services (not just web app, but database, different languages, whatever)? It seems odd having to worry about that kind of thing.

eurleif 11y ago
>It seems odd having to worry about that kind of thing. It seems odd having to worry about things that aren't Web apps? Why? Containers are also language-agnostic. .war files are only for JVM languages.
- facepalm 11y ago
  Mabye it is either a ploy of admins to make programmers do their work for them, or a ploy of programmers to put admins out of their jobs? I don't really know docker yet. So if I need a database, rather than instantiating a server with a database, I would create a docker image that runs a database? Then deploy it to some server that can digest docker images (is there a docker image for that)? The point of war files was not having to worry about the server.

serve_yay 11y ago

So you posited a totally dumb guy to talk to, then you talked to him and he said dumb stuff. Cool.

icebraining 11y ago

This hits home. While everyone is talking containers, we're running simple processes with a Linux user per instance, and I feel no need to add more complexity to our system, except I'm really struggling to automate stuff. It seems that if you aren't running a full dockerized cluster of services or outsourcing everything to a PaaS, you're left with building all the infrastructure yourself. What did people use before this great new wave?

walterbell 11y ago
A couple of decades of experience is encoded in CFEngine: http://en.wikipedia.org/wiki/CFEngine http://en.wikipedia.org/wiki/CFEngine http://cfengine.com/product/community/ http://cfengine.com/product/community/
- icebraining 11y ago
  Yeah, we're using configuration management, but that still seems too low level. I haven't tried CFEngine, but in the ones I have, there's no concept of an instance (essentially some configuration files and a few databases) that you should be able to treat as a single unit (e.g. delete instance or move it to another server). I wonder what's the architecture behind WPEngine and similar services. It must provide some isolation since clients can install their own plugins, but on the other hand I don't see them creating a new Docker image for each client, especially since they're self-managed.
digi_owl 11y ago
I think there is a mix of things being bandied about under the "container" banner. On the one hand it is about getting more bang for your hardware buck. On the other it is about someone getting so deep into netsec that they have developed gills. In the bang for bucks category you have a chain of one box pr database etc. Then noticing that the hardware sits idle most of the time, so virtualization is depolyed to pack more server on a single box to keep it in use. Then noticing that virtualization comes with a performance overhead, so it gets replaced chroot/containerization to give the impression of unshared box. In the netsec category it is really about namespace. Limiting the view of the world the processes gets. This has a superficial similarity to chroot, but can go much much deeper. And if one go deep enough, every server ends up looking like a digital fort Knox...

sebringj 11y ago

These frameworks arise from huge corporations then get preached to the masses. Problem is, they are only useful at the huge corporation level. Ironic.

jtwebman 11y ago

What no mention of running Dokku on Digital Ocean.

bch 11y ago

Anne > What’s Aphyr? Bob > -Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed systems and BDSM guy? Anne > What? Did you say BDSM? Bob > -Yeah, BDSM. It’s San Francisco. Everyone’s into distributed systems and BDSM. This hilarity demonstrates the tone, and alone is worth the price of admission. Great job with this article.

ahelwer 11y ago
"Paxos is like this really old distributed consensus protocol from the 70s that no-one understands or uses." I've run into this. In reality The Part-Time Parliament was published in 1998 and Paxos Made Simple in 2001.
- Dewie3 11y ago
  Maybe they got their IT-timescale mixed up with our normal timescale. Things that happened in IT in the 70s on the normal timescale was like 200 IT years ago on the tech timescale, man.

myth_buster 11y ago

Sadly I often feel this is the state of most of the web-dev stack due to high churn. There are extremely smart people working on tools who keep forking out new frameworks/tools/components/scripts and a bigger pool of smart people who keep consuming it. Having seen in enterprise incredible amount of man-hours wasted on migrating, re-writing and creating POCs on the latest fad, I sometimes wonder whether this cycle is productive or we keep at it just to keep our brains working and not go insane thinking of geo-political/financial/meta-physical questions. Its perhaps Crack for the tech crowd.

Dewie3 11y ago
> There are extremely smart people working on tools who keep forking out new frameworks/tools/components/scripts and a bigger pool of smart people who keep consuming it. Well, at least they get the privilege of being regarded as very smart. Why be a lowly smart web developer when you can be elevated to the status of extremely smart framework author/designer? If they care about that kind of status. If you want them to be a bit less trigger-happy, perhaps don't praise them so much for creating their own small contributions to the fragmented landscape.
digi_owl 11y ago
It may have picked up a quicker cadence on the web, but i swear this has been the case on "desktop" as well.

bch 11y ago

This OP gem-of-a-story reminds me of another masterpiece, about Tcl: http://www.markroseman.com/tcl/dyingout.html http://www.markroseman.com/tcl/dyingout.html (ref: https://news.ycombinator.com/item?id=9689046 https://news.ycombinator.com/item?id=9689046) Edit: link to submitted story.

crispycret 11y ago

I read this in the voice of Randy from southpark. Best episode ever!

ninkendo 11y ago

I've always thought of the whole containerization and orchestration "hotness" (I guess we're calling it "gifee" now?) to be great for people who want to write their own PaaS. And not really anybody else. I mean, it's great that the pieces are all there and open source now. You can get to a really great place with automation by gluing together Docker/Rocket, Mesos/Kubernetes, etcd/zookeeper, etc. But for now, a complete solution still requires you to bring a lot of your own glue. I mean, by the time you've actually covered enough edge cases to make all these ops components work together in a meaningful way, in a way that doesn't doesn't fail randomly or trip over itself when some critical component breaks, you may as well just start charging other people money to use it. I say this from the point of view of someone who's done it all (implemented a private Heroku on the stack described above [1]), and although it works amazingly well (for literally hundreds of internal apps), it was not trivial... not even close. We're talking probably 1-2 man-years of effort to get it to the point where it's usable, and that's with leveraging as much existing tech as we can. To anybody else, as in, any company who actually wants to ship a product (where the product isn't just a PaaS), I just don't see how it's worth it. Just use heroku (or elastic beanstalk, or appengine, or whatever.) [1] I'd love to make all the glue open source but I'm not really in a position to do so. But I suspect I'm not the only person who's done this... I really think anybody who's gotten this whole "the future" stack working solidly is in a similar position as me: if you really did get the job done for a single app, chances are you've invented an internal Heroku of your own.

helloiamaperson 11y ago
Or use cloud foundry (http://cloudfoundry.org/index.html http://cloudfoundry.org/index.html) if you have a burning desire to stand up your own paas vs. just using heroku.

lafar6502 11y ago

sounds strikingly realistic for a joke

doppp 11y ago

What's funny is that CircleCI is one of a million CI deployment services out there too.

rehtona 11y ago

Now do this for the Hadoop ecosystem. I'm ripping my hair out because of the complexity of it all. I get that distributed is difficult, but this just feels like too much. Abstraction upon abstraction upon abstraction. Hadoop is this thing over here, but now we have this other thing built on top that is way better. But actually that thing also sucks, so we built a whole layer on top to abstract away the badness of that other thing plus two other alternatives to it. Oh, but that wasn't good enough, so now you can write queries in this other language. And on and on and on it goes.

BerislavLopac 11y ago

In the immortal words of David Wheeler and Kevlin Henney: "All problems in computer science can be solved by another level of indirection, except for the problem of too many levels of indirection." Feel free to substitute abstraction for indirection.

jimbokun 11y ago
Just saw this linked on HN yesterday: http://www.dwheeler.com/innovation/innovation.html http://www.dwheeler.com/innovation/innovation.html I think Wheeler and Henney's quote applies to a lot of the advances on this list.

deleted 11y ago

[deleted]