There are fewer and fewer reasons for companies to build and deploy applications in private data centers these days, and perhaps no good reasons 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’s plenty that can go wrong by making simple mistakes.
SEE: Hiring kit: Android developer (TechRepublic Premium)
The AWS Editorial Team recently compiled a list of “Ten Mistakes Founders Make on AWS, and How to Avoid Them.” AWS’ list includes things like the need to establish budgets and good security hygiene like multi-factor authentication. On balance, 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 growing on AWS. But it’s not necessarily a complete list, as former AWS employee Randall Hunt’s Twitter thread revealed.
What are some of the other areas where startups and others can go wrong on AWS?
Money and security
Prevalent on the AWS-created list, and rife among respondents to Hunt’s tweet, is the idea of the need to control costs. One of the great things about cloud, in general, is how easy it is to spin up resources … and keep them spinning, whether you wanted that outcome or not. At a former employer, we estimated that we had gargantuan quantities of AWS instances beavering away 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’re getting paid regardless of the value to customers, right?
Not so. When I worked at AWS, we were trained to optimize for customer value, not dollars from the customer. Small wonder, then, that AWS’ Shivansh Chaudhary pointed to a need for startups to “Set up alerts and billing alarms” to ensure they don’t awake to an unpleasant billing surprise. It’s why Corey Quinn can make a healthy income advising companies on how to manage their AWS bills, and why he can snidely but accurately suggest that your AWS bill may have more to do with how many engineers you have, rather than how many customers you have.
Speaking of alerts, there’s also the problem of assuming that because AWS takes security seriously, some assume that, “by using AWS they have automagically secured all the things,” as SecureStack founder Paul McCarty opined. Again, the cloud makes it easy to get started, and AWS provides tools to make getting started securely relatively simple. But you have to use those tools/best practices to achieve security. It doesn’t happen by default.
SEE: AWS Lambda sees its first malware attack with Denonia, and we don’t know how it got there (TechRepublic)
Growing up way too fast
And then there are the problems associated with assuming your five-person startup needs to run like a 50,000-person enterprise. For example, on the AWS suggestion that “Not using Infrastructure as Code (IaC)” is a mistake for startups, that depends. As AWS suggested in a companion piece, “If your goal is to build a modern company using today’s development best practices…you will have environments for developers, unit testing, integration testing, pre-production testing and production itself,” with the “exceedingly 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 “In an early stage startup, your infrastructure is either changing a lot, or not at all.” As such, he continued, “In those cases, setting up stuff with the [AWS] console requires a lot less effort, which saves you time to build on your product.” Once a company moves beyond the startup phase and you “have to replicate your infra often (e.g. devops purposes) then the investment in IaC makes sense,” he concluded. It’s easy to assume that you need to start with IaC (or other cool, new development practices), but your mileage may vary on such assumptions.
Speaking of services, a startup may want but not need, Hashicorp’s Glenn Gillen highlighted everyone’s favorite if not always necessary Kubernetes: “Spending 6mo burning their credits while they refine a k8s cluster that is supporting zero customers.” Or, as Rob Love piled on, it’s a mistake to “Start[ with] Kubernetes way too soon!” Kubernetes may be all the rage, but it may not actually serve many startups’ actual requirements. It could be a case of “Overbuilding and using ‘heavy’ tech too fast,” noted Dillon Peterson.
When is “too soon” too soon for things like Kubernetes? According to Hunt, “Kubernetes is great when the maturity of the workload is well understood and you can get solid cost savings + utilization + convenience.” OK, so what should startups be doing instead? Serverless, he continued: “For net new workloads, I pick serverless options 99% of the time (except long IO_WAIT) and let the telemetry tell me when to [go Kubernetes].”
There are other gotchas, but I’ll leave it to you to discover them by reading through Hunt’s excellent Twitter thread. Most of the startup mistakes are relatively easy to avoid if–and I stress “if”–the startup is intentional about how it uses AWS (or another cloud). Convenience is the killer app in the cloud, and it can become … killer.
Disclosure: I work for MongoDB, but the views expressed herein are mine. I am also a former AWS employee.
