Using a PaaS (Platform-as-a-Service) like Heroku, Google App Engine, or AWS BeanStalk for creating a new application is very logical. It is possible to delay hiring a full-time system administrator or DevOps and focus on delivering the actual value.
At some point, almost every startup begins to question its technology stack. Usually, this happens when the MVP was successfully delivered to end-users and the first scaling issues appear on the horizon.
It may be tempting to change the platform and switch to IaaS (Infrastructure-as-a-Service) like AWS, but is it needed? In this blog post, I am comparing AWS and Heroku from different angles to determine whether you need to switch from Heroku to Amazon Web Services.
Before we move further, let's talk about what is PaaS (Platform-as-a-Service). In essence, Platform-as-a-Service (PaaS) is a cloud computing model in which a vendor provides a platform that is capable of provisioning, running, and managing business applications without worrying about the underlying infrastructure.
Most of the PaaS does not require any deployment scripts and automatically recognizes infrastructure requirements for the application based on the package. In some cases, an additional configuration may be supplied via a simple config file.
In contrast to PaaS, Infrastructure-as-a-Service operates with lower-level abstractions like virtual machines, networks, storage, and many more. In this cloud computing model end-user still does not have access to the underlying hardware but can control virtual machines on the operating system level and adjust some aspects of the network infrastructure (e.g., firewall rules, routing tables).
It is assumed that the IaaS consumer's responsibility is to provision and maintain needed resources by using deployment scripts, configuration files, and Infrastructure-as-a-Code tools.
In some cases, it is difficult to determine what is still IaaS since some services, like AWS SQS or AWS Kinesis, are application-level and can be considered as a PaaS. Furthermore, the biggest IaaS providers like Amazon Web Services, Google Compute Cloud, Microsoft Azure provide their own PaaS offerings built on top of the same infrastructure.
It is not easy to overstate the benefits of using Heroku. It provides simple, developer-friendly deployments by simply pushing the code to a Git repository. Heroku platform automatically recognizes the application's type based on the source code, builds it, and spins off virtual machines (called "dynos").
Applications can be easily configured to work with a PostgreSQL database in one click or by issuing a single CLI command. The platform provides a variety of database sizes that will work for small, hobby projects and large enterprise applications.
Another strong side of Heroku is a rich marketplace of plugins for almost any use case, like log collection and aggregation, application performance monitoring, distributed tracing.
The simplicity of Heroku comes with a specific price. Since Heroku runs on AWS, you can think of it as a management fee. Unfortunately, this fee is very high when compared directly with IaaS. For example, at this moment, a dyno with 2.5 GiB of memory costs $250/month. Simultaneously, EC2 instances with 4 GiB of memory will cost approximately $72.5 (can be further reduced to ~$50 in the case of a yearly commitment).
The same is with Heroku PostgreSQL. A 4GB instance DB would cost $200 on Heroku and around $120 on AWS.
Of course, it is not precisely correct to compare AWS EC2 (a simple VM) or AWS RDS with Heroku (a PaaS). But the trick is AWS PaaS offering (AWS Beanstalk) is free, and you only pay for the underlying cloud resources.
Yes, BeanStalk workflow differs from Heroku, but in some cases, 40%-70% savings on changing PaaS can be a good reason to learn the new workflow.
Besides it, some case-specific things cannot be easily achieved on Heroku without going with Private or Enterprise plans. For example, end-to-end TLS encryption between compute nodes and the load balancer or TLS-enabled connection to PostgreSQL.
Furthermore, with additional services and tools, Heroku-hosted applications often start using more and more from AWS. In such situations, migrating everything to AWS may be convenient.
A rich choice of infrastructure and application-level services is a signature of AWS. At this moment, AWS has more than 200 managed services in their IaaS offering. Such a variety of services makes it possible to implement virtually any idea in a reasonable time.
Besides a wide range of services, the pricing model is also a strong side of Amazon Web Services. They regularly decrease pricing for their services and provide cost-savings options based on long-term commitments or by using a particular computing architecture.
For example, recently announced AWS Graviton2 EC2 instances are considered to be up to 40% better price-performance than x86-based instances.
While AWS Beanstalk is a bit more complex in configuration than Heroku, it provides more flexibility in network configuration, persistent storage capabilities (not present at Heroku), load balancing, and more.
Finally, AWS has a great directory of partners, which may help you with the migration or anything else connected with hosting your application on AWS.
As with any tool, strong sides dictate weak spots. AWS can be intimidatingly complex, and you may need to hire a full-time system administrator or DevOps. While AWS Beanstalk is a PaaS offering, it is still not as easy to use as Heroku.
Things that are available in Heroku right away, like Git-based deployments, are possible on AWS but will require some time and configuration.
AWS will be a great starting point for applications that require complex underlying infrastructure and many managed services. Heroku can be a good choice for simple applications that will evolve.
First of all, you need to decide the purpose of the migration from Heroku to AWS. How is it going to benefit your product, business, and end-users? Without answering these questions, I would consider the migration unjustified.
Let's go over common arguments for migrating from Heroku to AWS and determine when they are valid. I created a table below to navigate through them and identify possible counter-arguments and tools that will help decide.