Terraform Tooling for Small and Medium Businesses

A frank discussion of current products in the Hashicorp ecosystem


For our avid Terraform Small and Medium Business (SMB) stakeholders, I thought it would make for an interesting article to do a straightforward and honest features analysis of the current Terraform Tools space. These are my opinions on market trends and the pros and cons of different solutions currently available. This will be an evaluation of the current state (a snapshot in time) of the tools meant to make Terraform easier to use for SMB.

If you have feedback to share about this article (or are looking to discuss further), join our InfraCode Slack Community to connect and chat.

Note: The below discussion is solely my opinion of the current Terraform tooling available. I’m taking a critical, but honest approach to the tools, in the spirit of DevOps and open-source. As I noted above, I’m open to feedback and would love to hear your thoughts.​

Cloudcraft and Modules.tf: A Brief Overviewlink icon

Cloudcraft is a tool to allow you to diagrammatically represent your AWS cloud infrastructure. The plugin modules.tf is an open-source project maintained by Anton Babenko, meant to take the diagrammatic drawings in Cloudcraft and convert them into actual, working Terraform architecture. Anton uses the Terragrunt wrapper, supported by Gruntwork (which we’ll get to in just a minute), to make the architecture designs in Cloudcraft scalable and deliver working code.

Cloudcraft itself is a neat idea; however, their product roadmap and time to production with new features have been slow and since their most recent filing for 2019 shows only $150,000 of ARR, likely future growth of their tools may prove to be problematic. It’s very possible that either timing of their go-to-market or operational excellence was off, but I believe their core idea was strong.

The Gruntwork Suite: From Terraform Templates to Subscription Businesslink icon

With 300% year over year growth in recurring revenue (now $3M of ARR) and no signs of slowing down, Gruntwork is a behemoth in the Terraform ecosystem right now, and their core focus is on SMB. Gruntwork started out with a focus on their Infrastructure as Code library all the way back in 2015. Their founder, Yevgeniy Brikman is considered to be a pre-eminent thought leader in Terraform. Throughout forums and communities, many people still refer to his initial writing in 2018, “Terraform Up and Running” as the definitive best resource for Terraform tutorials.

Gruntwork’s business initially started out focusing on consulting, by building out Terraform templates and code for customers who wanted expertise in the (at that point in time) very new system. They then turned their research, code, and credibility into a subscription business around “Reusable, composable, battle-tested Terraform modules”. A portion of their library is “open-source” in name, only to essentially prove their authority and assert participation in the open-source community. The vast majority of their code library, including the production-ready IaC is hidden behind their pricey subscription service, coming in at $800/mo for your organization for the AWS library alone, with pricing for other libraries (and likely additional custom services) hidden behind what is most likely a gateway to a more traditional Enterprise Sales Cycle. There are comparable libraries and repositories maintained in an open-source fashion, most notably “Terraform AWS Modules” on Github.

Terragrunt represents Gruntwork’s first actual endeavor into open-source with a “thin wrapper that… [keeps] your configurations DRY, [works] with multiple Terraform modules, and [manages] remote state.” In case you didn’t catch all of that, Terragrunt is essentially a suped-up File Management System for Terraform architecture to try and make your life easier. On paper, this seems good--especially when you’re first starting out with Terraform and want to make file management easy. However, there is unseen accidental technical debt when you implement Terragrunt because the architectural paradigms used are an anti-pattern at scale for most organizations. Gruntwork takes the opportunity to layer in a service-based offering for enterprises that reach an appropriate scale, with an anti-pattern that can’t easily be undone, and packages it as a further upsell.

Gruntwork is an interesting case in the IaC space. With huge cash flows and a robust business, obsolescence is a low risk as they likely will not let their product offerings deprecate any time soon. That being said, people buying into Gruntwork thinking they’re only buying into Terraform are, in fact, buying into the Gruntwork ecosystem which could incur unforeseen costs in the future.

Scalr: Recent Launchlink icon

I have a lot of things to say about Scalr, and unfortunately, most of them aren’t very good. Founded by Sebastian Stadil, Scalr raised their Series A in 2016 for $7.5 million and is a Silicon Valley company. Scalr is supposed to present an alternative to Terraform Cloud with the “Remote State” feature and RBAC and IAM policies for Terraform deployments.

They just recently launched as of my writing this article, and while there’s a lot to say about this launch, I think this (very upvoted) Reddit post on their launch announcement says it way better than I possibly could:

Source: Reddit R/DevOps

I suspect that Scalr cut their teeth on their Cloud Management Platform offering in a pure enterprise software sales model and this is their attempted transition into an SMB vertical, as their venture capitalists are demanding growth in their business model. With the amount of capital raised 4 years ago, OpenView (the VC firm) is likely demanding expansion, now, so they can get closer to returns on their investment. This could be predicated on the fact that the Cloud Management Platform hit saturation faster than anticipated. However, this is pure speculation on my part-- so take it with a grain of salt.

