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

This article explains:

• Why did 48% of CTOs move 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 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 with 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 learn 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 using 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: those who love to get their hands dirty in the infrastructure and those who don't want to. The latter is predominant, and even in the first case, 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 constantly learning on the job. Months can go by until the CTO decides to do so:

• Contracting an external DevOps company

OR

• 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 worldwide. 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 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 the "git" branch are a perfect start. GitOps methodologies would allow developers to maximize their productivity and never slow down their colleagues on deploying new features.

Extensible

Heroku's move to AWS is not insignificant. A growing startup needs technical extensibility. Deploying applications automatically is suitable, 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 and 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.

We're recruiting!

French translation