Which of these top cloud startup mistakes are you making?

Which of these top cloud startup mistakes are you making?

The cloud makes it easy to get started, but it also makes it easy to fail. Here are some tips on the mistakes to avoid.

Image: Shutterstock/Gonzalo Aragon

There’s less and less reason for companies to build and deploy applications in private data centers these days, and perhaps no good reason for startups to do so. Still, for startups looking to build on AWS, Microsoft Azure, or Google Cloud, choosing a cloud provider is the beginning of the journey, not the end. Along the way, there are many things that can go wrong by making simple mistakes.

WATCH: Recruitment Kit: Android Developer (TechRepublic Premium)

The AWS editorial team recently compiled a list of “10 Mistakes Founders Make on AWS and How to Avoid Them.” AWS’s list includes things like the need to set budgets and good security hygiene like multi-factor authentication. Overall, it’s a great list and represents a sincere attempt to help ensure that startups have a good experience on AWS, likely in the hope that those same startups will choose to continue to grow on AWS. But it’s not necessarily a complete list, as a former AWS employee Randall Hunt’s Twitter thread revealed.

What are some of the other areas where startups and others can fail on AWS?

money and safety

Predominant in the list created by AWS, and widespread among the respondents to Hunt’s tweet, is the idea of ​​the need to control costs. One of the best things about the cloud, in general, is how easy it is to spin up resources…and keep them spinning, whether he wanted that result or not. At a former employer, we estimated that we had gigantic numbers of AWS instances running in the background, largely forgotten by the teams and developers who originally set them up. One might be tempted to think that AWS loves this, because they get paid regardless of value to customers, right?

not so When I worked at AWS, we were trained to optimize for customer value, not customer dollars. It’s no wonder, then, that AWS’s Shivansh Chaudhary pointed to the need for startups to “Set up billing alerts and alarms” to make sure they don’t wake up to a nasty billing surprise. That’s why Corey Quinn can make a good living advising businesses on how to manage their AWS bills, and why he can sarcastically but accurately suggest that his Your AWS bill may have more to do with how many engineers you haveinstead of how many clients you have.

Speaking of alerts, there’s also the problem of assuming that because AWS is serious about security, some assume that “for using AWS have automatically secured all things”, as opined the founder of SecureStack, Paul McCarty. Again, the cloud makes it easy to get started, and AWS provides tools to make it relatively easy to get started securely. But you should use those tools/best practices to achieve security. It doesn’t happen by default.

WATCH: AWS Lambda sees its first malware attack with Denonia, and we don’t know how it got there (Republic of Technology)

grow up too fast

And then there are the problems associated with assuming your five-person startup needs to function like a 50,000-person company. For example, on AWS’s suggestion that “Not using infrastructure as code (IaC)” is wrong for startups, that depends. As AWS suggested in a complementary piece“If your goal is to build a modern enterprise using current development best practices… you’ll have developer environments, unit tests, integration tests, pre-production tests, and production itself,” with the “extremely difficult” task of ” Provisioning and updating the infrastructure in all these environments manually.” They’re not wrong.

But Qargo developer Brecht Verhoeve made a compelling counterpoint, arguing that “At an early stage of startup, your infrastructure is changing a lot or not at all.” As such, he continued, “In those cases, setting things up with the [AWS] console requires much less effort, saving you time to develop your product.” Once a company moves beyond the start-up phase and you “have to replicate your infrastructure frequently (for example, devops purposes), then investing in IaC makes sense,” he concluded. It’s easy to assume you need to get started with IaC (or other cool new development practices), but your mileage may vary based on such assumptions.

Speaking of services, a startup may want but not need, Glenn Gillen of Hashicorp highlighted everyone’s favorite, if not always necessary, Kubernetes: “Spending 6 months burning through their credits while refining a k8s cluster that supports zero clients.” Or, as Rob Love said, is an error “Start[ with] Kubernetes too early!” Kubernetes may be all the rage, but it may not actually meet the real requirements of many startups. It could be a case of “overbuilding and using ‘heavy’ technology too quickly,” he noted. dillon peterson.

When is “too early” too early for things like Kubernetes? According to Hunt, “Kubernetes is great when you understand workload maturity well and can get solid cost savings + utilization + convenience.” OK, so what should startups be doing instead? Serverless, he continued, “For net new workloads, I choose serverless 99% of the time (except long IO_WAIT) and let telemetry tell me when [go Kubernetes].”

There are other pitfalls, but I’ll leave you to discover them by reading Hunt’s excellent Twitter thread. Most startup errors are relatively easy to avoid if – and I stress “if” – the startup is intentional about how you use AWS (or another cloud). Convenience is the killer app in the cloud, and it can get… killer.

Disclosure: I work for MongoDB, but the opinions expressed here are my own.. I am also a former AWS employee.

Leave a Comment