For a company in the DevOps space that’s supposed to have competency and expertise in these areas of policy management and RBAC, the launch of their flagship Small Business tool having security lapses as described above is nothing short of embarrassing. It’s a branding and PR nightmare to have the DevOps community, which is super active, speak up and lodge complaints on launch of a paid version.

Furthermore, a platform with security at its core is entirely brokered on continuous and unwavering trust, so to release after “18 months of hard work” is extremely concerning. Time will tell if I’m wrong about this, but as of now, it looks like a mess.

Terraform Cloud: A Hashicorp Productlink icon

Found by scrolling down the new Terraform website to the pricing section, Terraform Cloud is Hashicorp’s productized answer to what they understand as an underserved SMB market. While I haven’t recorded particular examples quite as stark as the above Reddit post to Terraform Cloud, I think the general sentiment from a lot of the DevOps communities I participate in is that Terraform Cloud is underwhelming, and I believe Hashicorp knows that too.

With the current state of GitOps and pipelines, and the nature of IaC, managing Remote State is currently the most challenging part of Terraform for small organizations. You can count on Hashicorp’s continued immaculate execution on that particular critical feature set, as for most SMBs, continued usage of HashiCorp’s Open Source suite is becoming more and more important. Hashicorp will do everything it can to ensure that when those companies mature in their ecosystem, they’re the same companies that use Hashicorp’s services. Therefore, it’s in Hashicorp’s interests to enable small tech companies, to the best of their ability, to succeed while maintaining full operational velocity on the features that their largest enterprise customers are demanding. I don’t think it’s Hashicorp’s execution on Terraform Cloud that was lackluster. Instead, I think it's an organizational decision to do what they can for SMB with the amount of resources they currently have-- and speaks to a broader strategic roadmap.

InfraRapid: Custom Terraform Templateslink icon

InfraRapid is my company, Infracode’s, initial open-source product offering. Since I’ve taken a critical, but what I consider rational tone, for everyone else’s product, I’ll try my best to maintain transparency (a value at the heart of everything we do at Infracode) about the reality of InfraRapid and InfraCode.

I started InfraCode in June 2020 because I saw the gaps companies weren’t adequately filling in SMB around Hashicorp’s product suite. As I write about in my first post, we believe cloud-agnostic provisioning is going to be critical moving forward for organizations, specifically because of an explosion for SMBs in cloud operational complexity. As High Availability and Service Level Agreements become standard expectations because of the Cloud Operating Model, smaller technology companies providing mission-critical software are going to be expected to deliver their technology to those same standards if they’re going to win contracts.

Because of difficulty in learning Terraform and the Cloud providers themselves (as evidenced by the ungodly number of certifications available on any given platform) and a general explosion in DevOps tools, it became obvious that no small organization could possibly bring on the necessary people and resources to deliver at service expectations. The knowledge and skills gap was foreign to most of these founders, and the costs incurred on their businesses was proving increasingly challenging.

InfraRapid is our first barebones attempt at a patch fix, an Alpha open-source library to generate custom Terraform templates from YAML files. Our library currently supports generic compute resources for AWS and Azure. We plan to, as soon as possible, begin adding cloud providers and introducing more elements. That being said, our goal is to provide simple cloud-agnostic provisioning, as vendor lock-in and future costs accrued by getting stuck in their specific vendor ecosystem (i.e. AWS, Azure, GCP, etc.) could prove very costly. It is extremely likely that cloud providers could start using their highly differentiated service offerings on their platform to price gouge consumers who bought those tools, with the expectation that these providers would act in good faith​.

InfraRapid produces templates in Terraform, so you don’t get locked into the Gruntwork ecosystem like modules.tf (discussed earlier). There are clear limitations to InfraRapid in its current state. First, the templates it produces are not robust or production-ready. Second, the architecture hasn’t been totally optimized yet, so best practices in the code generated today may not be ideal. That being said, the tool is free to use, and perhaps most importantly, produces the templates in pure HCL, leading to the least technical debt as long, as you plan to continue using Terraform, which I highly recommend you do. Because of the nascent state of the project and lack of security in our potential profitability over time, there is a chance the library deprecates at some point (although currently, it is under rapid development). With all that in mind, I currently have high confidence in our execution and suspect the library will grow quickly for the foreseeable future, and with any luck with even greater velocity than currently. Furthermore, even if we fail, the code will still be generated in original Terraform and even if we disappear, I can say with almost 100% certainty Hashicorp won’t anytime soon.

If you made it to the end of this article, firstly, congratulations. This thing is a tome. Secondly, I’d really enjoy your feedback. If you’d like to share your thoughts with me, please join our Slack and I’ll make sure to respond to you.

Thanks so much for reading and I hope you enjoyed!