Heroku removes a lot of the normal headaches that come with deploying and managing a new web app or service. It’s also a great platform for apps that need modernization. When it’s time to move your applications to the cloud, most projects can be lifted from your servers or VMs and moved straight into Heroku, but what apps aren’t great candidates for cloud migration? Here are four categories of application that will involve much more friction in migration.
1. apps that rely on the file system
[wags cane at the camera] When I was coming up in the year nineteen dickety-two, we said ‘dickety’ instead of ‘ninety’ back then, we used our server’s file system a lot. If I had to parse through a massive database result, back when memory was expensive, I would write scratch lists to disk all the time. I would even keep track of running metrics as local files which were easy enough to request when needed.
Classic? Yes. Ready for the cloud? Noooooot quite.
Was this a bad way to make apps that I should feel bad about? Certainly this had issues with being ‘stateful’. The server would slowly change ‘state’ as the local files populated. A development version of my app, running on a laptop instead of a server and critically without those local files from the server, would act slightly differently and make debugging more challenging. But especially at the time local storage was *far* superior to any remote option for short-term noncritical storage. Of course in time this storage often turned out to be long term and critical.
An application that relies on a local filesystem’s state isn’t a great fit for Heroku. Since your application on Heroku executes on ephemeral containers called ‘dynos’, when Heroku restarts your application your filesystem will be wiped. Further, when multiple dynos are started to cover increased load, each will have a filesystem that isn’t shared.
Heroku’s implementation is actually a good practice — and the platform encourages a shared backing service. This is for a good reason — this is the proven way of building apps that scale. If you’re ready to do some necessary work to modernize your app, you can move to a shared storage service such as Amazon Simple Storage Solution (S3) and a suite of logging tools that don’t write to disk (Heroku has great tools for logging built in).
2. packaged apps designed for on-prem
Isn’t this just point 1) again? Surely ‘designed to be run on-the-premises (on-prem)” is synonymous with needing a local filesystem. But there is so much more that can go into software designed to be run from your own building.
Adobe CMS’s favorite t-shirt
The biggest component that’s hard to translate to the cloud is security. Many organizations skip the hard cryptography and practice problems of security for more simplistic ‘you need to run an ethernet cable from there to your desk to get access.’ Some secure software builds use literal hardware signing: secrets that exist only on literal server hardware, to unlock. This is a strategy that just doesn’t translate to Heroku — it cares that you build secure apps, even including free SSL and automated certificate management. The platform itself, has a host of controls in place to ensure that it’s a trusted, secure platform.
Of course, Heroku has long offered great secrets management, in fact it was the first tool where I personally managed the secrets correctly in my open-source project.
But let’s take a step back and discuss the underlying need for security. Often when we seek to guarantee security what we really want to guarantee is accountability and evidence that we’ve done some diligence to ensure security. A nice thing about using a platform like Heroku is their compliance efforts are well documented.
3. The Very Slow Starter
Heroku offers very fast scaling of instances of your application and even auto-scaling so that your 4AM surge in traffic gets managed without a bunch of alerts. But this fluidity does require that your app is generally capable of spinning up in a new dyno pretty quickly.
If your app consistently takes more than 30 seconds to start, Heroku will automatically shut down the dyno. There are some tricks to get around this limit, but you should probably see it as an opportunity to modernize your application’s startup and structure. Your app should also respond to requests quickly — this means not hanging about waiting for databases and other web services to get back — but to respond now and do the long-running work in the background.
For extremely massive and slow-starting applications, the best way to migrate to a cloud platform is to explore breaking up your monolith into multiple services that communicate with Kafka, or simply a queue.
4. the overconfident starter
When is an app started? Heroku is a platform, and doesn’t have insight into the internal logic of your app. So when are you really ‘up’? Since it’s aimed at web apps, Heroku uses a simple standard: your app is ready when it binds to a particular port.
More detail on port binding and the special requirements of Heroku is documented in this lovely StackOverflow post.
There is one edge case that you need to avoid in creating your app: as soon as your app binds to a port, Heroku will start routing requests to that app. If your app is a bit, how should we say, over-confident, you’ll see errors and what’s worse you might not see errors right from Heroku but rather errors in the form of timeouts for users! Avoid this by using modern web frameworks, and ensuring your apps don’t do loads of unnecessary startup work. This will also help the very slow starters too.
Much more detail on port binding is available on the Heroku documentation.
What does work on Heroku?
Heroku is a great platform for applications that are built with modern tools or those that need modernization. Heroku’s control of secrets and configuration environment can make your security much more complete and easy to audit, so if you’re using manually placed config files, or have credentials embedded in your source code (oh dear), migrating to Heroku might be a great opportunity to modernize your process and security.
If your app is relying on local storage, again moving to Heroku might be just the push you need to switch to a better architecture where you have a shared backing resource.
If you’re creating a new app and find it can’t deploy on Heroku, you may want to examine your choice of tools and framework, since a fast-starting, fast-responding, stateless app is now de rigueur.
Check out this fantastic tour of Heroku, its requirements, and assessing whether your app is ready to go, or their documentation to get started.
Full disclosure: Heroku paid me to write about this topic, this is a dream job for me because I’ve loved Heroku since I first started in web development. Since I have to use the tools I write about, no one can pay me to like something, and the views here are 100% my own.
