12 ms·

Goodbye Heroku

218 points by bcardarella 12y ago

sync 12y ago
So how do you scale out to multiple droplets on Digital Ocean? Set up your own HAProxy instance? What do you do when one of your droplets disappears or crashes? Where do you host your database? Not quizzing, real questions from someone also looking to drop heroku.
- opendais 12y ago
  I'd suggest using Linode over Digital Ocean. They already are the same price/performance [roughly, unless you are buying DO's $5 nodes]. They also have stuff like load balancers built out and are reasonably reliable [although only at the datacenter level, they don't have multi-DC load balancers]: https://www.linode.com/nodebalancers https://www.linode.com/nodebalancers
  - bcardarella 12y ago
    I am a big Linode fan and I hadn't realized they price-matched DO. Thank you for the info.
    - opendais 12y ago
      Ya, they shuffled their prices a month or so ago: https://www.linode.com/pricing https://www.linode.com/pricing Its the same 1 Core / 1GB == $10 pricing DO uses. [roughly]
    - rwg 12y ago
      Be warned that Linode's status page is also borderline useless. Their website and web-based management interface (and API, according to customers on their IRC channel) were throwing 500 Internal Server Errors for >2 hours the other night, and their status page never had any mention of it.
      - jebblue 12y ago
        In 4 year it's always worked for me. edit: years
  - pc86 12y ago
    Just a counterpoint as someone who switched from Linode to DO (and indeed have used mostly their $5 nodes) and currently uses a mix of DO and Azure: You need to be comfortable with command-line server administration to use Linode. Yes, they've got tutorials, and they're pretty good. You can be walked through installing __________ on whatever specific flavor of OS you happen to be running. But the moment something goes wrong or I had a slightly-above-novice-level question, the response was that Linode did not offer that level of support and it was a self-managed server (or whatever the specific language was). Not complaining, that was exactly what I was paying for, but it's certainly something to take into consideration if you're not comfortable with command-line server admin.
    - opendais 12y ago
      DO is pretty much the same as Linode in that respect. You have tutorials and command line comfort as the basic requirement for using the product. Both the parent and the OP both suggested switching to DO which is the point of comparison. I've never had better support/more comprehensive with DO than Linode. Then again, I've had a Linode account for like 6 years and I think I've opened as many tickets. ;)
  - albertoleal 12y ago
    Just curious, because I plan on using node balancers. Does node balancers only pool bandwidth on linode instances on the DC the node balancer is in?
    - opendais 12y ago
      Don't trust me <3 Ask their support. I believe its all of them: https://blog.linode.com/2010/02/08/bandwidth-pooling/ https://blog.linode.com/2010/02/08/bandwidth-pooling/
- nirvdrum 12y ago
  There's a few options out there. You can treat DO as a compute-only EC2 if you'd like. I work on a project called Rubber [1] that can provision servers and templates for you. DO is one of the supported providers. We've taken care of a lot of the annoying stuff for you, like mapping security group rules back to iptables, setting up DB replication, off-site backups to S3, and so on. You'd likely be able to do the same with chef, ansible, puppet or whatever else. I don't have deep experience with those options, so I can't really speak to them. [1] -- http://rubber.io/ http://rubber.io/
  - Lazare 12y ago
    Rubber looks quite interesting. Is it Rails only?
    - nirvdrum 12y ago
      Nope. It's got a Ruby inclination, but it's something we're divorcing ourselves from. Deploying Sinatra and other non-Rails, Ruby apps is pretty straightforward. Deploying non-Ruby apps is certainly doable but currently requires a bit of creativity (I've deployed Java and Scala apps with it).
      - bdcravens 12y ago
        It also spins up other server types like Selenium. (I do alot with Selenium, and even have an accepted pull request in Rubber's Selenium implementation)
    - gnepzhao 12y ago
      Checkout visualops.io. We are language-independent devops automation service. Similar value with Heroku: autoscaling, auto-healing, push-to-deploy, but not blackbox. Instances runs in your own account. Even if we go down, your app will not be impacted.
    - deleted 12y ago
      [deleted]
  - 12y ago
- king_magic 12y ago
  I've been trying out Dokku (https://github.com/progrium/dokku https://github.com/progrium/dokku) as a Heroku alternative. DigitalOcean has a nice VM template for Dokku; I think Linode has something like it too (or instructions for setting up Dokku). So far, I like it; Dokku is pretty slick. Deployments are more or less the same as Heroku - "git push dokku master", in the case of my Rails app. But that said, assuming Heroku's security is super tight, I have a bit of work to do to secure my droplet. I'll probably still have to scale myself (or just switch to Linode and use their load balancer), and with Dokku I've got a PostgreSQL DB in my Dokku container. Droplets disappearing or crashing... not sure, but I sure hope DigitalOcean's backups are good :)
  - sleight42 12y ago
    I'll probably still have to scale myself... This sounds painful. Dokku is only a single VM solution though, right? Flynn (http://flynn.io http://flynn.io), the all grown up Dokku, isn't production ready yet. I'd love to hear that I'm wrong and that scaling up with Dokku is a piece of cake. If so, please correct me!
    - alextgordon 12y ago
      Just curious, what are you guys doing that you need to "scale up"? Even if you get a hundred thousand hits in an hour, that's only 28 per second. I am pretty sure even my toaster can handle that. I've been fireballed, HN'd, reddited, etc. All on my little 256MB Linode instance (now 1024). It has never been anything but zippy.
      - king_magic 12y ago
        Currently - nothing that needs scaling for my personal projects. However, as a consultant, it's very possible that a large client may need to scale (dealing with this right now on Azure), so I like to be prepared with options. That said, I know better than to put Dokku in production for a client - at least not until it significantly matures :)
      - voltagex_ 12y ago
- grey-area 12y ago
  Not the OP, but if you're looking to drop Heroku (because of cost, or reliability?), it's not that hard to host your own on a VPS or dedicated servers. Set up your own HAProxy instance? https://www.digitalocean.com/community/tutorials/how-to-use-haproxy-to-set-up-http-load-balancing-on-an-ubuntu-vps https://www.digitalocean.com/community/tutorials/how-to-use-... Setting it up doesn't look too hard, and you're not going to need it until you reach significant scale - so probably 90% of the people reading this without a dedicated ops team aren't ever going to need it. Startups often seem to over-engineer servers at an early stage or assume they'll need a massive cluster when a single server with multiple processes could serve perfectly well till you actually hit some sort of scaling problem (i.e. millions of users a month). As an example, the HN website ran for a long time on one server (not sure what they use now, but it's not heroku :). Very large VPS instances often cost less than scaling with heroku. Also, other providers like Linode offer load balancers without setup for a low cost. What do you do when one of your droplets disappears or crashes? ansible myserverplaybook.yml to set up another one in a few minutes. But you'll find this just isn't necessary unless the server config changes - uptime will be measured in months on most providers (not sure about DO in particular, haven't hosted anything serious there). Where do you host your database? On another DO droplet, with remote backups, or even on the same one if you have a sizeable VPS and low to moderate traffic.
- nlh 12y ago
  I haven't deployed with them yet, but have been seriously considering making the switch to Cloud66 (http://www.cloud66.com/ http://www.cloud66.com/). It looks like the best of both worlds -- higher level than Dokku, but choices when it comes to the underlying infrastructure provider (Linode, DigitalOcean, AWS, or some combination). Small overhead charge for the management which seems very reasonable, otherwise you're just paying for the (virtual) metal from the IaaS guys.
  - jevyjevjevs 12y ago
    I've been really happy with cloud66. Discovering new features everyday that saves me from having to build nginx/postgres/passenger from scratch. Try it out, I think you'll find it provides the balance you seek.
  - bdcravens 12y ago
    We've been using Cloud66 for a couple of months now. You may find yourself tweaking the manifest files, though. It's not immutable architecture, but rather, they deploy over and over using Capistrano. So over time you'll build up some artifacts/cruft, especially if you're doing anything that generates a lot of log files. Not a problem, but you'll want to configure it to use instances with enough storage, which in a default config is often only 8GB.
- stollercyrus 12y ago
  Here are some puppet manifests I put together for hosting ruby (in my case rails) apps on Digital Ocean that you might find helpful. https://github.com/cyrusstoller/gardenbed https://github.com/cyrusstoller/gardenbed It sets up postgres/rbenv/nginx/ s3 db backups etc ...
drovido 12y ago
I am not a Heroku customer and maybe there is more substance to his complaints but I didn't see anything in the post that would cause him to want to leave his hosting provider with guns blazing like this. Reduce their prices because their service providers have reduced their rates? Seriously which company you know does that? Do we even know what arrangement Heroku has with amazon? Isn't it possible that as a large customer their rates are already discounted. On the subject of downtime he didn't actually say that his application was down as a result of the maintenance in this instance or any other.
parasubvert 12y ago
"Buildpacks are just terrible." Elaborate please? CF uses a variant of them, and they're ultimately just a simple three-script harness to build and run your app. There are pros/cons vs. dockerfiles , chef/puppet/ansible, or just doing a Netflix style Aminator, I suppose, but "terrible" seems exagerrated.
- bcardarella 12y ago
  Customization. Ever try to add a command-line tool to a buildpack? I don't understand why we cannot make use of apt as the EC2 instances that Heroku uses are just Ubuntu AMIs.
  - parasubvert 12y ago
    Sure. You can't make assumptions about the base distro with buildpacks, which is why you curl/untar dependencies. Dockerfiles are a bit better by allowing you to pick the base image (and thus distro), though there are tradeoffs with that too.
  - latchkey 12y ago
    It's a pain, but it isn't the end of the world or a disaster. I distribut some CLI tools with a NodeJS app I wrote. Here's the docs: https://github.com/lookfirst/convert/wiki/Compile https://github.com/lookfirst/convert/wiki/Compile
- cschmidt 12y ago
  I've found them to be fairly terrible. They work great until you need to do more than use pip to install stuff (I'm using python). So things as simple as matplotlib get hairy. You have to use a custom buildpack someone contributed (which is based on an old version). Now say I want to use python with R. It is a huge pain. You have to use heroku-buildpack-multi [1]. The problem is that environment variables and installed code from the first buildpack are invisible to the second. So you end up having to hack individual buildpacks, which is just gross. It worked in the end, but I wasted days on it. A concept like docker, where you fire up a container, install stuff with apt-get, and then save the results is greatly superior. [1] https://github.com/ddollar/heroku-buildpack-multi https://github.com/ddollar/heroku-buildpack-multi
