The Cloud Is Not for You

This article would be better if it were properly titled: "The Cloud is Not For Me".<p>The anecdote provided here – about a specific app with a specific architecture and a specific load profile, deployed by specific employees with specific skills at a specific company with a specific budget, a specific revenue model, and a specific schedule – is fine as anecdotes go, but you can't draw a general conclusion from it. Change any of those specifics and the conclusion may be entirely different.

This article is patently false and annoyingly severe. I used to run the backend of Dropbox and I can say without uncertainty that the cloud (AWS in our case) is incredibly useful. I would go so far as to say that the cloud IS for you, and probably for everyone until it really makes sense to move off. You may have had a bad experience with an off-the-shelf scaling solution, but that does not implicate "the cloud."<p>- Sometimes you just don't know whether your traffic is going to spike 10% or 100%. And I'm not talking about one or two computers, I'm talking about adding hundreds. Are you sure your supplier has everything in stock for a rushed overnight order? Your exact hard drive model? Your aging CPU? You're seriously going to experiment with a new batch of shit and tell your team to spend all night wiring all of those racks? Do you even have the space left in your cage? Enough space on your routers? Enough power? Even if you're in managed hosting like SoftLayer, these are now their issues and Not Their Problem if they can't turn around for you in the time you need.<p>- In the time we were on the cloud we were better able to understand our hardware needs so that we could actually spec out machines optimally. Even better, technology improved considerably to bring us low-cost SSDs which wouldn't have been possible at the start.<p>- There was no way we could manage these servers and a datacenter without a dedicated network engineer and an SRE. And even that was pushing it. If you've ever tried to hire these positions, it's even harder to find good ones than software engineering. We got really lucky. Also, you've spent a lot of time on your engineering interview process and you have it down -- now do the same for two more positions that you know much less about.<p>- There is a huge engineering cost to moving off and building your own tools. Two servers? OK. Two thousand? Different ball game.<p>- I would argue that even a company like Google uses essentially a cloud solution that they've built internally and made available to their teams. AWS helps make a piece of that accessible for the rest of us.<p>TLDR: I thought I was hot shit too when I ran a Newegg server off my parents' internet connection, but come back when you're pulling down a megawatt and tell me the cloud sucks.

