I was excited to be invited to participate as a delegate at AppDev Field Day 2 in Salt Lake City, running parallel to KubeCon + CloudNativeCon. Due to an unplanned bird collision, my flight was delayed, but I arrived in time to attend the Heroko presentation on day 1. I’d heard of Heroku way back in the day, and think I may have even tried their free tier back in their startup days before the Salesforce acquisition in 2011. But this was my first opportunity to learn about the company and its offerings first hand.

Heroku: Leave the DevOps to Us

Heroku’s value proposition to developers is that they can code and deploy their application without really needing to worry about all the infrastructure required to make it happen. Developers can focus on what they do best and trust that the team at Heroku will manage and maintain everything from containers to databases SSL certificates and more to keep the application running and scale it to meet demand. I can’t generalize about all developers because I don’t know them all, but almost all of the developers I’ve worked with across multiple organizations want to write code and push it to the environment on which their users will access it.

An Ops Pro Perspective

I’ve been on the operations side of things for nearly 28 years. So I was intrigued to learn more about Heroku and the cloud provider on which it runs.  When I asked that question, the presenter said they run on AWS. Heroku abstracts away the complexity of AWS infrastructure and presents it to the customer as a Dyno, which they call the "building blocks that power any Heroku app."

I can hear my fellow sysadmins, even those of us who are called cloud architects these days, saying, “but couldn’t we just build that ourselves? Aren’t we paying a premium for this ‘as a service’ over and above whatever AWS would charge us for infrastructure?” I’m betting the answers to those questions are “maybe” and “probably” - but I gotta be blunt - both in my current role and given that my plate always has more being added to it, I’m not sure why I’d want to. I could build Windows Server VMs in Azure, setup IIS, and have our developers deploy apps to them as well, but I don’t. I manage App Services on App Service Plans and, more and more, I’m considering migrating to Azure Kubernetes Service. Whether I’m one of several architects in a large IT department or a single IT Pro working for a smaller company, I’d rather not have to deal with some of the lower level infrastructure if I don’t have to.

What’s Next for Heroku?

It seemed clear to me that, having pitched their platform primarily to developers since the beginning, Heroku is also tailoring their message to the operations side of the house. They’re clearly adopting open standards and, while the opinionated nature of their platform is a strength, they’ve done a lot of work to allow customers to integrate with other tools if one aspect or another of the Heroku platform isn’t a perfect fit.

Here are a couple of pics I snapped during the presentation. HTTP/2 ought to speed up websites running on Heroku, and speaking as someone who still deals with far too many manually provisioned SSL certificates, Heroku’s Automated Certficate Management feature supporting wildcard domains sounds fantastic. Let’s Encrypt made this possible for me on this blog back in 2018, and I still look forward to a day when I never have to worry about certificates again. 

Many of the apps my organization builds and maintains are written in .NET, so having support for it come to Heroku was a nice surprise. We have a bit of some of their other supported languages sprinkled around as well.

My first Tech Field Day

Not gonna lie - it was a bit intimidating sitting there with folks I’d previously only seen on the TFD streams. The experience was fantastic, though, and I enjoyed learning more about Heroku and offering feedback to them. I’ll be keeping an eye on them and look forward to hearing about any new annoucements they may have in the pipeline.