nonane 12y ago
What are the alternatives to Heroku? I'm looking for something that makes it easy to deploy and launch services. http://deis.io http://deis.io looks promising but it isn't production ready yet.
- cobrabyte 12y ago
  We've been pretty happy with Cloud66 (www.cloud66.com).
- gabrtv 12y ago
  Deis has quite a few successful deployments in the wild. Most of the work being done today is around automated testing, platform hardening, HA/failure modes, etc. A stable release is not far away.
  - nonane 12y ago
    Who is Deis targeted towards? I'm a regular developer with little real world Ops experience. Will Deis be a good fit for me? From the docs it looks like Deis reuqires an advanced Ops person to manage a cluster of Deis machines.
    - gabrtv 12y ago
      Deis is for software teams who need to operate their own servers (for a variety of reasons). If you're a "regular developer with little real world Ops experience", I personally recommend sticking with Heroku or equivalent hosted services despite the occasional outages.
- king_magic 12y ago
  I literally just discovered Dokku (https://github.com/progrium/dokku https://github.com/progrium/dokku) yesterday - a "Docker powered mini-Heroku in around 100 lines of Bash". You can roll your own PaaS infrastructure on your own VMs. It took a few hours, but I was able to get my Heroku-based Rails app up and running on a Dokku droplet (to be fair, the most time-consuming part was getting the SSH keys right and figuring out that I needed a domain name - e.g., couldn't just set it up with a droplet's IP address - at least not with the DigitalOcean tutorial's instructions: https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-dokku-application https://www.digitalocean.com/community/tutorials/how-to-use-...).
calgaryeng 12y ago
s/mainteance/maintenance/
m0th87 12y ago
We're working on switching from Heroku to EC2. To my knowledge there isn't a lot of documentation out there on this process - we're just looking for code snippets to figure out how to build AMIs, deploy, etc. It's a slow and error-prone process. Anyone know of good resources to make this migration?
- infecto 12y ago
  I have never seen any documentation on moving from Heroku > EC2. They are very different services and there are many options to replicate the heroku api. Not used it yet but www.cloud66.com always interested me.
- deleted 12y ago
  [deleted]
- eknkc 12y ago
  Take a look at Elastic Beanstalk too. We use eb with docker containers and it has been pretty decent. Handles auto scaling, load balancing, fault recovery, deployment itself, and Docker provides great flexibility.
- parasubvert 12y ago
  I'd suggest looking at AWS OpsWorks, which is probably closest to what you're used to. http://www.stefanwrobel.com/heroku-to-opsworks http://www.stefanwrobel.com/heroku-to-opsworks http://artsy.github.io/blog/2013/08/27/introduction-to-aws-opsworks/ http://artsy.github.io/blog/2013/08/27/introduction-to-aws-o...
  - anko 12y ago
    I second this. I got up and running on opsworks in about 3 days without any AWS or Chef experience (I use puppet on our other providers).
- tbronchain 12y ago
  We are currently working on a product based on AWS that could fit your needs, giving you as flexibility as you can get with a manual EC2 configuration, but with the simplicity of a service like Heroku and the reliability of a service like OpsWorks: visualops.io Don't hesitate to contact with us if you have any remark or question. Also, we recently released a "store" comporting some template of common application to help people coming from PaaS platforms: store.visualops.io
braydenjw 12y ago
I'm wary about a lot of these SASS/PASS/IASS services. The "don't put all your eggs in one basket" cliche comes to mind.
meritt 12y ago
All these companies leaving Heroku and other PaaS providers is definitely a blessing for the thousands of unemployed devops & sysadmins out there.
- lucisferre 12y ago
  I can't say I meet all that many who are unemployed. Maybe that's just me.
  - meritt 12y ago
    Our last engineering job req we received about 10 sysadmin applicants almost all of which started with a "I know I'm not an exact fit but..." sort of line. Maybe it was just an oddity.
    - incision 12y ago
      >'Maybe it was just an oddity.' I think there's a reason, but it's not outright unemployment - yet. On the enterprise side what I'm seeing are traditional sysadmin positions being eaten up by aggressive VARs and software vendors. They all have XaaS plays now and they're targeting their existing customers first. The pitch is literally... "Hey, I can save you $350K/yr. Just fire your ________ team and use our PaaS. We'll perform the migration for free." Assuming the organization doesn't want to pursue their own internal or lower-level external service it leaves the sysadmins to either somehow make the leap to administering a provider system or diversify into other roles where they don't exactly fit.
- spudlyo 12y ago
  If any of the thousands of unemployed devops & sysadmin types out there are reading this: Twitter is looking to fill five open SRE positions in San Francisco[1] and two in Seattle[2]. [1] https://about.twitter.com/careers/locations/san-francisco https://about.twitter.com/careers/locations/san-francisco [2] https://about.twitter.com/careers/locations/seattle https://about.twitter.com/careers/locations/seattle If you'd like to know more about the SRE org at Twitter (Seattle in particular) drop me a line. My email address is in my profile.
_bpo 12y ago
The idea that maintenance should not be done during the day is a bit antiquarian. Scheduled maintenance should take place during their company's workday when they have as many people as possible available, feeling awake, well-rested and not distracted by the things they might prefer to do with their evenings and weekends off work. Of course, scheduled downtime should be done in off-hours, but modern services like Heroku don't have scheduled downtime.
- ryanbrunner 12y ago
  I agree with this argument, but there's plenty of work hours in the day, and 2 PM Eastern is just about the worst one to pick. We try to start scheduled maintenance around 8 AM - that way we have fully refreshed devs ready to address any problems, and if something does go wrong, it's a relatively low-traffic time for our application.
  - _bpo 12y ago
    The reality is that there is no good time for a large-scale platform to go down. I'd speculate that 8am PDT would be worse for Heroku, as their business seems largely split between the US and Europe, so downtime then would upset everyone... but that's just speculation. You can't build a company of developers selling products to developers while fleeing the working hours of developers.
- jonahx 12y ago
  What is the definition of maintenance? Is it work that they don't expect will cause downtime but has some chance of causing downtime?
  - _bpo 12y ago
    The scheduled maintenance notice said: During this time, Heroku command line tools and web interface actions to create and restart dynos can be delayed. So it was expected to slow the performance of some queues.
hunvreus 12y ago
Heroku is a great way to get started fast without having to worry about anything related to operations. That being said, you're effectively outsourcing your entire ops/DevOps to a third party. You don't set the rules, you don't get to argue about the best scaling strategy, and overall your infrastructure is pretty much a black-box. I've seen a fair amount of people who loved Heroku for ramping up apps only to feel trapped once they started scaling their service. PaaS definitely has its use case, but I wouldn't recommend it for anything beyond prototyping. In fact (shameless plug), this is why I've been working on devo.ps, to lower the barriers of entries to managing your own servers (on AWS, Rackspace, Digital Ocean, Linode...) using tools familiar to developers (Git + YAML). @bcardarella happy to add you to our beta testers; we'd love to get feedback from a heavy Heroku user. Email is in my profile. If there are other Heroku users affected, drop me a line and I'll see if we can help you get set up on your own infrastructure with devo.ps.
- morenoh149 12y ago
  no blog updates since '13 tsk tsk. I was excited.
  - hunvreus 12y ago
    We've been busy building stuff and talking with users. We actually have the new landing page and a couple blog posts coming out this week.
AdrianRossouw 12y ago
We're actually busy doing a similar move. fwiw, here's some resources i collected around docker. http://wayfinder.co/pathways/53619274d95a741100e7f203/docker-based-paas-wip http://wayfinder.co/pathways/53619274d95a741100e7f203/docker... It's a few weeks old, but of those the one that came closest to our needs was Deis.
slb350 12y ago
I'm a devops engineer and I never really saw the draw of Heroku or EY after you scale out to a certain size. EC2 is extremely easy to work with and there's tons of documentation out there. Once you setup your CI & CD, write your cookbooks and capistrano (or whatever), it's nearly hands off.
- robalfonso 12y ago
  I'm in your boat, but you have to realize that heroku is not targeted for anyone who is comfortable doing top to bottom provisioning of their environment. I also think their value proposition is a "grow with us" type situation: get you in the door for cheap and then as you grow you just keep bumping resources up.
- andy_ppp 12y ago
  Heroku is the dreamweaver of devops... but you know developers often don't have the time to spend 2 months+ learning how to do it right (hence your job title :-D). And for my small app I'll wager that Heroku has infinitely better uptime than I would manage!
michaelbuckbee 12y ago
Heroku's defining characteristic has always been that it radically reduces the sysadmin surface area of my app stack to something I can reasonably handle. So, while things like Dokku, etc. are really interesting they don't seem to be actually expanding the number of app-stack layers that I'd need to know to properly secure and maintain a server. Am I missing something?
lucisferre 12y ago
Heroku does have it's problems but if I'm being honest I don't have the time to spend using anything else right now. Perhaps when I hit a larger scale/stage I'll reconsider that, but at this stage there really isn't anything better.
alrs 12y ago
Deployment and maintenance should not happen in the middle of the night. We've known this for years. You design your systems to degrade gracefully, hopefully transparently. Screwing up your engineers' sleep schedules is a terrible idea, so you deploy during the day when people are awake, clear-headed, and on the clock. I'll take a 1PM outage over a 1AM outage any day. If that's bad for business, business should pay for the engineering time to build a more resilient system.
- jerhinesmith 12y ago
  Is that true? I'm not being sarcastic -- I just have always generally assumed that maintenance was better performed "off-hours". Also, 1pm and 1am aren't the only options. 8am EDT would have been within the work day but still avoided peak usage in the US.
  - alrs 12y ago
    8AM EDT is 5AM PDT, which is where web tech can be found in the United States. I'm sure you can find engineers willing to work garbage-man hours, but it's gonna cost you.
    - personZ 12y ago
      8AM EDT is 5AM PDT, which is where web tech can be found in the United States. I'm not sure if you're just being sarcastic, but talent in North America isn't limited to the Pacific Timezone, and such a claim borders on hilarious delusion. I don't say hilarious emotionally or pejoratively, but rather it is actually ha ha funny that anyone would actually believe that. However yes, there are endless loads of top-skill talent that will happily do "maintenance" in the middle of the night. I've done it on occasion, and slept in the next day. Big deal. Half the time I simply took a timeout from some online gaming I'd been doing.
      - alrs 12y ago
        We don't have "loads" of top-skill talent to begin with. The pool of top-skill-talent-with-a-self-esteem-problem is rapidly diminishing.
nathan_f77 12y ago
I really like Deis so far. Can't wait for the Docker / CoreOS / Deis ecosystem to become more mature.
brianmcdonough 12y ago
Heroku support options have always worked to shelter their employees from customers and as has been pointed out, despite the steep decline in costs, their prices have not changed. It's a shame because they were a trendsetter, but they are quickly being surpassed by players like DO, Linode and Poppup.
- therealmocker 12y ago
  Poppup?
  - ephemeralgomi 12y ago
    The company that $parent is the founder of. Which, if you google for, you discover that their page is titled "Blog Logo" and contains no content. Check back in a week or so, I guess.
    - brianmcdonough 12y ago
      A frivolous addition with no facts to check. Admitted. Give it twelve weeks. The point is that Heroku can do better. No offense meant to sales force or it's employees, just honest feedback based in real experiences.
  - deleted 12y ago
    [deleted]
joshpadnick 12y ago
I was always weary of Heroku because it's exactly what @hunvreus said: a black-box. Very appealing when you're strapped for resources in the beginning, but increasingly frustrating as you scale. Case in point: http://rapgenius.com/James-somers-herokus-ugly-secret-annotated http://rapgenius.com/James-somers-herokus-ugly-secret-annota... That being said, it seems like the model itself is not flawed, just the execution. I've met many developers, especially in the Node community, who fundamentally believe they as software engineers should not have to spend any time learning devops. My position is that a good software engineer today should be familiar with the full stack from frontend (SPA, javascript, html, css) to backend (sql, basic db admin, db design) and devops. Obviously, you can't become an expert in everything, but the knowledge level required to become "proficient" in these areas seems pretty achievable if you're well-versed in software engineering fundamentals. FWIW, it took me about 4 weeks to get a "startup-ready" fully open source 3-tier stack running in EC2 with full automation using Chef (which is a whole other topic) plus continuous deployment using Jenkins. Ultimately, we'll pay more for EC2 per month upfront, and I had to absorb the upfront time hit, but now that we're setup, it's extremely easy to tweak things, and we have complete transparency.
- pswenson 12y ago
  you mind sharing your chef recipes? did you use chef to automate jenkins too? there are too few good chef examples on the web....
  - joshpadnick 12y ago
    @pswenson, I used Chef to automate setting up the server with Jenkins. This included automated security updates, awscli tools, nodejs, and even hubot so that we can trigger builds from HipChat (we still need to write a custom hubot listener to handle that, though). I also took advantage of AWS IAM roles so that the server is pre-authenticated for certain S3 buckets. PM me at josh dot padnick at gmail /period/ com with some background on what you're trying to do and I'll see what I can share. For many reasons, I can't make our Chef code repo public, but maybe I can share some code samples. Edit: Regarding Chef, for more info you might check out http://www.slideshare.net/JoshPadnick/introduction-to-chef-automate-your-infrastructure-by-modeling-it-in-code http://www.slideshare.net/JoshPadnick/introduction-to-chef-a.... As far as online examples, yeah, the learning curve does kind of suck. Also, if you're starting from scratch, SaltStack may very well be a superior technology (don't know enough about it). I think the key with Chef is to learn how to read the docs, using the application-cookbook pattern (where you never touch the cookbooks you download online and instead customize them by "wrapping" them with your own custom-defined cookbooks. It's also helpful to use very thinly designed roles, and define special cookbooks as your actual roles. This way you can version-control them. I basically learned by reading the same material in multiple places, especially in books on Safari Books Online, and IRC was also a huge help b/c the community was VERY helpful. I think Chef is a classic case of where the technology is somewhat inelegant and perhaps bloated, but a mature community is there and it's battle-tested so once you suffer the pain of ramp-up you get a huge benefit. HTH
sunseb 12y ago
Why don't you use a dedicated server ? http://www.kimsufi.com/en/ http://www.kimsufi.com/en/ It's not that complicated... And it is far cheaper !
grrrando 12y ago
If Heroku simply re-sold AWS, people wouldn't use them. The argument that AWS's falling prices should be passed on to customer's is logical only if you're ignoring that Heroku is using the savings to build and increase the performance of their platform. It's really the complete opposite case, I think. For the value (time is money!) they offer, it's amazing they haven't increased their prices as they scale.
hadoukenio 12y ago
> When our customers email us during our vacation pissed off that we are not around and we have nothing to show to them to prove that this is Heroku's fault and not ours Here's a tip. You are a black box. Your customers don't care if it's your fault, Heroku's fault, the power grids fault or a meteorite's fault. They just care that their service is up. If anyone from you all the way down to the silicon breaks, its your problem. Not Intel, not RealTek, not Western Digital, not ComCast. Stop playing the blame game.
- cwyers 12y ago
  And that's what he's saying; Heroku's problems are his problems, but Heroku doesn't provide him a lever to solve their problems. So he's moving to somewhere else, where he has more visibility over the problems and can better communicate with his customers what the timetable is for repair.
  - rhizome 12y ago
    The whole rationale of outsourced hosting is to have someone else take care of things, so it's a little comical to see the complaints when the pendulum swings the other way. What do people expect?
marcoms 12y ago
Not sure, but is something like Divshot a viable replacement for Heroku - they both seem to be doing the same thing: developer webapp hosting, but there's probably a difference somewhere.
- josegonzalez 12y ago
  Seems like it's only for static sites? So if you mean someone's jekyll blog, sure, it's a viable replacement for Heroku. But then, so is Github Pages.
mr_than 12y ago
I'm still in the startup phase, and the time saving of Heroku has been fantastic. I'm ever mindful of these types of stories and the scaling cost though. I've not seen it mentioned so far: RedHat has OpenShift (https://www.openshift.com/ https://www.openshift.com/) out now, v3 will see Docker support too. With only a quick play, it seems to be a mix of Heroku and dedicated host. On sysadmins: talking to a guy who managed AWS nodes for a popular iOS game you've probably played, he made the comment that it was great to have a new team member onboard now, dedicated to looking after all the VMs. I figure he's rediscovered sysadmins, just using different kit. The risk I see with managing your own Dokku, etc is handling issues/maintaining uptime if it's not your only job/skill. When another HeartBleed comes along, can you react quickly and competently enough?
fortunajs 12y ago
what's funny, I read it and didn't go to heroku's website - now all the ads I see are from them
diziet 12y ago
If our company was hosted on Heroku instead of AWS, we would have to shut down. Want a 50gb redis? $4k/mo. MongoHQ's largest heroku instance is 150gb at $2700 / month? We'll need at least 50. Want 300 workers? That's $20k / mo for less quality servers. Heroku is great for working on your own project or if your data scale is small. Otherwise, the cost is just too high.
- matdes 12y ago
  At that point, don't you have enough scale, money, and need to actually hire an ops person?
  - joevandyk 12y ago
    The size of your data and the number of processes you run have nothing to do with your available cash for hiring people.
    - andy_ppp 12y ago
      The amount of money you have to grow your business is directly proportional to the cost overheads of running your app minus the revenue it generates. We are assuming that the larger your internet service is the more money you will make. Of course that has yet to be empirically proved.
      - nemothekid 12y ago
        A service that processes tweets from the firehose in realtime. Assuming you decide to process everything day 1, thats a case where the overhead from running your app could greatly outweigh the revenue it generates.
        matdes 12y ago
        I mean, I guess? I would question that business and processing model heavily, though. Most sustainable business models show growing from some kind of smaller MVP to a larger full-featured application. Significant overhead costs to go from nothing to steady-state instantaneously would be enough to scare me.
akh 12y ago
Sound similar to why we said goodbye to Heroku as well: http://blog.planforcloud.com/2013/03/from-paas-to-iaas-how-we-migrated-off.html http://blog.planforcloud.com/2013/03/from-paas-to-iaas-how-w...
cellis 12y ago
Easy. Just use deis [1]. Or CoreOS [2], if you're more hardcore. In any case, with the advent of Docker and 12-factor -- not to mention openstack [3] -- Heroku is a commodity or fast approaching it, and will soon face pricing pressure. [1] http://deis.io http://deis.io [2] http://coreos.com http://coreos.com [3] http://openstack.org http://openstack.org
rodrigoavie 12y ago
I work at an Brazilian mobile ad network running on Amazon AWS and our traffic is really intense. There are 13 developers in total in the team and none of them are DevOPS, which make me conclude that most often than not, you don't need a person specialized into server maintenance and infrastructure. Like some people said before, Heroku is great for prototyping but just not a good deal in the long run. Too expensive, way to risky/unreliable for serious stuff
zaqokm 12y ago
> It has been heavily reported that AWS has cut their pricing quite a bit over the past few years. Yet, how many times has Heroku reduced its price? This is the bit which confuses me. It is easy to think that there should be correlation between Heroku pricing and AWS pricing. However just because AWS drops their pricing does not mean the capex for Heroku is dropping.
- bdcravens 12y ago
  Even if there is a capex drop, Heroku's focus is simplicity. 5 or 10 cents an hour is part of the value prop; it may be hard to translate a 55.4 to 49.8 cent/hour drop for an AWS instance into their pricing model and not lose that simplicity.
  - zaqokm 12y ago
    > and not lose that simplicity. Very interesting point
steven_yue 12y ago
Thank god you finally realized that :)
Lamlon 12y ago
I do not believe Brian has a strong understanding of what it actually takes to do ops work. 1) Downtime. This is such a huge fallacy, if you think doing this yourself means no downtimes think again. If you had a top notch ops team you are still going to have outages in the middle of the business day. This team of ops guys you hire, guess what? They are not going to be deploying at 1am every day, that is not sustainable. They are going to deploy in the middle of the day, and guess what, they will make a mistake. And guess who notices outages first most times? Customers. Heroku's uptime is typically in the 99.9%'s, I don't think you can do the same with one ops guy, maybe you will get lucky, however it is more likely that you won't. 5) Buildpacks Build packs are an AMAZING abstraction. Just think about how you would solve the following without buildpacks: 5.1) Install libgeos on all the hosts running a specific application? 5.2) Create and scale new worker instances on demand? 5.3) How do you setup logging for all these servers? 5.4) Health checks for these services (tcp, http) 5.5) Alerting and automatic failover * pssh? That will work fine until you spin up a second server and forget all the incatations to get your software up and running. * Puppet? I am sorry but Puppet, chef and their ilk are horrible, who knows what state any machine is ever in at any point in time. humans will inevitably forget to ensure absent, or make an assumption about state in puppet land. Nevermind the slow feedback loop in puppet land. Oh hey you want to change all the servers running X to now run Y instead, good luck with that. * Mesos? Mesos is the best open source scheduler out there, Marathon makes it easy to deploy to and there are scripts to run easily on ec2. However if you want to install native dependencies (libgeos etc) you will still need to do one of the above things. * Docker? Docker is an amazing way to package your app up and ship it to run on Mesos, however how do you package docker apps and ship them? Guess what? Buildpacks. Now consider this on Heroku (5.1) Add the https://github.com/ddollar/heroku-buildpack-multi https://github.com/ddollar/heroku-buildpack-multi (5.2) Change your procfile (5.3) There are plugin's for that Oh hey you can also write your own language, write a buildpack for it, and deploy it to production without ever having to get an ops person anywhere to setup a server for you. I am sorry but that is nothing short of amazing. 2 and 4) I agree 100%, it sucks to feel powerless and have no insight as to when things will be resolved, however if you work in any decent size org ops things will go down, and you will also have to wait to see any resolution. I agree it feels better to see people working busily in your office because you can see the sense of urgency. I 3) Pricing: In regards to pricing: yes Heroku is very expensive. However for small and medium teams it is much cheaper than hiring an ops person. You also get an economy of scale when you use Heroku; Think of all the things heroku takes care of for you: automatic failover on hardware/software(segfaults)/vm issues. Disks filling up on some host (it is embarrassing how many times I have seen something as simple as this cause issues). Agility; You need to switch MRI out for JRuby or rubinius, no problem, just update your ruby "version" in your Gemfile. The Heroku platform is superior in almost every way for running small to medium size applications then any in house cooked alternative. I am very familiar with the alternatives out there, I have contributed to dokku's buildpack repo https://github.com/progrium/buildstep https://github.com/progrium/buildstep, and have patched docker. There is no good behind the firewall/on my vm/hardware alternative for heroku atm. People are making progress but you won't really get anything as full featured as heroku. Best of luck to you Brian.
boboohaze 12y ago
Bit surprised no one mentioning Cloudfoundry in the comments. It's pretty much opensource Heroku solution, run it againts AWS and it's almost exactly heroku, and with all the tooling around it quite easy to setup.
delta-clu 12y ago
Hi guys, we're actually working on bare-metal PaaS, and we're a couple of weeks away from launching a beta.
Jweb_Guru 12y ago
Personally, I really fell out of love with Heroku when reading their justification for not providing VPC compatibility. https://discussion.heroku.com/t/deploy-failure-from-heroku-ec2-security-group-change/324 https://discussion.heroku.com/t/deploy-failure-from-heroku-e... In short, Heroku thinks that firewalls encourage people to be lazy about security, and leaves people crippled if the firewall is exposed. Due to this philosophical difference, they would rather force everyone to rely on SSL for all secure communication, and leave every machine accessible to the internet, including (for example) your database server.

