SSL Is Now Included on All Paid Dynos
blog.heroku.com
blog.heroku.com
If you want to get the certificates for free as well, there's a guide at the link below that can help for setting this up with Let's Encrypt. The title is "LET'S ENCRYPT WITH A RAILS APP ON HEROKU", but I followed mostly the same steps for a Flask/Python app and it worked fine. The only step that was Rails specific was for setting up a route to the verification content, which is pretty easy to do in any framework that I can think of (to verify the website's ownership, Let's Encrypt makes you setup an endpoint at <your-site>/.well-known/acme-challenge/<verification-string-they-give-you> that simply returns a long random string they give you in the CLI). See: http://collectiveidea.com/blog/archives/2016/01/12/lets-encr...
I can't go anywhere else do service create followed by git push service master and be ready to go within a minute.
Almost the same features plus you can install a Let's Encrypt plugin to handle SSL for free. Main difference is that you can't scale up - doesn't have that whole dynos thing.
I'd pay more than 20 dollars.
But it doesn't replace having to keep your OS updated, dangling with firewalls, etc.
However the premium you pay for that experience continues to rise, while the alternatives are expanding dramatically (GC, AWS, DO, other PaaS).
In the very near future I really hope to see cloud vendors losing a lot of their business for hosted applications, and just becoming big elastic pools of bytes and FLOPs, with open source orchestration tools managing the consumption of those resources and keeping cognitive overhead low.
Since he said hobby app, I'd say throw it Digital Ocean for $5, running Ubuntu and letsencrypt for SSL. Use the DO guides to install whatever you want instead of paying separately for each service.
It's much more natural now that I have some experience and now my little hobby apps can go on that cluster, and if I decide I want to deploy one for reals, it's just a few tweaks to get it going in any number of places.
Usually there's some junk on DO or AWS, only a couple guys know where anything is. "Cheaper" because we don't track time lost to "what instance is <environment>.<app> on?" "How do I <dead simple task> without <toppling house of cards>?"
Team A: had lots and lots of sites all on a single dedicated 2U rack server at a call-for-pricing provider, didn't really understand how to run it or that they had other options. Disk controller failed in a way that trashed the journal on the databases' volumes. They got a weekly backup restored but customers were furious. I had to explain that moving things to the "cloud" in the form of a single big VPS wasn't magically going to prevent similar risks.
Team B: had 1 app, could have been a single dyno most of the time, scaled to 2 ahead of media announcements and the like (not worth considering/mo) and testing / staging environments could have been spun up with activity/on feature branches, so sub 100 bucks. Instead had 2 VPS (live/everything else) for only tens of bucks a month, but "dev-ops" guy never really completed or got assigned sprint tasks because he was too busy smelling like gunpowder and patching up holes in his feet.
Team C: Big multi-tenant monolith-app on a dedicated rack at a call-for-pricing, wanted to figure out autoscaling, continuous deployment, review apps (every feature branch has an environment so you're not prematurely integrating code to get it deployed to a single bottle-neck staging branch+environment) how to bring up new apps (break tenants out to their own environments so they stop having noisy neighbor problems) etc so they could spend more time delivering value to the customer than having to ssh into things and running down checklists. They picked AWS, ansible, docker, kube -- everything "hip". Year later I think they're still "working on it".
Team D: Enterprise, Everything is at central IT, we write apps with nice search features but IT doesn't want to learn how to spin up elastic search, so we get to write bastardized slow and less usable version. Meanwhile we're trying to figure out AWS, but everything's just pets managed by hand in the web console! We burn lots of money on people forgetting to shut down one-off instances and other people not having any info about what all of them are enough to clean up.
Team E: "Knows what they are doing", hundreds of apps and services, owns their own top of the line hardware with a dedicated NOC team, those salaries actually amortize across each project pretty well, automates the hell out of everything with Puppet, doesn't bother with virtualization, they have the engineering resources to write code that manages real apps on real OSes on real hardware. However, most of that hardware sits with 50% RAM utilization and 5% CPU utilization. Day-to-day operations are smooth and very cheap but they way, way overspend on capital (hardware and automation code).
Team F: Team E but nothing is automated or smooth, everything is virtualized and they spend too much on ops contractors getting paged at night to resize a 4gb LVM volume on a 20TB storage array (19TB free) because it got half-full of unrotated logs, or because a build box had two builds going at once and load average went above some silly arbitrary threshold.
I'm a technologist but I hate watching tech organizations solve tech problems instead of business problems. I see lots of people doing the equivalent of drunk driving and complaining that Uber's so much more expensive than the gas.
Of course, if you need and can build a software development lifecycle comparable to Heroku Pipelines or a PaaS comparable to Heroku itself or a database service comparable to Heroku Postgres, a IaaS comparable to AWS/GCE, etc. down to the metal and the cost of your solution plus the capital investment amortizes somewhere below what those services cost, go do that. Plenty of folks are in that position and should of course do so.
Napkin math: It takes a whole year of dyno hours before you begin to approach what it costs to waste a day of a developer's time, or a 1 hour meeting between eight of them about "what branch is on <environment> right now?" It takes having a mean of 200 dynos running before you begin to approach what it costs to have a single ops salary.
I'm interested to know how performance compares to the add-on, which uses a dedicated ELB per app (which is why it cost $20). On the one hand I would imagine switching to this new feature removes the need to pre-warm the endpoint (https://devcenter.heroku.com/articles/ssl-endpoint#performan...), but on the other could presumably introduce noisy neighbour issues.
"we will be rolling out exciting new features to it over the coming months" ...native Let's Encrypt support perhaps? :-)
I'm sure eventually they'll add automatic LetsEncrypt certificates too. But in the meantime if you're using Ruby on Rails on Heroku, this gem (that I made) will probably help: https://github.com/pixielabs/letsencrypt-rails-heroku
So it's Heroku reacting to that push by encrypting inbound data, and then storing it in a cloud with zero privacy protection.
Which, I don't mean to be cynical - it's way better than not encrypting at all, it's just a bit funny, in a sad, Orwellian way.
What data are they storing? I'm pretty sure they just pipe the inbound request to whatever process is running your app. They (Heroku) aren't saving every request or response body. It'd be an insane amount of traffic.
Now someone could tap into that but none of this makes things less secure. They're just changing the way inbound SSL is handled by offering free SNI based SSL to everybody. That's a good thing, not a bad thing. The alternative is having a dedicated endpoint per application serving the exact certificate for that app (which is why the cost for it was non-free before).
Also, here's a great server side TLS guide that explains best practices for TLS: https://wiki.mozilla.org/Security/Server_Side_TLS
Heroku's day has come and gone, quite frankly. Obviously, I'm biased because I'm the author, but you should evaluate it for yourself.
But, it's still absolutely true. For Python users, you should use Zappa for web apps and ECS for anything that requires long-running processes. I just don't see how Heroku makes sense any more.