I think Heroku is a great tradeoff for brand-new startups that are cash-strapped and also have no sysadmin capabilities.<p>Buying your own hardware - or using a blank VM provided by a VPS company - and setting them up immediately puts you in sysadmin mode from day one. New apache vulnerability? Your problem. Operating system upgrade? That's you, too.<p>What about security? Do you know all the ways that bad people can get into your system? How do you lock it down? Do you know how to properly configure the firewall?<p>What about a hardware failure? Now you're running back and forth from Fry's to your datacenter. Or in a VPS - you're going to have downtime while your provider moves your VM to another box. Depending on the scale of the outage, you could be down for a long time. Ugh.<p>Yes, Heroku is more expensive than your own hardware. So are tons of other VPS/VM hosting facilities out there.<p>Personally, I also really like RailsMachine. They built something called Moonshine (<a href="https://github.com/railsmachine/moonshine" rel="nofollow">https://github.com/railsmachine/moonshine</a>) that uses Puppet and Ubuntu to spin up properly configured, locked-down servers at the drop of a hat. I'd try something like that before managing my own infrastructure as an early-stage startup.<p>Some things are better outsourced; as a startup your most valuable currency is not a few hundred dollars per month - but your time. Wasting it playing sysadmin isn't worth the cost.

Happy user of both Heroku and (recently) GetSentry here.<p>I think the author may be undervaluing how useful it was to, "for the first couple of months", survive on the off-the-shelf offerings. He didn't have to spend 3 days learning server configurations. He could instead expand his service "to cover nearly all popular languages".<p>He only had to switch -- spending effort on researching alternatives and learning new systems -- <i>after</i> knowing the growth path of his business, the pain-points of his architecture, and the baseline costs of a cloud solution. Heroku's turnkey environment, warts and all, got him to the point where he knew enough about his business situation to make rational optimization changes.<p>And if the 'shape' of his architecture, growth, and personal expertise was slightly different, he might be just adding dynos and upgrades inside the Heroku system today, happy to be paying them far more than his peak $700 cloud bill.

The problem is not that the cloud is not for you / others.<p>The problem is that you chose the wrong kind of cloud platform for your app, and instead of choosing the right kind, went right back to the early 2000's and rented some physical boxes instead. In doing so, you've flipped your pros and cons lists, but you haven't solved the actual problems.<p>Heroku is a PaaS cloud platform. Zero server awareness or maintenance. An app only environment.<p>You would have been better off using an IaaS cloud, where you have to rent instances and install apps, but you still have the benefit of instant, (potentially automated) scalability, intrinsic high availability and minimal maintenance.<p>Instead, you're renting physical servers which often have a long term commitment, can potentially drop off the air for any reason - such as drive failure, power supply failure - and then you'd have to rebuild.<p>I think the cloud almost certainly is for everyone, but you need to use the right kind of tool for the job.

This article is painting with far too large a brush. Heroku is not The Cloud, it's just a little piece of it.<p>When you use Heroku you are paying a premium for the platform. You do this because it saves you sysadmin duties, and you pay a premium in terms of base cost as well as flexibility. Obviously it only makes sense if the platform suits your app.<p>If you want to manage your servers yourself you will save a ton of money and gain a ton of flexibility. But does this mean you should reject the cloud and order some servers and start shopping for colocation facilities right away? No, you still have dozens of competing choices for how to get your vanilla linux boxen up and running, some of them fall under the purview of "the cloud" and some of them don't. These choices become very interesting based on your specific requirements. Sure raw EC2 is going to charge more than buying your own server, but if you buy reserved instances and factor in the colocation costs it's actually not <i>that</i> much more, and you may have many other reasons to look at it. For instance maybe you push a lot of data to and from S3 and you want it to be fast, or maybe you want to easily put identical deployments in Europe, Asia and South America for your global customers.<p>Beyond that, the premise that the cloud is somehow a big pain in the ass and owning your own hardware does not really wash. They both can utilize chef/puppet equally well, and being able to programmatically commission hardware is a huge convenience, the learning curve notwithstanding.<p>I also don't like hosting substantial apps of any kind on Heroku for some of the reasons the OA touches on, but that is not an indictment of cloud hosting in general. This article jumps to conclusions far too hastily and then arrogantly proclaims their generality with the threadbarest of anecdotes.

Wow where to begin. Yeah with the title hehe: 'You' in a title obviously means 'Me'.<p>&#62; Almost any company worth a damn can bring online a server within 24 hours<p>I know a few companies 'worth a damn lot more than a damn' that can't bring a physical server up within 24 hours unless someone happens to have a spare box with the right specs lying around (unlikely). If they need multiple boxes, well, good luck with that.<p>But perhaps more importantly, I know of no companies that can get rid of a now unnecessary server quickly and at no cost.<p>The idea that 'capacity planning' is the best approach to scaling in 99% of the cases is laughable.<p>Someone who can bring up, configure, secure and monitor a custom backend in a few days is someone versed in operations, even if his day job is development.

Oh nice, another cloud thread.<p>I'll just utter my standard: The cloud is great for very small and very large deployments.<p>If you're in the middle, rent servers.

The term "Cloud" can meet a number of different functional definitions. In this article's case, this was a PAAS model where you upload your code, choose the supporting services, and expect a given service level in return. For some, this works great, for others - well, see the OP blog post.<p>In my organization's case, we run all of our infrastructure "in the cloud" - mostly AWS. But, we view AWS as an <i>infrastructure</i> cloud provider meaning we choose the hardware available, develop and run our own stack, and go from there. We also have infrastructure with ServerBeach and 100TB.com - and, yes, we consider that "cloud" as well. Just because your code doesn't run well on a PAAS cloud provider doesn't mean that my code won't prosper on a "cloud" infrastructure provider.<p>Here is the deal: if you've never seen, in person, the server that you are paying for - you are in the "the cloud." And that is going to be most of us out there. And for those of you that "own" your own boxes, that still doesn't mean you aren't "in the cloud" - because you probably setup your <i>own internal cloud</i> at that point.<p>Edit: SAAS to PAAS

For small stuff Heroku is great. We're an ad agency doing a bunch of small sites and Facebook games with little traffic (small marketplace). The cost is spread out over many clients and it works out for everyone. That's the opposite of the scenario this article presents: one API with one database and one party that pays the bill. We have very low hardware requirements, but would like to manage as little as possible.<p>PHP/MySQL shared hosting was always the best way to get a site up quickly (cheap, reliably and fast). Now finally there is a comparable hosting option for simple stuff written in Python/Ruby/..?

The benefit of running on Heroku is time savings. Not scaling. If I hit a scaling problem, that's a good sign that I am growing. Right now, I have no scaling issues because we aren't big enough so the savings of hiring a dev ops or learning chef while I make my product better is where the plus is.<p>Yes you become reliant upon the cloud, but it is only temporary. Buying faster hardware isn't hard

Just to start some discussion on the dismissal of instant scalability: "Almost any company worth a damn can bring online a server within 24 hours, even budget companies. When have you actually needed turnaround time faster than that? If you did, maybe you should read up on capacity planning."<p>Realistically it is often very hard (impossible) to predict how viral something new is going to go. If some "superstar" grabs onto your app and publicizes it in front of 10x your normal audience, 24 hour turn around may not be fast enough.

It feels awfully ironic that a SaaS provider is telling me that the Cloud is not for You.<p>If it isn't, then why would I purchase a GoSentry licence instead of just self-hosting Sentry and avoiding the $99 fee

How much does Heroku actually cost? I have the impression that its a ripoff if you need a few databases. Like you could get a Linode or Rackspace for $20 or $10 a month or you could get Heroku set up with a few "addons" and get jacked.<p>Even for Linode or Rackspace though, I think that there is still room for much better prices for larger instances though for sure.<p>Also, if you don't want to set up the VPS, Linode has StackScripts, or (shameless plug), if you are into Node.js, I am only charging about $1.85 more per month than Rackspace for a VPS with my image that already has MongoDB, nginx and redis setup. <a href="http://cure.willsave.me" rel="nofollow">http://cure.willsave.me</a>

So, I've actually had completely the opposite experience using Heroku.<p>I work at a telecom company that heavily relies on python (and Django) for our front-end and backend--and processes millions of API requests per month.<p>Initially--we started out running our entire web stack on our physically colocated hardware. This was a tremendous pain for us, for numerous reasons:<p>- Investing in hardware requires lots of time to shop around, purchase hardware, and do capacity planning.<p>- It requires physical work (in our case, multiple trips across the US) to setup / provision / bootstrap our servers.<p>- Automatic maintenance (through puppet, in our case) required constant meddling to handle edge cases, and robbed us of hundreds of man hours in the process.<p>- Regardless of how excellent your puppet (or chef scripts) are, you will unquestionably have to do a lot of maintenance work to keep things running smooth through OS updates, new software releases, etc.<p>- Scaling up on hardware is a pain for small companies, as it requires so much time and supervision.<p>I made the choice to migrate all our stuff to Heroku after an enormous comparison of services available (we actually migrated to Rackspace for a while before Heroku), and finding myself completely unsatisfied with options.<p>Moving to Heroku was an incredibly great decision for us:<p>- Our operations time went from hundreds of hours per month to none.<p>- With our extra engineering time freed up, we released numerous new features in the following two months and doubled our userbase.<p>- The cost for running our web infrastructure dropped by a significant portion, not only because of engineering time saved--but also because it was incredibly easy to scale up (and down) our entire infrastructure when needed, as opposed to wasting money on static physical resources that can't be adjusted for need.<p>- Our bandwidth cost dropped to 0 (bandwidth is provided free on Heroku).<p>- We don't have to run any duplicate services, since we can rely on Heroku's load balancer, dyno dispatcher, fully managed databases, and monitoring (via newrelic).<p>- We have automatic (free) database backups via Heroku's pgbackup service.<p>- We can instantly add read slaves, test changes on duplicate masters, etc. (all for free).<p>In regards to the 'poor performance' mention in this article--since there is no data or numbers listed, I can only assume that the author didn't have any monitoring software or management software setup. I've found that using newrelic (a Heroku addon service) gives you more than enough detail and granularity to see how your dynos perform, which tasks take up CPU, which tasks take up memory, and how to properly handle capacity planning.<p>All in all--I feel like this is a good topic for an article, but that it seems to be poorly researched. Sure, hardware can outperform a cloud service if you compare a virtual dyno to a physical server--but at what cost?<p>- High upfront purchasing cost.<p>- Physical maintenance required.<p>- Operations work required.<p>- Must implement your own redundancy of services (backup load balancer, backup database, backup caching servers, etc.)--these all add extra hardware costs.<p>- Custom monitoring solutions must be implemented.<p>- No automatic recovery from faults.<p>- Large time investment to keep things running.<p>I disagree with the premise that 'The cloud is not for you.' I'd actually argue that the opposite is true.

Can anyone recommend a primer on the sort of scalability issues the author mentions? Some textbook or series of blog posts I can read?