Errores comunes que las startups deben evitar en AWS

Cada vez hay menos razones para que las empresas construyan y desplieguen aplicaciones en centros de datos privados en estos días, y tal vez no haya buenas razones para que las startups lo hagan. Sin embargo, para las startups que buscan construir en AWS, Microsoft Azure o Google Cloud, elegir un proveedor de la nube es el comienzo del viaje, no el final. A lo largo del camino, hay muchas cosas que pueden salir mal al cometer errores simples.

Mitos sobre el dinero y la seguridad

Uno de los grandes errores comunes, según la lista compilada por el Equipo Editorial de AWS, es la falta de control de los costos. Una de las grandes ventajas de la nube en general es lo fácil que es crear recursos... y mantenerlos en funcionamiento, ya sea que desee ese resultado o no. En un antiguo empleo, estimamos que teníamos una cantidad enorme de instancias de AWS trabajando arduamente en segundo plano, en gran parte olvidadas por los equipos y desarrolladores que las configuraron inicialmente. Uno podría tentarse a pensar que AWS ama esto, porque están siendo pagados independientemente del valor para los clientes, ¿verdad?

No es así. Cuando trabajé en AWS, nos capacitaban para optimizar el valor para el cliente, no los dólares que el cliente pagaba. No es de extrañar que Shivansh Chaudhary de AWS haya destacado la necesidad de que las startups "establezcan alertas y alarmas de facturación" para asegurarse de que no se despierten con una desagradable sorpresa en la factura. Es por eso que Corey Quinn puede ganar un buen ingreso asesorando a las empresas sobre cómo gestionar sus facturas de AWS, y por qué puede sugerir con ironía pero con precisión que su factura de AWS puede tener más que ver con la cantidad de ingenieros que tiene, en lugar de la cantidad de clientes que tiene.

Otro error común es asumir que AWS asegura automáticamente todo por usar su plataforma, como opinó el fundador de SecureStack, Paul McCarty. Si bien es cierto que la nube facilita comenzar, y AWS proporciona herramientas para comenzar de manera segura de manera relativamente simple, uno debe usar esas herramientas y mejores prácticas para lograr la seguridad. No ocurre de forma automática.

Crecer demasiado rápido

Luego están los problemas asociados con asumir que tu startup de cinco personas necesita funcionar como una empresa de 50,000 personas. Por ejemplo, según la sugerencia de AWS de que "No usar la Infraestructura como Código (IaC)" es un error para las startups, eso depende. Como AWS sugirió en un artículo complementario, "Si tu objetivo es construir una empresa moderna utilizando las mejores prácticas de desarrollo de hoy... tendrás entornos para desarrolladores, pruebas unitarias, pruebas de integración, pruebas previas a la producción y producción misma, con la tarea 'excesivamente difícil' de 'Provisionar y actualizar la infraestructura en todos estos entornos de forma manual'. No están equivocados.

Sin embargo, Brecht Verhoeve, desarrollador de Qargo, plantea un argumento convincente en contra, argumentando que "en una startup en etapa temprana, tu infraestructura cambia mucho o no cambia en absoluto". Como tal, continúa diciendo, "en esos casos, configurar cosas con la consola de AWS requiere mucho menos esfuerzo, lo que te ahorra tiempo para construir tu producto". Una vez que una empresa pasa la etapa de startup y "necesitas replicar tu infraestructura a menudo (por ejemplo, para fines de DevOps), entonces tiene sentido invertir en IaC", concluye. Es fácil asumir que necesitas comenzar con IaC (u otras prácticas de desarrollo nuevas y geniales), pero puede variar según tu situación.

Cómo funciona el protocolo FTP y cómo resolver problemas relacionados con él

En cuanto a los servicios, uno que las startups pueden querer pero no necesitar es Kubernetes, el favorito de HashiCorp, según Glenn Gillen: "Pasar 6 meses consumiendo sus créditos mientras perfeccionan un clúster de Kubernetes que no tiene ningún cliente". O, como agrega Rob Love, es un error comenzar con Kubernetes demasiado pronto. Kubernetes puede estar muy de moda, pero puede que no satisfaga realmente los requisitos de muchas startups. Podría ser un caso de "sobreconstrucción y uso de tecnología 'pesada' demasiado rápido", señaló Dillon Peterson.

¿Cuándo es "demasiado pronto" para cosas como Kubernetes? Según Hunt, "Kubernetes es genial cuando se comprende bien la madurez de la carga de trabajo y se pueden obtener ahorros sólidos en costos + utilización + comodidad". Bueno, ¿qué deberían hacer las startups en su lugar? Serverless, continúa diciendo, "para cargas de trabajo completamente nuevas, elijo opciones sin servidor el 99% del tiempo (excepto cuando se requieren largas pausas de espera para la E/S), y dejo que la telemetría me indique cuándo [migrar a] Kubernetes".

Existen otras advertencias, pero lo dejo en tus manos para que las descubras leyendo los excelentes hilos de Twitter de Hunt. La mayoría de los errores de las startups se pueden evitar relativamente fácilmente si -y subrayo "si"- la startup es intencional en la forma en que usa AWS (u otra nube). La conveniencia es la aplicación clave en la nube, y puede volverse... mortal.

Divulgación: Trabajo para MongoDB, pero las opiniones expresadas aquí son mías. También soy un ex empleado de AWS.

Microsoft lanza servicio gratuito de almacenamiento en la nube para usuarios de Windows

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Nube, allí encontraras muchos artículos similares a Errores comunes que las startups deben evitar en AWS , tenemos lo ultimo en tecnología 2023.