Ilek migration from Heroku
As Heroku, or rather, Salesforce, pushed more and more Ilek to make a decision about an "Entreprise" class of account they studied the feasability of a migration to another provider with us.
Initial conversation with Ilek
Ilek faced a comparable problem to companies that have depended on Heroku for their initial growth and development within the first 3 to 5 years. Let's examine what they were seeking.
- Security. As Ilek's engineering team had started to build and deploy custom macro services they needed a way to isolate internal services from the internet. Such a feature was very costly with Heroku, a mere checkbox with most IaaS providers.
- CI/CD. With multiple services being built and deployed daily it was important the CI/CD integration was easy and efficient. Although not an issue with Heroku this was very important to consider when comparing IaaS providers.
- Networking. As Ilek's company continued to expand, managing multiple services with varying degrees of public accessibility became increasingly important. This drove the need for greater control over the routing and networking layer.
- Scalability. The Heroku compute offering lacks granularity and doesn't allow for easy resource sharing among multiple services. As the number of services grew, it became evident that this was hindering the team's ability to scale each service effectively.
- Cost. Although Heroku's PaaS provides great services behind the scenes, its design, such as the lack of granularity of the compute offering and the additional cost for private network zones, promised significant expenses if they were to continue along that path.
Upon careful consideration of these factors and the engineering team's roadmap, it became evident that continuing with Heroku would result in a significant increase in costs, while also limiting access to now standard tools and services.
Things to consider
Planning the migration
Although Ilek's CTO had no preference, the replacement choice became clear rather quickly. Since some of Ilek's resources were already hosted within AWS, it made sense to plan for AWS to replace Heroku.
What was needed
While AWS seemed the obvious candidate we had to consider the following requirements.
- Private and Public networks. Resources needed to be split between public and private networks to comply with the security aspect of their project.
- Managed, highly available databases. Most services developed and maintained by Ilek's team rely on PostgreSQL. A solution to setup managed and highly available instances was key.
- Auto scalable, mutualised compute resources. To avoid falling into the same issue as with Heroku and suffer from a waste of compute capacity due to a lack of mutualised compute solution we needed to have a way to deploy dockerized applications within a cluster of compute instances.
- Reducing costs and making them predictable. Migrating to a IaaS provider often incur unpredictable costs. To avoid such issues, we needed to be able to have billing alerts and a way to have discounts for long term resources.
What was chosen
After testing a few options and researching the different services available on AWS in each case we came up with the following.
- Private and Public networks. AWS comes right out of the box with VPC and a support for public and private subnets. The included network security also allows to secure all the traffic right away.
- Managed, highly available databases. AWS RDS isn't the cheapest solution on the market but it provides a good, reliable service to host PostgreSQL instances in all their regions. Configurable with or without a high availability option it's also flexible enough to plan for non production uses.
Auto scalable, mutualised compute resources. Many companies opt for Kubernetes as their container orchestration solution, but Ilek's CTO and our team were not convinced it was the best choice for them. Kubernetes adds complexity and requires specialized expertise in infrastructure management.
Given Ilek's team lacked infrastructure specialists, a solution closer to Docker and AWS was deemed more appropriate. AWS ECS was selected as a middle ground between a custom container orchestration solution and Kubernetes. It's also well integrated within AWS's suite of services, simplifying the team's management tasks.
When paired with EC2 Auto Scaling Groups and load balancers, AWS ECS provides a stable and robust solution that aligns with AWS's established primitives.
Reducing costs and making them predictable. AWS provides several tools and features to help with reducing costs and making them predictable. One such tool is billing alerts, which allows you to set up notifications for when you're approaching or exceed a certain spending threshold. This helps you keep track of your expenses and avoid any unexpected charges.
Another tool is budgets, which allows you to set up spending limits and get alerts when you're about to exceed them. This helps you stay within your budget and avoid overspending.
AWS also offers spot instances, which are spare compute capacity that can be purchased at a discount compared to on-demand instances. This allows you to save money on your compute costs, especially for non-critical workloads that can tolerate interruptions.
Additionally, AWS allows to reserve instances, which allow you to commit to a certain amount of compute capacity for a term of one or three years. This can result in significant savings compared to on-demand instances.
Overall, with these tools and features, AWS helps you reduce costs and make them more predictable, which can be especially helpful when migrating from a platform like Heroku where costs can quickly spiral out of control.
As Ilek's fleet of service was, at the time, relatively small. The migration of all of them didn't take much time. What kept us initially busy was not so much the setup of the infrastructure but the preparation of all the tooling required to make the transition as smooth as possible for the team.
None the less the migration progressed at a good pace once the first service was migrated. We started by migrating all compute resources. Since Heroku's PostgreSQL clusters are accessible over the internet, containers running within AWS had no issues accessing them. This allowed us to prepare the compute resources beforehand and limited the downtimes experienced.
In a few months all services were migrated and hosted on AWS instead of Heroku. There was not major issue caused by the migration and although some downtime could not be avoided when migrating the databases it was always very limited.