Quais destes principais erros de nuvem de inicialização você está cometendo?

A nuvem simplifica o início, mas também facilita o fracasso. Aqui estão algumas dicas sobre erros a serem evitados.

Há cada vez menos motivos para as empresas criarem e implantarem aplicativos em data centers privados hoje em dia, e talvez não haja bons motivos para as startups fazerem isso. Ainda assim, para startups que desejam construir na AWS, Microsoft Azure ou Google Cloud, escolher um provedor de nuvem é o começo da jornada, não o fim. Ao longo do caminho, há muito que pode dar errado cometendo erros simples.

VEJO: Kit de contratação: desenvolvedor Android (TechRepublic )

A equipe editorial da AWS compilou recentemente uma lista de “Dez erros que os fundadores cometem na AWS e como evitá-los”. A lista da AWS inclui coisas como a necessidade de estabelecer orçamentos e boa higiene de segurança, como autenticação multifator. No geral, é uma ótima lista e representa uma tentativa sincera de ajudar a garantir que as startups tenham uma boa experiência na AWS, provavelmente na esperança de que essas mesmas startups escolham continuar crescendo na AWS. Mas não é necessariamente uma lista completa, como revelou o tópico do Twitter do ex-funcionário da AWS Randall Hunt.

Quais são algumas das outras áreas em que startups e outras podem dar errado na AWS?

Dinheiro e segurança

Prevalente na lista criada pela AWS, e abundante entre os entrevistados do tweet de Hunt, é a ideia da necessidade de controlar custos. Uma das grandes coisas sobre a nuvem, em geral, é como é fácil ativar recursos… e mantê-los girando, querendo ou não esse resultado. Em um ex-empregador, estimamos que tínhamos quantidades gigantescas de instâncias da AWS em segundo plano, em grande parte esquecidas pelas equipes e desenvolvedores que as configuraram originalmente. Alguém pode ficar tentado a pensar que a AWS adora isso, porque eles estão sendo pagos independentemente do valor para os clientes, certo?

Não tão. Quando trabalhei na AWS, fomos treinados para otimizar o valor do cliente, não o dinheiro do cliente. Não é de irar, portanto, que Shivansh Chaudhary, da AWS, tenha apontado para a necessidade de as startups “configurarem alertas e alarmes de faturamento” para garantir que não acordem com uma surpresa desagradável de faturamento. É por isso que Corey Quinn pode ter uma renda saudável aconselhando empresas sobre como gerenciar suas contas da AWS e por que ele pode sugerir de maneira sarcástica, mas com precisão, que sua conta da AWS pode ter mais a ver com quantos engenheiros você tem, em vez de quantos clientes você tem .

Falando em alertas, há também o problema de supor que, como a AWS leva a segurança a sério, alguns assumem que, “usando a AWS, eles protegeram automaticamente todas as coisas”, como opinou o fundador do SecureStack, Paul McCarty. Novamente, a nuvem facilita o início, e a AWS fornece ferramentas para tornar o início seguro relativamente simples. Mas você precisa usar essas ferramentas/práticas recomendadas para obter segurança. Isso não acontece por padrão.

VEJO: AWS Lambda vê seu primeiro ataque de malware com Denonia, e não sabemos como chegou lá (TechRepublic)

Crescendo muito rápido

E depois há os problemas associados a assumir que sua startup de cinco pessoas precisa funcionar como uma empresa de 50.000 pessoas. Por exemplo, na sugestão da AWS de que “Não usar infraestrutura como código (IaC)” é um erro para startups, isso depende. Como a AWS sugeriu em um artigo complementar, “Se seu objetivo é construir uma empresa moderna usando as melhores práticas de desenvolvimento atuais… difícil” tarefa de “Provisionar e atualizar a infraestrutura em todos esses ambientes manualmente”. Eles não estão errados.

Mas o desenvolvedor da Qargo, Brecht Verhoeve, fez um contraponto convincente, argumentando que “em uma startup em estágio inicial, sua infraestrutura está mudando muito ou nada”. Como tal, ele continuou: “Nesses casos, configurar coisas com o [AWS] console requer muito menos esforço, o que economiza tempo para desenvolver seu produto.” Uma vez que uma empresa vai além da fase de inicialização e você “tem que replicar sua infra com frequência (por exemplo, para fins de devops), então o investimento em IaC faz sentido”, concluiu. É fácil supor que você precisa começar com IaC (ou outras práticas de desenvolvimento novas e interessantes), mas sua milhagem pode variar de acordo com essas suposições.

Falando em serviços, uma startup pode querer, mas não precisar, Glenn Gillen, da Hashicorp, destacou o Kubernetes favorito de todos, se nem sempre necessário: “Gastar 6 meses queimando seus créditos enquanto refinam um cluster k8s que a zero clientes”. Ou, como Rob Love continuou, é um erro “Iniciar[ with] Kubernetes muito cedo!” O Kubernetes pode estar na moda, mas pode não atender aos requisitos reais de muitas startups. Pode ser um caso de “construção excessiva e uso de tecnologia ‘pesada’ muito rápido”, observou Dillon Peterson.

Quando é “muito cedo” muito cedo para coisas como Kubernetes? De acordo com Hunt, “o Kubernetes é ótimo quando a maturidade da carga de trabalho é bem compreendida e você pode obter uma sólida economia de custos + utilização + conveniência”. OK, então o que as startups deveriam fazer? Sem servidor, ele continuou: “Para novas cargas de trabalho líquidas, escolho opções sem servidor 99% do tempo (exceto IO_WAIT longo) e deixo a telemetria me dizer quando [go Kubernetes].”

Existem outras pegadinhas, mas vou deixar para você descobri-las lendo o excelente tópico de Hunt no Twitter. A maioria dos erros de inicialização são relativamente fáceis de evitar se – e enfatizo “se” – a inicialização é intencional sobre como usa a AWS (ou outra nuvem). A conveniência é o aplicativo matador na nuvem e pode se tornar… matador.

.