218 points by bcardarella 12y ago

sync 12y ago

So how do you scale out to multiple droplets on Digital Ocean? Set up your own HAProxy instance? What do you do when one of your droplets disappears or crashes? Where do you host your database? Not quizzing, real questions from someone also looking to drop heroku.

opendais 12y ago
I'd suggest using Linode over Digital Ocean. They already are the same price/performance [roughly, unless you are buying DO's $5 nodes]. They also have stuff like load balancers built out and are reasonably reliable [although only at the datacenter level, they don't have multi-DC load balancers]: https://www.linode.com/nodebalancers https://www.linode.com/nodebalancers
- bcardarella 12y ago
  I am a big Linode fan and I hadn't realized they price-matched DO. Thank you for the info.
  - opendais 12y ago
    Ya, they shuffled their prices a month or so ago: https://www.linode.com/pricing https://www.linode.com/pricing Its the same 1 Core / 1GB == $10 pricing DO uses. [roughly]
  - rwg 12y ago
    Be warned that Linode's status page is also borderline useless. Their website and web-based management interface (and API, according to customers on their IRC channel) were throwing 500 Internal Server Errors for >2 hours the other night, and their status page never had any mention of it.
    - jebblue 12y ago
      In 4 year it's always worked for me. edit: years
- pc86 12y ago
  Just a counterpoint as someone who switched from Linode to DO (and indeed have used mostly their $5 nodes) and currently uses a mix of DO and Azure: You need to be comfortable with command-line server administration to use Linode. Yes, they've got tutorials, and they're pretty good. You can be walked through installing __________ on whatever specific flavor of OS you happen to be running. But the moment something goes wrong or I had a slightly-above-novice-level question, the response was that Linode did not offer that level of support and it was a self-managed server (or whatever the specific language was). Not complaining, that was exactly what I was paying for, but it's certainly something to take into consideration if you're not comfortable with command-line server admin.
  - opendais 12y ago
    DO is pretty much the same as Linode in that respect. You have tutorials and command line comfort as the basic requirement for using the product. Both the parent and the OP both suggested switching to DO which is the point of comparison. I've never had better support/more comprehensive with DO than Linode. Then again, I've had a Linode account for like 6 years and I think I've opened as many tickets. ;)
- albertoleal 12y ago
  Just curious, because I plan on using node balancers. Does node balancers only pool bandwidth on linode instances on the DC the node balancer is in?
  - opendais 12y ago
    Don't trust me <3 Ask their support. I believe its all of them: https://blog.linode.com/2010/02/08/bandwidth-pooling/ https://blog.linode.com/2010/02/08/bandwidth-pooling/
nirvdrum 12y ago
There's a few options out there. You can treat DO as a compute-only EC2 if you'd like. I work on a project called Rubber [1] that can provision servers and templates for you. DO is one of the supported providers. We've taken care of a lot of the annoying stuff for you, like mapping security group rules back to iptables, setting up DB replication, off-site backups to S3, and so on. You'd likely be able to do the same with chef, ansible, puppet or whatever else. I don't have deep experience with those options, so I can't really speak to them. [1] -- http://rubber.io/ http://rubber.io/
- Lazare 12y ago
  Rubber looks quite interesting. Is it Rails only?
  - nirvdrum 12y ago
    Nope. It's got a Ruby inclination, but it's something we're divorcing ourselves from. Deploying Sinatra and other non-Rails, Ruby apps is pretty straightforward. Deploying non-Ruby apps is certainly doable but currently requires a bit of creativity (I've deployed Java and Scala apps with it).
    - bdcravens 12y ago
      It also spins up other server types like Selenium. (I do alot with Selenium, and even have an accepted pull request in Rubber's Selenium implementation)
  - gnepzhao 12y ago
    Checkout visualops.io. We are language-independent devops automation service. Similar value with Heroku: autoscaling, auto-healing, push-to-deploy, but not blackbox. Instances runs in your own account. Even if we go down, your app will not be impacted.
  - deleted 12y ago
    [deleted]
- 12y ago
king_magic 12y ago
I've been trying out Dokku (https://github.com/progrium/dokku https://github.com/progrium/dokku) as a Heroku alternative. DigitalOcean has a nice VM template for Dokku; I think Linode has something like it too (or instructions for setting up Dokku). So far, I like it; Dokku is pretty slick. Deployments are more or less the same as Heroku - "git push dokku master", in the case of my Rails app. But that said, assuming Heroku's security is super tight, I have a bit of work to do to secure my droplet. I'll probably still have to scale myself (or just switch to Linode and use their load balancer), and with Dokku I've got a PostgreSQL DB in my Dokku container. Droplets disappearing or crashing... not sure, but I sure hope DigitalOcean's backups are good :)
- sleight42 12y ago
  I'll probably still have to scale myself... This sounds painful. Dokku is only a single VM solution though, right? Flynn (http://flynn.io http://flynn.io), the all grown up Dokku, isn't production ready yet. I'd love to hear that I'm wrong and that scaling up with Dokku is a piece of cake. If so, please correct me!
  - alextgordon 12y ago
    Just curious, what are you guys doing that you need to "scale up"? Even if you get a hundred thousand hits in an hour, that's only 28 per second. I am pretty sure even my toaster can handle that. I've been fireballed, HN'd, reddited, etc. All on my little 256MB Linode instance (now 1024). It has never been anything but zippy.
    - king_magic 12y ago
      Currently - nothing that needs scaling for my personal projects. However, as a consultant, it's very possible that a large client may need to scale (dealing with this right now on Azure), so I like to be prepared with options. That said, I know better than to put Dokku in production for a client - at least not until it significantly matures :)
    - voltagex_ 12y ago
grey-area 12y ago
Not the OP, but if you're looking to drop Heroku (because of cost, or reliability?), it's not that hard to host your own on a VPS or dedicated servers. Set up your own HAProxy instance? https://www.digitalocean.com/community/tutorials/how-to-use-haproxy-to-set-up-http-load-balancing-on-an-ubuntu-vps https://www.digitalocean.com/community/tutorials/how-to-use-... Setting it up doesn't look too hard, and you're not going to need it until you reach significant scale - so probably 90% of the people reading this without a dedicated ops team aren't ever going to need it. Startups often seem to over-engineer servers at an early stage or assume they'll need a massive cluster when a single server with multiple processes could serve perfectly well till you actually hit some sort of scaling problem (i.e. millions of users a month). As an example, the HN website ran for a long time on one server (not sure what they use now, but it's not heroku :). Very large VPS instances often cost less than scaling with heroku. Also, other providers like Linode offer load balancers without setup for a low cost. What do you do when one of your droplets disappears or crashes? ansible myserverplaybook.yml to set up another one in a few minutes. But you'll find this just isn't necessary unless the server config changes - uptime will be measured in months on most providers (not sure about DO in particular, haven't hosted anything serious there). Where do you host your database? On another DO droplet, with remote backups, or even on the same one if you have a sizeable VPS and low to moderate traffic.
nlh 12y ago
I haven't deployed with them yet, but have been seriously considering making the switch to Cloud66 (http://www.cloud66.com/ http://www.cloud66.com/). It looks like the best of both worlds -- higher level than Dokku, but choices when it comes to the underlying infrastructure provider (Linode, DigitalOcean, AWS, or some combination). Small overhead charge for the management which seems very reasonable, otherwise you're just paying for the (virtual) metal from the IaaS guys.
- jevyjevjevs 12y ago
  I've been really happy with cloud66. Discovering new features everyday that saves me from having to build nginx/postgres/passenger from scratch. Try it out, I think you'll find it provides the balance you seek.
- bdcravens 12y ago
  We've been using Cloud66 for a couple of months now. You may find yourself tweaking the manifest files, though. It's not immutable architecture, but rather, they deploy over and over using Capistrano. So over time you'll build up some artifacts/cruft, especially if you're doing anything that generates a lot of log files. Not a problem, but you'll want to configure it to use instances with enough storage, which in a default config is often only 8GB.
stollercyrus 12y ago
Here are some puppet manifests I put together for hosting ruby (in my case rails) apps on Digital Ocean that you might find helpful. https://github.com/cyrusstoller/gardenbed https://github.com/cyrusstoller/gardenbed It sets up postgres/rbenv/nginx/ s3 db backups etc ...

drovido 12y ago

I am not a Heroku customer and maybe there is more substance to his complaints but I didn't see anything in the post that would cause him to want to leave his hosting provider with guns blazing like this. Reduce their prices because their service providers have reduced their rates? Seriously which company you know does that? Do we even know what arrangement Heroku has with amazon? Isn't it possible that as a large customer their rates are already discounted. On the subject of downtime he didn't actually say that his application was down as a result of the maintenance in this instance or any other.

parasubvert 12y ago

"Buildpacks are just terrible." Elaborate please? CF uses a variant of them, and they're ultimately just a simple three-script harness to build and run your app. There are pros/cons vs. dockerfiles , chef/puppet/ansible, or just doing a Netflix style Aminator, I suppose, but "terrible" seems exagerrated.

bcardarella 12y ago
Customization. Ever try to add a command-line tool to a buildpack? I don't understand why we cannot make use of apt as the EC2 instances that Heroku uses are just Ubuntu AMIs.
- parasubvert 12y ago
  Sure. You can't make assumptions about the base distro with buildpacks, which is why you curl/untar dependencies. Dockerfiles are a bit better by allowing you to pick the base image (and thus distro), though there are tradeoffs with that too.
- latchkey 12y ago
  It's a pain, but it isn't the end of the world or a disaster. I distribut some CLI tools with a NodeJS app I wrote. Here's the docs: https://github.com/lookfirst/convert/wiki/Compile https://github.com/lookfirst/convert/wiki/Compile
cschmidt 12y ago
I've found them to be fairly terrible. They work great until you need to do more than use pip to install stuff (I'm using python). So things as simple as matplotlib get hairy. You have to use a custom buildpack someone contributed (which is based on an old version). Now say I want to use python with R. It is a huge pain. You have to use heroku-buildpack-multi [1]. The problem is that environment variables and installed code from the first buildpack are invisible to the second. So you end up having to hack individual buildpacks, which is just gross. It worked in the end, but I wasted days on it. A concept like docker, where you fire up a container, install stuff with apt-get, and then save the results is greatly superior. [1] https://github.com/ddollar/heroku-buildpack-multi https://github.com/ddollar/heroku-buildpack-multi

