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.

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.

We keep the Metrics tab open while we load test, and hit refresh to see what’s going on:

I would expect the graphs to expand with some sort of detail, but that’s not the case. So these metrics aren’t very useful. The logs are far more useful, so we just keep the tail open while we test.

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.

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.

As much as I love AWS EC, I prefer Heroku for apps like this. Heroku has grown up around Rails and Ruby, massive set of add-ons that are usually one-click setup, and I once had to perform an emergency app scale-up a that I completed in seconds from my mobile phone whilst riding the Bangkok subway. Doesn't get much easier than that.

Used for proofs of concept and personal projects where I want to remain in a free tier (as opposed to a service like DigitalOcean), and application state must outlive an HTTP request/response cycle.

Heroku Postgres sometimes used as a free tier PostgreSQL managed database linked to non-Heroku apps, for example AWS Lambda.

App engine fills in the gaps in the increasingly smaller case where it's necessary for us to run our own APIs.

Very easy to make cloud computing of ML models , and use containers like Kubernetes.

Cloud instances to run our app, Cloud MySQL , Network Load Balancer