Add comparison table comparing our enterprise EKS offering

[yorinasub17]

Originally from Jim:

Note that we may also want to add a comparison table somewhere; e.g., a separate "How Gruntwork EKS" compares page.

    The columns could be the most popular way to run K8S in AWS, including:
        EKS you set up yourself
        kops
        Rancher
        Gruntwork EKS
    The rows can be the various trade-offs, such as:
        Time to deploy EKS cluster
        CIS compliant out of the box
        Service mesh
        Friendly developer self-service
        Managed as code
        Etc

This could help drive home our unique differentiators more.

[josh-padnick]

I see comparison tables as a double-edged sword. Consider the subscription management space, which I'm currently knee-deep in right now while (attempting to) setup Stripe Billing.

Recurly is probably the market leader here, but you'll see no mention of competitors on their website. Less successful players like Chargify setup specific comparison pages (e.g. Chargify vs. Chargebee) but don't setup direct comparison tables. The least successful companies tend to be the ones who do direct comparison tables. Personally, whenever I see them, I assume that the company is glossing over what the other companies do really well.

I think the right way to do comparison tables is to either be very thoughtful and nuanced about it, like Terraform vs. Other, though that usually needs a docs site for that level of depth. Or you can compare our paradigm to alternative paradigms without naming the companies (or at least without making it about the companies). For example, we do this effectively at https://gruntwork.io/faq#gruntwork-vs-the-competition-at-a-glance, and I've seen lots of customers respond well to this.

So maybe here we could make the columns:

• Do it yourself
• Scaffolding tools (e.g. kops)
• K8s as a Service (e.g. Rancher)
• Gruntwork EKS

Not sure if it's worth mentioning the specific tool names, though.

[brikis98]

The least successful companies tend to be the ones who do direct comparison tables.

Hm, that strikes me as a broad generalization. For example, one of my favorite things in the HashiCorp docs is that they directly address how their various tools compare to specific other competitors. For example, see the Terraform vs Other Software page, which has Terraform vs Chef, Puppet, etc, Terraform vs CloudFormat, Heat, etc, and others as sub-pages. Consul has a similar set of pages. These aren't comparison tables, but they are direct comparisons, and I found them super useful.

Personally, whenever I see them, I assume that the company is glossing over what the other companies do really well.

Hm, I find the opposite to be true: if a technology doesn't tell me how it compares to the competition, and is afraid to flush out some of its own weaknesses, then I assume they know they are inferior, and avoid the comparison because they believe it'll make them look bad. In fact, we could even tackle it head on: the table could have rows like "provides a 24/7 managed service," and the Gruntwork option should NOT have that checked. The point is to help users make a good decision and to see the trade-offs, not solely to sell.

It's also important to point out that comparison tables are important when (a) there are plenty of competitors, (b) there's no dominant player, and (c) it's not clear what distinguishes one offering from another.

Not sure if it's worth mentioning the specific tool names, though.

I think it's worth it. Customers likely search for that sort of content anyway (e.g, Terraform vs Chef), and IMO, it's better to tackle it head on, and be more transparent with the trade-offs.

[yorinasub17]

Migrated to JIRA