nonane 12y ago

What are the alternatives to Heroku? I'm looking for something that makes it easy to deploy and launch services. http://deis.io http://deis.io looks promising but it isn't production ready yet.

cobrabyte 12y ago
We've been pretty happy with Cloud66 (www.cloud66.com).
gabrtv 12y ago
Deis has quite a few successful deployments in the wild. Most of the work being done today is around automated testing, platform hardening, HA/failure modes, etc. A stable release is not far away.
- nonane 12y ago
  Who is Deis targeted towards? I'm a regular developer with little real world Ops experience. Will Deis be a good fit for me? From the docs it looks like Deis reuqires an advanced Ops person to manage a cluster of Deis machines.
  - gabrtv 12y ago
    Deis is for software teams who need to operate their own servers (for a variety of reasons). If you're a "regular developer with little real world Ops experience", I personally recommend sticking with Heroku or equivalent hosted services despite the occasional outages.
king_magic 12y ago
I literally just discovered Dokku (https://github.com/progrium/dokku https://github.com/progrium/dokku) yesterday - a "Docker powered mini-Heroku in around 100 lines of Bash". You can roll your own PaaS infrastructure on your own VMs. It took a few hours, but I was able to get my Heroku-based Rails app up and running on a Dokku droplet (to be fair, the most time-consuming part was getting the SSH keys right and figuring out that I needed a domain name - e.g., couldn't just set it up with a droplet's IP address - at least not with the DigitalOcean tutorial's instructions: https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-dokku-application https://www.digitalocean.com/community/tutorials/how-to-use-...).

calgaryeng 12y ago

s/mainteance/maintenance/

m0th87 12y ago

We're working on switching from Heroku to EC2. To my knowledge there isn't a lot of documentation out there on this process - we're just looking for code snippets to figure out how to build AMIs, deploy, etc. It's a slow and error-prone process. Anyone know of good resources to make this migration?

infecto 12y ago
I have never seen any documentation on moving from Heroku > EC2. They are very different services and there are many options to replicate the heroku api. Not used it yet but www.cloud66.com always interested me.
deleted 12y ago
[deleted]
eknkc 12y ago
Take a look at Elastic Beanstalk too. We use eb with docker containers and it has been pretty decent. Handles auto scaling, load balancing, fault recovery, deployment itself, and Docker provides great flexibility.
parasubvert 12y ago
I'd suggest looking at AWS OpsWorks, which is probably closest to what you're used to. http://www.stefanwrobel.com/heroku-to-opsworks http://www.stefanwrobel.com/heroku-to-opsworks http://artsy.github.io/blog/2013/08/27/introduction-to-aws-opsworks/ http://artsy.github.io/blog/2013/08/27/introduction-to-aws-o...
- anko 12y ago
  I second this. I got up and running on opsworks in about 3 days without any AWS or Chef experience (I use puppet on our other providers).
tbronchain 12y ago
We are currently working on a product based on AWS that could fit your needs, giving you as flexibility as you can get with a manual EC2 configuration, but with the simplicity of a service like Heroku and the reliability of a service like OpsWorks: visualops.io Don't hesitate to contact with us if you have any remark or question. Also, we recently released a "store" comporting some template of common application to help people coming from PaaS platforms: store.visualops.io

braydenjw 12y ago

I'm wary about a lot of these SASS/PASS/IASS services. The "don't put all your eggs in one basket" cliche comes to mind.

meritt 12y ago

All these companies leaving Heroku and other PaaS providers is definitely a blessing for the thousands of unemployed devops & sysadmins out there.

lucisferre 12y ago
I can't say I meet all that many who are unemployed. Maybe that's just me.
- meritt 12y ago
  Our last engineering job req we received about 10 sysadmin applicants almost all of which started with a "I know I'm not an exact fit but..." sort of line. Maybe it was just an oddity.
  - incision 12y ago
    >'Maybe it was just an oddity.' I think there's a reason, but it's not outright unemployment - yet. On the enterprise side what I'm seeing are traditional sysadmin positions being eaten up by aggressive VARs and software vendors. They all have XaaS plays now and they're targeting their existing customers first. The pitch is literally... "Hey, I can save you $350K/yr. Just fire your ________ team and use our PaaS. We'll perform the migration for free." Assuming the organization doesn't want to pursue their own internal or lower-level external service it leaves the sysadmins to either somehow make the leap to administering a provider system or diversify into other roles where they don't exactly fit.
spudlyo 12y ago
If any of the thousands of unemployed devops & sysadmin types out there are reading this: Twitter is looking to fill five open SRE positions in San Francisco[1] and two in Seattle[2]. [1] https://about.twitter.com/careers/locations/san-francisco https://about.twitter.com/careers/locations/san-francisco [2] https://about.twitter.com/careers/locations/seattle https://about.twitter.com/careers/locations/seattle If you'd like to know more about the SRE org at Twitter (Seattle in particular) drop me a line. My email address is in my profile.

_bpo 12y ago

The idea that maintenance should not be done during the day is a bit antiquarian. Scheduled maintenance should take place during their company's workday when they have as many people as possible available, feeling awake, well-rested and not distracted by the things they might prefer to do with their evenings and weekends off work. Of course, scheduled downtime should be done in off-hours, but modern services like Heroku don't have scheduled downtime.

ryanbrunner 12y ago
I agree with this argument, but there's plenty of work hours in the day, and 2 PM Eastern is just about the worst one to pick. We try to start scheduled maintenance around 8 AM - that way we have fully refreshed devs ready to address any problems, and if something does go wrong, it's a relatively low-traffic time for our application.
- _bpo 12y ago
  The reality is that there is no good time for a large-scale platform to go down. I'd speculate that 8am PDT would be worse for Heroku, as their business seems largely split between the US and Europe, so downtime then would upset everyone... but that's just speculation. You can't build a company of developers selling products to developers while fleeing the working hours of developers.
jonahx 12y ago
What is the definition of maintenance? Is it work that they don't expect will cause downtime but has some chance of causing downtime?
- _bpo 12y ago
  The scheduled maintenance notice said: During this time, Heroku command line tools and web interface actions to create and restart dynos can be delayed. So it was expected to slow the performance of some queues.

hunvreus 12y ago

Heroku is a great way to get started fast without having to worry about anything related to operations. That being said, you're effectively outsourcing your entire ops/DevOps to a third party. You don't set the rules, you don't get to argue about the best scaling strategy, and overall your infrastructure is pretty much a black-box. I've seen a fair amount of people who loved Heroku for ramping up apps only to feel trapped once they started scaling their service. PaaS definitely has its use case, but I wouldn't recommend it for anything beyond prototyping. In fact (shameless plug), this is why I've been working on devo.ps, to lower the barriers of entries to managing your own servers (on AWS, Rackspace, Digital Ocean, Linode...) using tools familiar to developers (Git + YAML). @bcardarella happy to add you to our beta testers; we'd love to get feedback from a heavy Heroku user. Email is in my profile. If there are other Heroku users affected, drop me a line and I'll see if we can help you get set up on your own infrastructure with devo.ps.

morenoh149 12y ago
no blog updates since '13 tsk tsk. I was excited.
- hunvreus 12y ago
  We've been busy building stuff and talking with users. We actually have the new landing page and a couple blog posts coming out this week.

AdrianRossouw 12y ago

We're actually busy doing a similar move. fwiw, here's some resources i collected around docker. http://wayfinder.co/pathways/53619274d95a741100e7f203/docker-based-paas-wip http://wayfinder.co/pathways/53619274d95a741100e7f203/docker... It's a few weeks old, but of those the one that came closest to our needs was Deis.

slb350 12y ago

I'm a devops engineer and I never really saw the draw of Heroku or EY after you scale out to a certain size. EC2 is extremely easy to work with and there's tons of documentation out there. Once you setup your CI & CD, write your cookbooks and capistrano (or whatever), it's nearly hands off.

robalfonso 12y ago
I'm in your boat, but you have to realize that heroku is not targeted for anyone who is comfortable doing top to bottom provisioning of their environment. I also think their value proposition is a "grow with us" type situation: get you in the door for cheap and then as you grow you just keep bumping resources up.
andy_ppp 12y ago
Heroku is the dreamweaver of devops... but you know developers often don't have the time to spend 2 months+ learning how to do it right (hence your job title :-D). And for my small app I'll wager that Heroku has infinitely better uptime than I would manage!

michaelbuckbee 12y ago

Heroku's defining characteristic has always been that it radically reduces the sysadmin surface area of my app stack to something I can reasonably handle. So, while things like Dokku, etc. are really interesting they don't seem to be actually expanding the number of app-stack layers that I'd need to know to properly secure and maintain a server. Am I missing something?

lucisferre 12y ago

Heroku does have it's problems but if I'm being honest I don't have the time to spend using anything else right now. Perhaps when I hit a larger scale/stage I'll reconsider that, but at this stage there really isn't anything better.

alrs 12y ago

Deployment and maintenance should not happen in the middle of the night. We've known this for years. You design your systems to degrade gracefully, hopefully transparently. Screwing up your engineers' sleep schedules is a terrible idea, so you deploy during the day when people are awake, clear-headed, and on the clock. I'll take a 1PM outage over a 1AM outage any day. If that's bad for business, business should pay for the engineering time to build a more resilient system.

jerhinesmith 12y ago
Is that true? I'm not being sarcastic -- I just have always generally assumed that maintenance was better performed "off-hours". Also, 1pm and 1am aren't the only options. 8am EDT would have been within the work day but still avoided peak usage in the US.
- alrs 12y ago
  8AM EDT is 5AM PDT, which is where web tech can be found in the United States. I'm sure you can find engineers willing to work garbage-man hours, but it's gonna cost you.
  - personZ 12y ago
    8AM EDT is 5AM PDT, which is where web tech can be found in the United States. I'm not sure if you're just being sarcastic, but talent in North America isn't limited to the Pacific Timezone, and such a claim borders on hilarious delusion. I don't say hilarious emotionally or pejoratively, but rather it is actually ha ha funny that anyone would actually believe that. However yes, there are endless loads of top-skill talent that will happily do "maintenance" in the middle of the night. I've done it on occasion, and slept in the next day. Big deal. Half the time I simply took a timeout from some online gaming I'd been doing.
    - alrs 12y ago
      We don't have "loads" of top-skill talent to begin with. The pool of top-skill-talent-with-a-self-esteem-problem is rapidly diminishing.

nathan_f77 12y ago

I really like Deis so far. Can't wait for the Docker / CoreOS / Deis ecosystem to become more mature.

brianmcdonough 12y ago

Heroku support options have always worked to shelter their employees from customers and as has been pointed out, despite the steep decline in costs, their prices have not changed. It's a shame because they were a trendsetter, but they are quickly being surpassed by players like DO, Linode and Poppup.

therealmocker 12y ago
Poppup?
- ephemeralgomi 12y ago
  The company that $parent is the founder of. Which, if you google for, you discover that their page is titled "Blog Logo" and contains no content. Check back in a week or so, I guess.
  - brianmcdonough 12y ago
    A frivolous addition with no facts to check. Admitted. Give it twelve weeks. The point is that Heroku can do better. No offense meant to sales force or it's employees, just honest feedback based in real experiences.
- deleted 12y ago
  [deleted]

joshpadnick 12y ago

I was always weary of Heroku because it's exactly what @hunvreus said: a black-box. Very appealing when you're strapped for resources in the beginning, but increasingly frustrating as you scale. Case in point: http://rapgenius.com/James-somers-herokus-ugly-secret-annotated http://rapgenius.com/James-somers-herokus-ugly-secret-annota... That being said, it seems like the model itself is not flawed, just the execution. I've met many developers, especially in the Node community, who fundamentally believe they as software engineers should not have to spend any time learning devops. My position is that a good software engineer today should be familiar with the full stack from frontend (SPA, javascript, html, css) to backend (sql, basic db admin, db design) and devops. Obviously, you can't become an expert in everything, but the knowledge level required to become "proficient" in these areas seems pretty achievable if you're well-versed in software engineering fundamentals. FWIW, it took me about 4 weeks to get a "startup-ready" fully open source 3-tier stack running in EC2 with full automation using Chef (which is a whole other topic) plus continuous deployment using Jenkins. Ultimately, we'll pay more for EC2 per month upfront, and I had to absorb the upfront time hit, but now that we're setup, it's extremely easy to tweak things, and we have complete transparency.

pswenson 12y ago
you mind sharing your chef recipes? did you use chef to automate jenkins too? there are too few good chef examples on the web....
- joshpadnick 12y ago
  @pswenson, I used Chef to automate setting up the server with Jenkins. This included automated security updates, awscli tools, nodejs, and even hubot so that we can trigger builds from HipChat (we still need to write a custom hubot listener to handle that, though). I also took advantage of AWS IAM roles so that the server is pre-authenticated for certain S3 buckets. PM me at josh dot padnick at gmail /period/ com with some background on what you're trying to do and I'll see what I can share. For many reasons, I can't make our Chef code repo public, but maybe I can share some code samples. Edit: Regarding Chef, for more info you might check out http://www.slideshare.net/JoshPadnick/introduction-to-chef-automate-your-infrastructure-by-modeling-it-in-code http://www.slideshare.net/JoshPadnick/introduction-to-chef-a.... As far as online examples, yeah, the learning curve does kind of suck. Also, if you're starting from scratch, SaltStack may very well be a superior technology (don't know enough about it). I think the key with Chef is to learn how to read the docs, using the application-cookbook pattern (where you never touch the cookbooks you download online and instead customize them by "wrapping" them with your own custom-defined cookbooks. It's also helpful to use very thinly designed roles, and define special cookbooks as your actual roles. This way you can version-control them. I basically learned by reading the same material in multiple places, especially in books on Safari Books Online, and IRC was also a huge help b/c the community was VERY helpful. I think Chef is a classic case of where the technology is somewhat inelegant and perhaps bloated, but a mature community is there and it's battle-tested so once you suffer the pain of ramp-up you get a huge benefit. HTH

sunseb 12y ago

Why don't you use a dedicated server ? http://www.kimsufi.com/en/ http://www.kimsufi.com/en/ It's not that complicated... And it is far cheaper !

grrrando 12y ago

If Heroku simply re-sold AWS, people wouldn't use them. The argument that AWS's falling prices should be passed on to customer's is logical only if you're ignoring that Heroku is using the savings to build and increase the performance of their platform. It's really the complete opposite case, I think. For the value (time is money!) they offer, it's amazing they haven't increased their prices as they scale.

hadoukenio 12y ago

> When our customers email us during our vacation pissed off that we are not around and we have nothing to show to them to prove that this is Heroku's fault and not ours Here's a tip. You are a black box. Your customers don't care if it's your fault, Heroku's fault, the power grids fault or a meteorite's fault. They just care that their service is up. If anyone from you all the way down to the silicon breaks, its your problem. Not Intel, not RealTek, not Western Digital, not ComCast. Stop playing the blame game.

cwyers 12y ago
And that's what he's saying; Heroku's problems are his problems, but Heroku doesn't provide him a lever to solve their problems. So he's moving to somewhere else, where he has more visibility over the problems and can better communicate with his customers what the timetable is for repair.
- rhizome 12y ago
  The whole rationale of outsourced hosting is to have someone else take care of things, so it's a little comical to see the complaints when the pendulum swings the other way. What do people expect?

marcoms 12y ago

Not sure, but is something like Divshot a viable replacement for Heroku - they both seem to be doing the same thing: developer webapp hosting, but there's probably a difference somewhere.

josegonzalez 12y ago
Seems like it's only for static sites? So if you mean someone's jekyll blog, sure, it's a viable replacement for Heroku. But then, so is Github Pages.

mr_than 12y ago

I'm still in the startup phase, and the time saving of Heroku has been fantastic. I'm ever mindful of these types of stories and the scaling cost though. I've not seen it mentioned so far: RedHat has OpenShift (https://www.openshift.com/ https://www.openshift.com/) out now, v3 will see Docker support too. With only a quick play, it seems to be a mix of Heroku and dedicated host. On sysadmins: talking to a guy who managed AWS nodes for a popular iOS game you've probably played, he made the comment that it was great to have a new team member onboard now, dedicated to looking after all the VMs. I figure he's rediscovered sysadmins, just using different kit. The risk I see with managing your own Dokku, etc is handling issues/maintaining uptime if it's not your only job/skill. When another HeartBleed comes along, can you react quickly and competently enough?

fortunajs 12y ago

what's funny, I read it and didn't go to heroku's website - now all the ads I see are from them

diziet 12y ago

If our company was hosted on Heroku instead of AWS, we would have to shut down. Want a 50gb redis? $4k/mo. MongoHQ's largest heroku instance is 150gb at $2700 / month? We'll need at least 50. Want 300 workers? That's $20k / mo for less quality servers. Heroku is great for working on your own project or if your data scale is small. Otherwise, the cost is just too high.

matdes 12y ago
At that point, don't you have enough scale, money, and need to actually hire an ops person?
- joevandyk 12y ago
  The size of your data and the number of processes you run have nothing to do with your available cash for hiring people.
  - andy_ppp 12y ago
    The amount of money you have to grow your business is directly proportional to the cost overheads of running your app minus the revenue it generates. We are assuming that the larger your internet service is the more money you will make. Of course that has yet to be empirically proved.
    - nemothekid 12y ago
      A service that processes tweets from the firehose in realtime. Assuming you decide to process everything day 1, thats a case where the overhead from running your app could greatly outweigh the revenue it generates.
      - matdes 12y ago
        I mean, I guess? I would question that business and processing model heavily, though. Most sustainable business models show growing from some kind of smaller MVP to a larger full-featured application. Significant overhead costs to go from nothing to steady-state instantaneously would be enough to scare me.

akh 12y ago

Sound similar to why we said goodbye to Heroku as well: http://blog.planforcloud.com/2013/03/from-paas-to-iaas-how-we-migrated-off.html http://blog.planforcloud.com/2013/03/from-paas-to-iaas-how-w...

cellis 12y ago

Easy. Just use deis [1]. Or CoreOS [2], if you're more hardcore. In any case, with the advent of Docker and 12-factor -- not to mention openstack [3] -- Heroku is a commodity or fast approaching it, and will soon face pricing pressure. [1] http://deis.io http://deis.io [2] http://coreos.com http://coreos.com [3] http://openstack.org http://openstack.org

rodrigoavie 12y ago

I work at an Brazilian mobile ad network running on Amazon AWS and our traffic is really intense. There are 13 developers in total in the team and none of them are DevOPS, which make me conclude that most often than not, you don't need a person specialized into server maintenance and infrastructure. Like some people said before, Heroku is great for prototyping but just not a good deal in the long run. Too expensive, way to risky/unreliable for serious stuff

zaqokm 12y ago

> It has been heavily reported that AWS has cut their pricing quite a bit over the past few years. Yet, how many times has Heroku reduced its price? This is the bit which confuses me. It is easy to think that there should be correlation between Heroku pricing and AWS pricing. However just because AWS drops their pricing does not mean the capex for Heroku is dropping.

bdcravens 12y ago
Even if there is a capex drop, Heroku's focus is simplicity. 5 or 10 cents an hour is part of the value prop; it may be hard to translate a 55.4 to 49.8 cent/hour drop for an AWS instance into their pricing model and not lose that simplicity.
- zaqokm 12y ago
  > and not lose that simplicity. Very interesting point

steven_yue 12y ago

Thank god you finally realized that :)

Lamlon 12y ago

I do not believe Brian has a strong understanding of what it actually takes to do ops work. 1) Downtime. This is such a huge fallacy, if you think doing this yourself means no downtimes think again. If you had a top notch ops team you are still going to have outages in the middle of the business day. This team of ops guys you hire, guess what? They are not going to be deploying at 1am every day, that is not sustainable. They are going to deploy in the middle of the day, and guess what, they will make a mistake. And guess who notices outages first most times? Customers. Heroku's uptime is typically in the 99.9%'s, I don't think you can do the same with one ops guy, maybe you will get lucky, however it is more likely that you won't. 5) Buildpacks Build packs are an AMAZING abstraction. Just think about how you would solve the following without buildpacks: 5.1) Install libgeos on all the hosts running a specific application? 5.2) Create and scale new worker instances on demand? 5.3) How do you setup logging for all these servers? 5.4) Health checks for these services (tcp, http) 5.5) Alerting and automatic failover * pssh? That will work fine until you spin up a second server and forget all the incatations to get your software up and running. * Puppet? I am sorry but Puppet, chef and their ilk are horrible, who knows what state any machine is ever in at any point in time. humans will inevitably forget to ensure absent, or make an assumption about state in puppet land. Nevermind the slow feedback loop in puppet land. Oh hey you want to change all the servers running X to now run Y instead, good luck with that. * Mesos? Mesos is the best open source scheduler out there, Marathon makes it easy to deploy to and there are scripts to run easily on ec2. However if you want to install native dependencies (libgeos etc) you will still need to do one of the above things. * Docker? Docker is an amazing way to package your app up and ship it to run on Mesos, however how do you package docker apps and ship them? Guess what? Buildpacks. Now consider this on Heroku (5.1) Add the https://github.com/ddollar/heroku-buildpack-multi https://github.com/ddollar/heroku-buildpack-multi (5.2) Change your procfile (5.3) There are plugin's for that Oh hey you can also write your own language, write a buildpack for it, and deploy it to production without ever having to get an ops person anywhere to setup a server for you. I am sorry but that is nothing short of amazing. 2 and 4) I agree 100%, it sucks to feel powerless and have no insight as to when things will be resolved, however if you work in any decent size org ops things will go down, and you will also have to wait to see any resolution. I agree it feels better to see people working busily in your office because you can see the sense of urgency. I 3) Pricing: In regards to pricing: yes Heroku is very expensive. However for small and medium teams it is much cheaper than hiring an ops person. You also get an economy of scale when you use Heroku; Think of all the things heroku takes care of for you: automatic failover on hardware/software(segfaults)/vm issues. Disks filling up on some host (it is embarrassing how many times I have seen something as simple as this cause issues). Agility; You need to switch MRI out for JRuby or rubinius, no problem, just update your ruby "version" in your Gemfile. The Heroku platform is superior in almost every way for running small to medium size applications then any in house cooked alternative. I am very familiar with the alternatives out there, I have contributed to dokku's buildpack repo https://github.com/progrium/buildstep https://github.com/progrium/buildstep, and have patched docker. There is no good behind the firewall/on my vm/hardware alternative for heroku atm. People are making progress but you won't really get anything as full featured as heroku. Best of luck to you Brian.

boboohaze 12y ago

Bit surprised no one mentioning Cloudfoundry in the comments. It's pretty much opensource Heroku solution, run it againts AWS and it's almost exactly heroku, and with all the tooling around it quite easy to setup.

delta-clu 12y ago

Hi guys, we're actually working on bare-metal PaaS, and we're a couple of weeks away from launching a beta.

Jweb_Guru 12y ago

Personally, I really fell out of love with Heroku when reading their justification for not providing VPC compatibility. https://discussion.heroku.com/t/deploy-failure-from-heroku-ec2-security-group-change/324 https://discussion.heroku.com/t/deploy-failure-from-heroku-e... In short, Heroku thinks that firewalls encourage people to be lazy about security, and leaves people crippled if the firewall is exposed. Due to this philosophical difference, they would rather force everyone to rely on SSL for all secure communication, and leave every machine accessible to the internet, including (for example) your database server.