#2. PaaS is too expensive
But Heroku is soooo expensive! This is herd thinking and ignores the cost of finding, recruiting, and training great devops people to build and maintain your snowflake infrastructure. Not to mention the cost of retaining these people, putting them in an office, and providing ping pong tables or whatever else it takes to keep them happy.
Then there is the opportunity cost of hiring people in devops and sysadmin roles instead of product engineering. And those costs increase linearly as your business scales. With Heroku, you have diminishing marginal costs at scale.
And don’t forget the additional cost of your lack of focus. If you’re dealing with peripheral infrastructure matters, you’re not focused on making your product better.
Paying Heroku means you don’t have to worry about building your infrastructure and keeping it available at all times—and it still costs the same or less than hiring and retaining those additional ops people.
#3. PaaS is too constraining
But… but… my snowflake! A lot of people think their application or architecture has unique needs. In most cases, it doesn’t—and if it does, it probably shouldn’t. However, I’m prepared to accept a few legitimate reasons you might not be able to use Heroku. Here they are:
- You need tons of CPU or RAM. Heroku won’t scale as far as AWS, and configurations are a bit less flexible. If you really need thousands of servers, AWS (or even bare metal) may be more economical. But Heroku supports some pretty sizeable instances. For most people, it should be more than enough.
- You need bare-metal servers or specialty processors. If you’re doing machine learning or other GPU-intensive work, Heroku might not be a great fit. However, you can still take a hybrid approach like we do. We use Heroku, but also bare-metal servers to get the best performance for our virtualization platform.
#4. Heroku doesn’t do Docker
But I must have Docker! Fret no more. Since early September, you can deploy Docker images to Heroku. Even before that, Heroku included somewhat similar capabilities to Docker, allowing you to ship around containerized builds of your app.
.. #5. Heroku is not secure enough
.. There is no reason to believe Heroku is meaningfully less secure than AWS.
.. Plus, unlike your custom environment, Heroku is consistent and uniform. It has boundaries that are clearly defined, which means your attack surface is going to be smaller. That also means it’s easier to understand, so you’re less likely to do something by accident that creates a vulnerability.
Should your EC2 be a Lambda?
How much would you save by going serverless? Which of your applications can harness event-driven architecture, blazing-fast deployment, incredible scalability, and decreased cost of AWS Lambda? Use this handy calculator to find out!
Using Free LetsEncrypt Https SSL on Bitnami Lamp on EC2
If you want to try out the new free SSL certificate using LetsEncrypt for a web site hosted on Bitnami LAMP Stack on Amazon EC2, here is how I did it.
First of all I’m using a very simple apache install on bitnami, so the default bitnami supplied scripts to configure apache2 and mysql and php are all still there in the default location.
Introducing Heroku Button
When you see a Heroku Button in a README, in documentation or in a blog post, then this is a piece of code that’s ready to deploy and run on Heroku.
When you click a Heroku Button, you access a setup flow in Dashboard. If you’re not logged in or don’t have an account, you’ll go through the login flow first. Heroku then determines what code you’re trying to deploy (using either the
referer
header or a parameter in the button URL). Heroku uses an app.json manifest in the code repo to figure out what add-ons, config and other deployment steps are required to make the code run. This is used to configure and deploy the app.