Heroku

Most of our apps and services start life on heroku before moving upstream to AWS. Heroku

We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).

We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .

Read the blog post to go more in depth.

We undertook the task of building a manufacturing ERP for small branded manufacturers. We needed to build a lot, fast with a small team, and have clear focus on product delivery. We chose JavaScript / Node.js ( React + LoopBack full stack) , Heroku and Heroku Postgres (also Heroku Redis ) . This decision has guided us to picking other key technologies. It has granted us high pace of product delivery and service availability while operating with a small team.

We use Heroku because it's easy and fast. We spend 0 time on DevOps stuff (and I've spent a lot of time on that before), and it just keeps running. One click install of add-ons, and consolidated sign on with billing is awesome.

If you're going to use a lot of memory or run many processes it gets expensive fast. But you probably shouldn't use that much memory and you rarely need to run many processes. Heroku will start a new process if one dies (rare), so if you need extreme up time you can pay for running multiples. :)

Their support is stellar even though we don't pay for top tier support. Since we're off timezone wise it might take some time to get responses. But they always connect me to someone with deep technical insights that give concrete feedback and helpful information even when my problems are of the less common ones.

We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.

We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.

The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.

Sometimes #ad-blocking addons can cause a real headache when working with JavaScript apps. Onboarding assistants (Appcues + elevio ), chat (Intercom) and product usage insight (Hotjar) have all landed on their blacklists. I guess there is a perfectly good reason for this that I just don't know.

In order to fix this, we had to set up our own content delivery service. We chose Amazon CloudFront and Amazon S3 to do the job because it has a good synergy with Heroku PaaS we are already using.