|Heroku||Google App Engine||AWS Elastic Beanstalk|
|Hacker News, Reddit, Stack Overflow Stats|
|Description||Build, deliver, monitor and scale web apps and APIs with a trail blazing developer experience.||Build web applications on the same scalable systems that power Google applications||Quickly deploy and manage applications in the AWS cloud.|
|Why people like using this service||
|Companies using this service|
Great way to get apps out there, easy to outgrow
February 04, 2014 11:12
Can't beat the simplicity of deploying and managing apps, the pricing is a bit high, but you are paying for those streamlined tools. However, after several experiences of tracing issues back to Heroku's stack, not having visibility into what they are doing has prompted moving two applications off of it and on to other more transparent cloud solutions. Heroku is amazing for what it is, hosting for early stage products.
Indispensable for prototyping
February 04, 2014 03:51
I've been using Heroku for 3 years now, they have grown super fast and each time they're improving their services. What I really like the most is how easily you can show to your client the advances on you project, it would take you maximum 15 minutes to configure two environments (Staging/Production). It is simply essential and fantastic!
Good servers to start out on
May 10, 2014 14:11
I use Heroku as a starting server for my app. Heroku is easy to use and isn't crashing on me all the time.
Heroku is for everyone
March 24, 2014 06:39
I use Heroku, for almost any project of mine. Their free plan is awesome for testing, solo developers or your startup and its almost impossible to not cover you somehow. Adding an add on is a simple command away and I find it easy to use it both on my Windows PC or my Linux laptop. Their documentation, covers almost everything. In particular I have used Heroku for Spring, Django and AngularJS. I even find it easier to run my project on my local dev with foreman start, than ./manage.py runserver (for my django projects). There is no place like Heroku for the developer!
Stress free PAAS
May 05, 2014 01:47
Using Heroku takes away all the pains associated with managing compute and backing services. It may require a little extra optimisation and tweaks, but these constraints often make your app better anyway.
Easy to Use and Free to Get Started
April 06, 2016 08:39
I liked how easy this was to use and that I could create some proof of concepts without have to pay. The downside for NodeJS is remote debugging. Pretty much have to depend on logging where Azure allows remote debugging with Node Inspector.
Easily create scalable backend for mobile
March 27, 2014 07:50
With Cloud Endpoints you can create and deploy mobile backend in one hour or less. And it is free (until you need extra scale). I would not recommend to use Java - python is faster and has all new appengine features.
Pros: everything is in one place: task queue, cron, backend instances for data processing, datastore, mapreduce. Cons: you cannot easily move your code from GAE. Even with special 3rd party services.
used heroku on and off for many projects over the last 5 years. quick and dirty application infrastructure without the headaches. it ain't cheap up its worth the time savings.
Our main apps are hosted on Heroku. We use Papertrail for logging, the Heroku Scheduler to automate rake tasks and deploy automatically through CircleCI.
Main platform of deployment. This proved to be the easiest with our React + Node stack.
We had the develop branch deployed on a staging subdomain and master on the rootdomain.
Used to host Shift's API and we built a deployment engine which utilises Heroku's Platform API to deploy client front-end websites without requiring the client to have devops experience.
Heroku runs the web and background worker processes. Auto-deployments are triggered via GitHub commits and wait for the Buildkite test build to pass. Heroku pipelines with beta release phase execution (for automatically running database migrations) allowed for easy manual testing of big new releases. Web and worker logs are sent to Papertrail.
Hosts the main Sweat Shop application as well as all worker applications (deployed on their own instances)
5 years of experience using Heroku for application deployment, management, and production.
Heroku is amazing. We use the effortless git integration to deploy code for review to our clients. We also have projects that run on Heroku in production.
With its complimentary SSL (on *.herokuapp.com) we can test everything. Our dev branch is built and deployed out to Heroku. Testing happens out here. not production cause $20/mo is TOO much to pay for the ability to use my own SSL purchased elsewhere.
Not having to deal with servers is a huge win for us. There are certainly trade-offs (having to wait if the platform is down as opposed to being able to fix the issue), but we’re happy being on Heroku right now. Being able to focus 100% of our technical efforts on application code is immensely helpful.
Two dynos seems to be the sweet spot for our application. We can handle traffic spikes and get pretty consistent performance otherwise.
We have a total of four apps on Heroku: Legacy Leanstack, StackShare Prod, StackShare Staging, StackShare Dev. Protip: if you’re setting up multiple environments based on your prod environment, just run heroku fork app name. Super useful, it copies over your db, add-ons, and settings.
We have a develop branch on GitHub that we push to dev to test out, then if everything is cool we push it to staging and eventually prod. Hotfixes of course go straight to staging and then prod usually.
Our app is built using Ruby on Rails. We deploy on Heroku via github. We have separate instances for prod and staging, and can increase/decrease dyno's depending on load.
We had Postgres, and we started on Heroku. When an order would come in, we would just send it to a shopper. Whichever shopper received an order last, so it’s kind of just like this revolving door of shoppers getting text messages that would lead them to a web page that wasn’t really mobile formatted, that just told them what to get, and then they would say “I got it,” and that was like the extent of the smarts of it. We just iterated.
So overall, I would say it’s somewhat indicative of the way we work, which is we try to push something up as soon as we can, the smallest possible version of whatever it is and then iterate and iterate and iterate until we get it right.
checking a swap require a lot of cpu resource, roster normally come out same day of month, every month, at a particular time. Which make very high spike, our flag ship product, iSwap, with the capability looking swap possibility with 10000 other rosters base on user critieria, you need a cloud computing give you this magnitude of computing power. gae did it nicely, user friendly, easy to you, low cost.
PaaS for back-end components, including external data ingestion APIs, front-end web service APIs, hosting of static front-end application assets, back-end data processing pipeline microservices, APIs to storage infrastructure (Cloud SQL and Memcached), and data processing pipeline task queues and cron jobs. Task queue fan-out and auto-scaling of back-end microservice instances provide parallelism for high velocity data processing.
Elastic Beanstalk manages our environments. We rely on it to manage rolling out new versions of services.