Hacker News Reader

> Also people that want to start a business, there is a huge opportunity here, create software that makes managing Apache, Redis, PostgreSQL, ..., in dedicated servers very easy and robust. Traget a popular and robust non-commercial distribution like Ubuntu LTE, and provide all is needed to deploy web nodes, database nodes, with backups, monitoring, and everything else trivial.

So the pitch is: clone Heroku, which has taken dozens of very smart engineer man-years to build and refine, then charge 5% of what the market will bear?

> "I can only write my Ruby code but can't handle operations" is not the right attitude, grow up.

I handled ops for 120+ Rails apps while managing a team of juniors and making time to write code. What a stupid waste of my time: ops is forever & never-ending, while implementing & delivering a new feature to 100K customers can bump sales' conversions permanently.

If I can outsource relatively-linearly-increasing Ops costs and instead focus on delivering value that multiplies compounding-interest style, that's not childish.

It's great business.

No, presumably the pitch is: clone Heroku's software stack as an OSS project, then get the server/VPS sellers to let people opt to install it as a package when they rent out a node, the same way things like Wordpress can automatically be installed.

Sure, see OpenStack: http://www.openstack.org/

[that said, comparing automated scaling of a Ruby on Rails SaaS app with 100K+ users to a one-click WordPress install is kinda humorous. Even WordPress has a market for expert DevOps guys to manage your site: http://wpengine.com]

Well, Herouk's stack may indeed be way more impressive in sheer scope, but for any one individual user, there's no difference.

As long as bringing up more than one node in your "application" gets them to start talking to one-another and auto-distributing load between them [including sometimes just electing one of them to serve as a router node that doesn't actually have apps running on it], your experience will be identical to paying Heroku, save for the fact that when one of the machines goes down--although the load will be redirected away from it--you'll have to "manually" fix it if you want it back.

In the default case, this just means dropping the IaaS node responsible and provisioning a new one [possibly on a different IaaS provider, if there's a lot of failure in one provider]. Though if you did pay for physical hardware, there can be some pain here. ;)

Basically, what I'm suggesting is a software stack that is to computation as Tahoe-LAFS is to storage. Just give it a set of machines that resemble Unix boxen--with more separate providers and regions = more better--and it'll give you something that looks like Heroku in exchange.

It could even have an optional provisioner service running atop it, that globally aggregates known IaaS providers and gives them ratings based on machine response times from the perspective of various other components, then lets you just say "okay, you're allowed $N/mo more to scale me up" and it'll find places around the globe where your users are being underserved, find well-rated API-compatible IaaS providers in those places, and provision nodes in those locations, adding them to your mesh. And then dropping them back out for alternatives if they start to suck :)

--you know, if this doesn't already exist, I might be willing to put in some time...

I don't think OpenStack is the right comparison to make to Heroku. In the common parlance, OpenStack is infrastructure as a service, while Heroku is platform as a service. Cloud Foundry http://cloudfoundry.com/ and OpenShift https://openshift.redhat.com/app/ are more comparable. They're both open source.

I think OpenStack, CloudFoundry, ..., are still not what I have in mind, as this solutions are more designed at scale, that is, if you want to provide a PaaS service to third parties or if you are a very large organization. IMHO the missing piece here is something that you can install in just one or a few nodes to start providing easy-to-setup and monitored services, with proven configurations and setups and so forth.

Something like TurnkeyLinux? http://www.turnkeylinux.org/

And there are some VERY good reasons to invest in DevOps even for Wordpress.

I'd write a lengthy post on this subject right here, but I already did so elsewhere: http://www.mmomeltingpot.com/2012/03/wpengine-review-after-1...

(And Patio11 wrote on the same topic a while ago, too: http://www.kalzumeus.com/2012/02/09/why-i-dont-host-my-own-b... )

That's what I think about your reasoning.

1) Once you develop a culture of PaaS the reality is, if you check the history of most startups, you'll continue along this way, and the money you'll burn will be massive. I suspect that if you build a sysop culture earlier, later you'll be able to just hire a full time sysop instead of spending a lot more.

2) If you don't understand very well your platform from the point of view of operations, likely you'll build a non scalable system (scalable not just from the point of view, let's distribute the load among N nodes, but about the constant times / CPU / energy it takes to serve a request). You'll end spending all the time again porting your app to another framework / language. This happens all the times.

3) The first months of a startup are usually not so critical from the point of view of operations, it is unlikely you'll spend a lot of time managing servers, unless...

Unless you selected a platform that is too complex to start with. I think that many of the PaaS companies I see today are here mainly for two reasons: Rails & Java frameworks.

So first of all, select your platform wisely.

Unless you selected a platform that is too complex to start with. I think that many of the PaaS companies I see today are here mainly for two reasons: Rails & Java frameworks.

Can't speak for Heroku but with EC2 you get the ability to dynamically add/remove instances. While this seems like it's needed only for certain kinds of startups, the reality is that most background processing is batch oriented and it's extremely cost effective to just spin up instances when I need them, crunch the data and terminate them after that. And, if you go for spot instances (and use a fault tolerant framework like Hadoop to distribute jobs), it's becomes even more cheaper.

I think EC2 is not quite "PaaS":

http://en.wikipedia.org/wiki/Platform_as_a_service

Since you still do need to administrate the instances you run.

> Unless you selected a platform that is too complex to start with. I think that many of the PaaS companies I see today are here mainly for two reasons: Rails & Java frameworks.

I think this is where I misunderstood you originally. For 3 days, Hacker News has been discussing the performance of -Rails- on Heroku. If I had understood at the beginning that your real argument is to use Sinatra/PHP/NodeJS/whatever (you're somewhat vague on recommended alternatives), I would not have jumped in. I do not have enough experience hosting other tech stacks at scale to be advising on the viability of open source solutions.

As for your other 3 points, presuming a Rails stack: all of those smell like a premature optimization for any company with less than 500K customers. If I went to my clients and said "Hey, we should invest 1-2 days in spooling up a server, because if we gain traction 6 months from now, we'll have to pay Heroku a lot of money until we fix it!", they would grin a bit and say:

"That would be a great problem to have. Now go back to shipping features so we gain traction and actually have to worry about fantastic problems like how to deal with having too many users."

Yes, features are important, and you don't want to waste your time doing stuff you can easily outsource. However, I think it's not about saving $2000 by outsourcing, it's really about understanding how your software runs. How each request is handled. How each layer and architecture affects scalability, performance and stability.

One of the things we've seen in this Rails/Heroku example is that the platform can't really be completely transparent. If you treat it as some obscure service and don't understand how it fits together - you lose. You can't optimize, you can't scale, you can't give consistent experience to your users.

I personally don't particularly like the distinction between devops and developers. I think all developers should have a good grasp of the platform. Of how pieces fit together. This is a worthwhile investment, not to save money on your PaaS, but to build a good solid app with good architecture. Performance, scalability and security are also features you should be shipping.

I'm not sure Rails and Java are the culprits. Rails deployment is actually not that difficult once you get a few things figured out.

Perhaps the problem is a generation that has grown up without looking under the hood as much, preferring the flashy "just works" Mac, for instance, to running Linux as a desktop OS and knowing something about how to administrate it it. That's a skill that may not allow you to be an admin for a big site, but should be enough to help you get a server up and running, and maintain it.

Also - and this is a positive development - as of late there has been more focus on making sure you've got something the market wants before you worry about scaling and another problems like that.

Still though, I think that it's not that hard to get a basic server up and running, and deploy to something you manage yourself. Amongst other things, it gives you way more flexibility than what something like Heroku can offer. Want to recompile Postgres yourself, with some funky option enabled? Not a problem!

David what you say is absolutely possible, that is, the reason could be more of a cultural / focus shift, but when I think to invest my money on a startup where the core guys can't, if they want, setup a server and run their operations if needed or fix a bug overnight understanding what's wrong in a server, I feel there is something wrong.

About the focus on making sure you build something the market wants, it is a good approach, but on the other side maybe the focus is just on that, and there is little interest about the ability to create a sustainable service where the only exit is not being acquired. A big part of being sustainable, especially with the freemium model, is cheap operations. It's a key value of being able to say to your users once you start to get some traction, ok, give me 5$ per month, and I'll be profitable.

From that point of view startups spending like 2000$ / month while not even remotely profitable while it is possible perhaps with more wise coding and in-house ops to spend 200$ seems very odd to me, and not a trend I want to see encouraged, so I posted my original message in order to provide, maybe with some provocation intent, a different point of view.

Just think for a moment if there are no longer big companies acquiring you (that is now the norm but it was not in the past) how the operations and costs point of view changes.

>"I can only write my Ruby code but can't handle operations" is not the right attitude, grow up.

How is such a condescending post at the top?

Everyone running a startup is an idiot because they choose not to waste their time on your priority?

Heroku isn't 10 times more and it wouldn't matter even if it was. Talented people are hard to find and spending time on operations when you might not be around in 4 months may not be the most important thing to focus on. On a 6 to 8 month time scale, heroku would be 10 times cheaper that taking the hit of setting up everything to emulate it. Deployments, backups, monitoring. Those things take a lot of time to setup correctly.

The annoying thing about that post is that it derails the conversation. The top post should be analyzing Heroku's response, whether it was sufficient or not. Or how developers can mitigate Heroku's dumb-by-design routing issue.

Right, I'm interested in XYZ, so that is what the top post should be ...

I run a startup that is hosted on Heroku. I write Ruby code but can't handle operations (I have and can set up servers but if shit hits the fan I wouldn't have a clue. Also I don't have the time). My startup is a one-man show. And you suggest I should grow up? By grow up you mean that I should watch my customers face days of downtime because I don't know how to fix the server, how to secure the server probably, how to scale or have money to hire someone who can?

Of the "ShitHNSays"-stuff I read here this surely takes the cake.

The primary bottleneck for most startups isn't money, it's time.

Also for most startups (assuming you're not doing something CPU/bandwidth heavy) the actual cost of hosting is going to be a relatively small part of the budget. If your burn rate is a million dollars, reducing 10k of hosting costs to 1k isn't really worth the effort.

Money can buy time in various forms. I think PaaS is one abstraction level too much to remain flexible and efficient as you grow.

Kind of depends

There's the "two guys in a dorm eating ramen" and there's the YC backed "startup" that already has a couple of hires

So if your monthly budget is of hundreds of dollars, using a VPS instead of Heroku makes sense

Let say your average http request takes 200ms to serve, then with 5 heroku worker dynos you can serve about 10 million requests a day which should comfortably cover the requirements of most startups.

How much do those dynos cost ? - $143/month. That's less than three hours salary for a developer.

If your monthly budget is hundreds of dollars I'm guessing your traffic is low enough you can just use the free tiers of heroku, appfog, etc.

Well the point of all this is that simple scaling math like that doesn't add up because of the queuing latency introduced by heroku's routing layer. But still at that scale your point is valid.

Yes, but there's a step before

$143 is money that is missed by a college student, for example.

Better go with something cheaper or the free tiers of Heroku, AWS, etc

You're probably still developing the system, or having only a small amount of requests.

10,000,000 requests each day are 115 requests per second. I don't follow your math here with a 200ms CPU time per request.

Heroku customers don't typically do math when they do capacity planning. That's part of the Operations toolchest they're buying. They just up/down dynos.

115/30 is almost 4, which is almost 5; 5*200ms = 1 second;

I guess he meant 10M/mo, not 10M/day.

Yes, my mistake.

And the real problem is the non-uniformity of the load. If your 10M/mo request start concentrating around weekends, you've got a problem... Except you haven't, as your infrastructure is elastic, and this is the real bonus.

Also, I'd be very afraid to get accidentally hit by HN traffic if I'd host my own server.

Definitely. This is possible with e.g. puppet already - where I work I've setup puppet modules for provisioning everything automatically for developers, they just need to enter the customer name and whether they need dev, stage and/or live for that customer - the rest is automated. We use http://www.hetzner.de/en/hosting/produktmatrix/rootserver-pr... for hosting - let me just say that I can buy an entire rack with 64 GB ram in each server, for the same cost as one amazon instance :D

We're also looking into Cloud Foundry - basically Open Source Heroku - with support for buildpacks. If the installations gets easy enough, this could be the new thing.

This feels like a distraction. How about instead of pontificating on how someone else chooses to do business, we discuss the actual merits (or lack thereof) of Heroku's routing issues.

That business model is basically what Cloud66 seems to be doing: https://www.cloud66.com/

Looks pretty decent, would make sense to see something similar for other stacks.

It's more like 10x from Heroku to AWS, then another order of magnitude to metal. AWS has other advantages in addition to convenience, though.

My thoughts exactly. Like you don't outsource dev, you can't outsource sysops, it's a core competency to a tech startup.

Is it not more like you can't outsource customer support and product development, but you'd better outsource everything else if it's economically viable?

Thus if your product is some kind of hosting (i.e. blog or image hosting), the reliability is your product, so you don't outsource sysops, but if you offer some project management software... Well it's almost certainly hosted so reliability is your product again and you better have your own sysops.

So the only viable conclusion seems like you limit your trust to the PaaS provider and have some plan for the rare case when they get screwed. Or you could bet on technology not requiring such monstrous resources as Rails and host your entire MegaCorp on a single server rack.

Fail fast.

I can perfectly well install, set up and maintain my own Ruby servers - but it takes time.

Alternatively, I can pay someone else to do that, and remove that timesink from the elapsed time between "start developing" and "find out how well we've achieved market fit".

I can always optimise later - move off Heroku, develop our own load balancing, all that stuff. Once I've got a working product/market fit, I probably will.

But doing that before I know if I'm going to chuck the entire infrastructure in the garbage and move on to idea #2 (and #3, and #4...), or indeed pivot so wildly that we'll have to reorganise all our server stuff anyway, is a waste of time. And time is valuable.

Chef/Puppet/Stackscripts/Salt/etc, and develop your own load balancing? Why on earth would you do that instead of just using HAProxy?

Misspoke - when I said "develop our own load balancing", I meant "test and pick the best existing load balancing solution, then implement that on our servers". That's as opposed to "use whatever our hosting provider offers".

If your Ruby code deploys to X you should know X, if it's part of your stack it should be part of your toolbox.

"create software that makes managing Apache, Redis, PostgreSQL" Like Plesk, but better, faster and less resource hungry.

I'm honestly surprised there aren't tools available now replicating what Heroku does.

We should have puppet scripts to deploy, instrument and manage all the popular infrastructure choices by now.

The same way originally Linux was a build it yourself box of parts, we ought to have "cloud infrastructure" distributions, from bootup to app deployment.

The neat thing here is that as people improve the distribution you get cumulative savings. Back in the 90's you needed a skilled individual to setup a Unix/Linux system. Now, even an MBA can do it. The same could happen with infrastructure on a higher level.

" If you sum EC2 and Heroku you are going to pay like 10x what it takes to run the same machines power in a dedicated server, all this because you can't handle the operations? This is absurd IMHO."

It really depends. My current experience with heroku is that it is absurdly cheap - at least, for our use cases. We would have to do a lot more traffic for us to ever consider moving to a colo.

Not to mention I'd bet that they do have someone spending all their time dealing with Heroku ops... and my sense is it's not just because of this bug.

Inaka has a combined total of close to a billion pageviews/month across all our EC2-hosted apps for all of our clients and we have zero full time operations staff - we have 2 guys that spend (much less than) part time on it.

This seems to me like the server admin version of "build a website like Amazon."

http://news.ycombinator.com/item?id=5222581

What's more likely, that everyone else in the world is too dumb to see this opportunity, or that perhaps you have underestimated how hard it is to do?

Is Canonicals Juju along the lines of what you mean? https://juju.ubuntu.com/