Ilek migration from Heroku

• 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.

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.

• 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.

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.