Heroku: the PaaS of the Past Struggles To Keep Up

If there's one thing almost every developer has done in their life, it's deploy an application to Heroku.

From their launch in 2007, Heroku dominated PaaS and caught the attention of Salesforce who acquired them in 2010. They had the first managed Postgres service in 2011, an easy to use CLI, and, last but not least, it was free to get started which led to a big uptick in initial popularity. Every side project from here to the moon went to Heroku.

After acquisition the team at Heroku started adding support for languages other than Ruby -- and the platform stayed relevant for the years to come. Many developers still rely on Heroku to get their new projects off the ground or to do proof of concepts and early scaling.

But, in the last few years, I've talked to a lot of developers who are wondering "what's next for Heroku?". They've seen a stale trickle of updates and a mostly "more of the same" type release schedule.

Is the once great king of PaaS officially dead for real projects? Let's take a look.

What does a Heroku Deployment Look Like?

Generally you'll piece together a project that will have:

• Dynos - similar to a linux container but paired with a language or framework.
• Data Service - an optional managed data service.
• Mem Cache - an optional in memory cache like Redis.
• Addons - there are tons of additional "addons". From Email to logging and more.

Heroku has undertaken some modernization so that developers can use a GitOps-style deployment pattern, and most users I've spoken with adopt this. It does help to remove a lot of the stress on developers who don't want to get in the weeds with anything more than just pushing new code to GitHub and having Heroku take it from there. The scalability of the platform is moderate, giving users easy access to scaling simple applications, and overall people generally rank it as easy to use.

A few of the things to watch out for with a Heroku deployment are:

• Cost - which can quickly escalate as the project grows and requires more resources.
• Limited Control - not many ways to interact with the underlying servers.
• DB Limits - outside of enterprise tiers there are strict row limits on databases.
• Vendor Lock - migrating off of Heroku is objectively more challenging the longer their platform is used.

How is Cycle.io Different?

There are several big differences between the Cycle platform and Heroku.

Bring Your Own Infrastructure

In Herokus model, you tell Heroku what type of server/dyno is desired based on resource type CPU's, RAM, disk etc, but retain limited control over the actual type of processor or generation of EC2 instance being paired with (much less the provider of the compute as Heroku is strictly AWS). If something goes wrong at the server level, you'll have to interact with their team to get information about the running server and ask them to make fixes or proxy information back.

With Cycle, you still have complete access to the IaaS account and choose the exact model of server(s) deployed. Being able to bring your own infrastructure also means control over the location and regionality of the servers (most of the time all the way down to the datacenter, whereas on Heroku you can only select US or Europe and that's it.

Cycle even runs on-prem, but that's a story for another time.

Containers vs Dynos

Where Heroku leans towards PaaS, Cycle falls heavily into the container orchestration space. Heroku’s Dynos, which are individual servers behind the scenes, abstract a bit of the complexity and are designed for language/framework specific deployments where Cycle’s approach with containers lets developers deploy applications built with whichever technology a development team chooses.

Additionally, these Dynos are limited to a single app per "dyno" and additional dynos will need to be deployed per service for scale. With Cycle organizations can run as many containers on a single server as desired, giving users greater flexibility and density on each server.

Addons

Heroku's addons are generally wrappers around some AWS resource or 3rd party service. Today, Cycle doesn't use the "addons” concept, but, because organizations maintain ownership of their infrastructure, networks, and data, connecting with other IaaS services is simple and secure. This makes the setup of your SaaS application on Cycle and then connecting it to RDS or DynamoDB is trivial. Additionally, being a container platform, many of our users spin up services that would be "addons" to run alongside their application containers.

Proponents of our system would likely point out that while these integrations aren't "native", the user remains in full control of the networks, specifications, version, location, etc for the IaaS service which can be very appealing for a growing company, especially those that are looking to have deep compliance documentation.

The Right Time To Migrate

If your organization is currently on Heroku (or another "Heroku-like" platform) and you’re feeling the weight of having a low ceiling pressing down re: development capabilities, here are 3 signs we've seen as signals that it's time to migrate.

1. Wanting to pursue a more transparent, observable, and highly available infrastructure.
2. Looking for more advanced control over their apps and environments.
3. Cost transparency and predictability are becoming more meaningful.

Want to learn more about how migrating to Cycle can have an impact on your project? Just want to explore more of what Cycle has to offer? We'd love to hear from you.

💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!