I interviewed 200 CTOs from growing startups - here's what came up

#productivity #aws #heroku

Between late 2019 and early 2020, I interviewed more than 200 CTOs of growing US and EU startups on the topics of the Cloud and their working methodologies. I discovered that 86% of these SMB startups use the Cloud and that 48% started their business on Heroku and then migrated to a Cloud provider — especially AWS (Amazon Web Services).

This article explains:

Why 48% of CTOs moved from Heroku to AWS.
Why migrating to AWS is a “hell” (a word I’ve often heard in my interviews).
How to simplify AWS and meet the needs of growing startups.

From Heroku to AWS

Early in the life of a startup, the CTO’s objective is to design a product quickly and then validate that the product’s value proposition is the right one with the defined target. Technical decisions are pragmatic, saving valuable time on product delivery. For application hosting, the majority choice of CTOs is Heroku — because it’s easy to get started, with virtually zero upfront cost, a price that grows with usage and maximum time spent on the product rather than managing the complexity of a server and database infrastructure.

When the startup’s market positioning is the right one, the product is successful. The questions of recruitment and team structuring naturally arise, and it is from this point on that the CTO realizes that:

Heroku is not for teamwork: a group of developers will have to share the same environments (staging, development) at the risk of getting stuck on modifications. Heroku very quickly shows its limitations in this mode of operation and prevents development teams from being productive and efficient.
Heroku is not for enterprise applications: Heroku considers the deployment and management of applications as a single unit. However, today an application is often made up of several apps — a frontend, a backend, and a database. Heroku does not allow you to manage a set of applications as a single application. This leads to difficulties in complexity management. And therefore, loss of team productivity.
Heroku is outrageously expensive: even though AWS is not known for being cheap, Heroku is up to 10x more expensive than AWS for the same use. The more you use it, the more your bills go up. Peace of mind at a price, but it’s tough to scale with Heroku.

These negative points lead 48% of CTOs to replace Heroku by AWS. But not everything is as green on the other side of the fence…

AWS hell for CTOs

Pre-sales engineers at AWS have a real strength to promote the many advantages of their Cloud solution. Arguments such as free services for up to 2 years and technical support by a dedicated account manager and a team of Cloud architects resonate exceptionally well. Their crews know the field correctly and know how to reassure. Their products are of outstanding quality, and reliability is well proven. However, most of the CTOs we interviewed have no experience of what it means to use a Cloud provider such as AWS. From a technical point of view, you have to start from scratch — everything has to be built from the ground. Meaning, configuring the network, configuring the services, creating a CI for integration, and a CD for deployment — in short, getting your hands in the engine. In our study, we found two types of CTOs, the one who loves to get their hands dirty in the infrastructure, and the one who doesn’t want to. The latter is predominant, and even in the case of the first, he lacks time to do what is necessary. The CTO then often turns to someone from his team who will have the cumbersome task of “ re-creating “ how Heroku works but often learning on-the-job. Months can go by until the CTO decides to do so:

Contracting an external DevOps company

Internalize this skill by recruiting it

From that moment on, I often heard, “Recruiting a DevOps is a real hell, I wouldn’t wish it on anyone”. Not surprisingly, this skill is scarce and expensive — ~$180k/year in San Francisco. Recruiting a DevOps can take up to 12 months, not counting the months of work needed to get a tenth of a Heroku functionality.

AWS is complex to use, as it has to meet the needs of all businesses around the world. However, it is possible to simplify AWS. Here are some areas for improvement…

Simplify AWS and meet the needs of growing startups

To meet the needs of growing startups, we should be able to combine Heroku’s simplicity with the flexibility of AWS. But where to start? Here are my thoughts:

A UX designed for developers

Heroku gets it; the developer is now the king. He’s the one who turns ideas into products. Developers should be able to use AWS without any effort. AWS must be fully integrated into their working environment (IDE) to request what they need transparently. “I need a PostgreSQL version 12 database, a 20GB disk, and to have my application available at https://foo.bar — and of course all this on my Cloud account”.

An opinionated approach

Even if there is no consensus work methodology in the R&D departments of startups, most of them try to copy their elders with a functioning (most often) in the form of a Squad. The idea would be to ensure that the product can fit team working. GitOps and environment isolation (production, staging, dev) methodologies by “git” branch are a perfect start. GitOps methodologies would allow developers to maximize their productivity and never slow down their colleagues on the deployment of new features.

Extensible

Heroku’s move to AWS is not insignificant. A growing startup needs technical extensibility. Deploying applications automatically is good, but allowing you to change everything at any time is even better. This leaves room for future DevOps to join the growing startup.

To go further

These areas of improvement apply to AWS as well as to other cloud providers such as Google Cloud Platform and Azure. At Qovery, we have begun this work of simplifying the Cloud. Our mission is to make it accessible to any developer, enabling growing startups to become the unicorns of tomorrow.