Heroku Blog

I'm the Java Languages Owner at Heroku. While I can't reveal in full detail why we do (or do not) officially support a particular language, I can say that it has nothing to do with how resource-hungry the runtime is :)

Our determination to officially support a language is based on numerous factors including community demand, relationship with other technologies, suitability to the platform (C++ is really popular but not for web apps), and more. In any case, I wouldn't read too much into our support--it's not a determination on the language itself.

Fun fact: Clojure was the first JVM language supported on Heroku back in 2011 (even before Java itself)!
https://blog.heroku.com/clojure_on_heroku

Today, Heroku support Java (with Maven or Gradle), Scala, and Clojure buildpacks. JRuby is supported via the Ruby buildpack. Buildpacks are the mechanism that prepares each app for production, so in some ways our support is more tightly coupled to the build tools than the language. That's why we don't have a Kotlin buildpack (it can use the Maven or Gradle buildpack accordingly). In fact, there's nothing specially you need to do to run a Kotlin app on Heroku, so we have some docs and there isn't much more to say about it. We've also worked closely with the Kotlin folks to make sure the ecosystem plays well with Heroku.

Let us know if you have any trouble with Clojure on Heroku. Stackoverflow.com is a great place to start (and I personal try to watch for questions tagged with "Heroku"…

We use PagerDuty and couldn't be happier with the product.

Ops in a modern startup (based on my experience at Crittercism) is about 1/3 automation (deploys, backups, cronjobs, etc.) 1/3 monitoring, and 1/3 vendor/product eval (hosting, various consultants for things like database tuning)

The hardest part about monitoring isn't making the tool go off, it's (1) knowing when something is broken and (2) knowing who needs to be alerted when that thing is not working. "Tell the whole team" breeds an attitude of "this is someone else's problem", and also prevents real work/progress from happening during incident response. You have to get away from the "all hands on deck" during an incident once your company gets beyond about 3-4 engineers or your feature velocity is going to get destroyed.

Also, as your company gets larger, you'll find that managing the communication around the incident is just as important as fixing the problem. Customers HATE being left in the dark, so it's important to figure out who needs to know things are broken (internally and externally) and how that's communicated.

Heroku did an excellent writeup on this topic recently: https://blog.heroku.com/archives/2014/5/9/incident-response-at-heroku -- even if you don't adopt the full system outlined there, at least ensure you're thinking about it, especially the communication part.

API Gateway is the definite gotcha with serverless architectures. Whenever someone tells me how cheaper serverless is, I figure they haven't actually dived in to see how many AWS resources besides Lambda are required for a production deployment.

It is convenient in several use cases, but for an endpoint or even an entire API that is going to receive a lot of load, managing servers is the more economical approach.

If you need to get a one-off endpoint built that won't receive any significant amount of load, I think a serverless solution is great. But I wouldn't use it as my primary API architecture. Like most things in tech, there's no silver bullet. Context matters, and the best approach depends on many factors.

I still recall this article by the creator of ipify on how he's able to receive upwards of 30 billion requests per month on Heroku for a fraction of the cost of API gateway: https://blog.heroku.com/scaling-ipify-to-30-billion-and-beyond

I had asked a similar question on Quora [1] few years back. Here is the summary:

- Facebook: https://www.facebook.com/Engineering?sk=notes

- Google: http://google-engtools.blogspot.com/

- Twitter: http://engineering.twitter.com/

- Linkedin: http://engineering.linkedin.com/blog

- Dropbox: https://tech.dropbox.com/

- Instagram: http://instagram-engineering.tumblr.com/

- Netflix: http://techblog.netflix.com/

- Flickr: http://code.flickr.com

- Etsy: http://codeascraft.etsy.com/

- Yelp: http://engineeringblog.yelp.com/

- Heroku: https://blog.heroku.com/

- Airbnb: http://nerds.airbnb.com/

- Bitly: http://word.bitly.com/

- Evernote: https://blog.evernote.com/tech/

- Highscalability: http://highscalability.com/

[1] https://www.quora.com/What-are-the-companies-that-have-some-of-the-best-engineering-blogs

yeah you're missing something, unless you're just running something low priority like a personal blog:

Although an app may not require the resources of more than a single dyno, we recommend running at least 2 dynos for a production app. One reason for this is that dynos restart roughly every 24 hours, and dyno redundancy helps ensure that you don't experience excessive queueing or dropped requests while a single dyno restarts. Additionally, dynos and the processes running on them can occasionally crash, and having another dyno helps ensure that you don't have downtime while that dyno recovers. Finally, single web dynos sleep after an hour of inactivity, and having a second dyno means that all dynos will stay awake.[1]

[1] https://blog.heroku.com/archives/2013/4/26/introducing_production_check

My problem with this type of thinking is that is too easy for Y to swoop in and take over X for you. They have the team, reputation, and recent success. You, most likely, have nothing.

Examples:
"We are facebook for bicycles!": that's just a facebook group.
"We are Heroku for PHP/Clojure/Python":http://blog.heroku.com/archives/2011/8/3/polyglot_platform/

These are my best examples, but if X is just a feature that Y could implement or acquire, then making that comparison could be a major mistake. If they expand into your niche, then your X of Y idea backfires on you hardcore.

Edit: I saw that my variables were reversed at some places.