AWS the startup builder!
Gran disclaimer este post va en base a mi experiencia de todas las empresas que tuve la oportunidad de trabajar de primera mano o como asesor/consultor. Son experiencias, tomarlas como tal!. Como también el foco de este post es contemplar a AWS como enabler de startups,no se va a realizar un análisis de mercado entre distintos proveedores cloud, no se va tomar en consideración otras soluciones de nicho para determinados sistemas como New Relic, Datadog, Github, Gitlab , etc.
Primer gran concepto, no hay un único modelo que esté bien o esté mal, a lo largo de los años vi cosas muy copadas hechas en ambientes on-premise, en la nube o en un mundo híbrido. Como también aplicados como monolitos, microservicios ya sean en Instancias, Docker o Kubernetes.
Hay cientos de definiciones de Startup, voy a tomar una de ellas que en mi opinion hace fit con los tópicos que vamos a estar tratando en este documento, Startup es una empresa de nueva creación que busca comercializar productos y/o servicios a través del uso intensivo de las tecnologías, con un modelo de negocio escalable el cual le permite un crecimiento rápido y sostenido en el tiempo. Buscan operar con costos mínimos hasta que hayan validado su modelo de negocios.
Una de las primeras grandes decisiones que vamos a tomar, vamos a ir por un modelo On Premise, Cloud o Híbrido? La respuesta a este punto para una startup normalmente es muy sencillo y es que vamos a ir al mundo Cloud sin lugar a duda ya que como mencionamos antes estamos en la carrera de validar nuestro modelo de negocio y el mundo cloud es perfecto para eso pagamos por lo que usamos, con un montón de features que nos permiten una altísima velocidad, sin tener los grandes riesgos que representa el mundo Onpremise. Distinto es el escenario si existe alguna restricción legal o de latencia, perse ahí tendremos que tomar con más detenimiento el modelo a elegir.
”You don’t generate your own electricity. Why generate your own computing?” Jeff Bezos, CEO, Amazon, 2008
Escenarios que nos pasarían si elegimos ir por el modelo Cloud:
- Si la startup triunfa menos de lo esperado, vamos a ver una Reducción de carga:
Se liberan recursos no utilizados y únicamente se paga por el consumo realizado.
- Si la startup triunfa más de lo esperado, vamos a ver un Aumento de carga:
Se solicitan más recursos del proveedor Cloud de forma automática para satisfacer las peticiones de los usuarios.
En cuanto en el mundo on-premises sos rehén de tu propio gasto si triunfas mucho no podes escalar a tiempo y si no triunfas tienes una gran inversión para tirar a la basura.
Ahora bien digamos que vamos por el mundo cloud es un momento muy crítico que proveedor vamos a elegir, hay grandes jugadores en el mercado, dentro de esto los tres big players son Amazon Web Services, Google Cloud Platform y Microsoft Azure. Cualquiera de los ofrecen muy buenos programas para las startups, AWS active en AWS, Google for Startups Cloud Program en GCP y Azure for startups en Azure. Estos programas entre varios beneficios que nos ofrecen son los “créditos”,en los casos que conozco van a ofrecer hasta USD 100.000 en créditos. Los créditos son básicamente dinero que tenemos para gastar en un periodo de tiempo finito en recursos del proveedor cloud que elijamos es decir dando ejemplo vamos a poder montar todas nuestras máquinas virtuales , bases de datos y elementos que necesitemos para estar operativos. Ahora veamos un poco como funciona esto generalmente otorgan un máximo de USD 100.000 en el cual se puede activar por 1 año o podemos ir solicitando de paquetes menores tipo USD 10.000 o USD 20.000 cada uno de estos con lapsos de ejecución de 2 años. Ahora esto quiere decir que voy a poder obtener mas de USD 100.000 en su totalidad NO, todas los proveedores tienen este monto topeado. Lo que nos dejan es como lo queremos ir activando y esto va ir en relación directa de la realidad de cada una de las empresas.
Es importante que es hasta y no quiere decir que siempre los ofrezcan dependera de que fondos de inversión invirtieron en su Startup, en el caso de no tener ningún fondo conocido que se te haya invertido por un familiar o amigo, se puede aplicar las fundaciones como Y combinator para solicitar créditos.
En Pomelo como en todas mis pasadas experiencias tuve el placer de trabajar del lado de AWS como el gran partner que fue un enabler de negocios, por ello lo llamó AWS the startup builder! Más allá del ENORME valor agregado que brinda AWS desde un punto de vista tecnológico es también un partner que acompaña a las startups en su crecimiento. Gran prueba de esto es el programa AWS Activate ya mencionado anteriormente que les permite a cualquier tipo de startup poder tener un punch inicial en base a créditos logrando validar el modelo de negocio sin necesidad de tener inversión inicial sin pedir nada a cambio por esto, pero no son solo creditos AWS, a través de un vasto equipo de primer nivel conformado por ex founders, ex inversores, ex Arquitectos y excelentes Ejecutivos de cuenta nos permite que AWS logre entender las necesidades a medida que cada startup necesita, proponiendo por ejemplo afianzar nuestras alianzas comerciales potenciando los negocios a nivel LATAM o Global, habilitan puentes con otros potenciales clientes, generar espacios con posibles inversionistas y hasta nos ayudan a ver desde qué ángulo podemos llevar nuestro producto as a service en el Marketplace. Link al programa Activate :https://aws.amazon.com/activate/
Cuando hablamos de infraestructura muchas veces se piensa en los ‘fierros’ los servidores donde correr las aplicaciones únicamente. ¡No hay nada más errado! Si es verdad infra se encarga de los servidores, pero es mucho más amplio son los servicios, procesos y sitios para ejecutar uno o varios proyectos. De hecho, es el paquete completo del producto junto con el poder de cómputo. Estos son servidores, procesos de desarrollo y despliegue, servicios de monitoreo de registros y una visión arquitectónica de alto nivel. Llamemos a esto la evolución de “infraestructura” a “plataforma” que engloba servidores, servicios, arquitectura, escalabilidad, gobernanza, entre otros varias metodologías como Infra as a code, Gitops, Devops y podemos seguir! Viendo a Infra con esta visión más amplia AWS provee distintos Frameworks de trabajo que permiten armar Infraestructuras que sean Escalables para desarrolladores y servicios, Seguras y Performantes. Para esto recomiendo ver los 6 pilares de AWS son documentos que para aquellos que trabajamos sobre la plataforma deberíamos tomarlo como la biblia.
https://aprendiendoaws.com/01-intro/0111-well-architected.html
Todo el mundo cree que la infraestructura buena y barata es un mito y no funciona en la vida real. Escalado automático, infraestructura como código, Kubernetes, monitoreo y registro: todo esto suena muy costoso. Pero, ¿qué pasa con una startup que no puede pagar una infraestructura costosa? Con esta respuesta podríamos escribir un artículo entero sobre el mismo! Vamos a resumirlo en tres grandes ítems! Primero lo ya mencionado AWS Activate que otorgan créditos, Segundo tanto AWS como otros proveedores ofrecen una capa gratuita de los servicios y Tercer punto los ya mencionado Pilares, en este caso el pilar de Costos. Las buenas prácticas nos van a decir desde utilizar instancias Spot para reducir hasta el 90% del costo de cómputo, Realizar Upfront de pagos, Apagado cuando no se use entre otras buenas prácticas!
https://aws.amazon.com/ec2/spot/
Una startup necesita iteraciones de retroalimentación rápida, desarrollo rápido y despliegues frecuentes. Esto que parece sencillo en una frase es uno de los desafíos más grandes a la hora de construir algo que sea Seguro, Escalable y Perfomante. Para ello necesitamos tecnologías que nos permitan crecer a esta velocidad, necesitamos poder entregar herramientas que nos permita entregar ‘Self-Service’ de Infra Hardenizada bajo nuestros estándares de forma sencilla, rápida y que sea iterable. Que la misma acompañe las propias iteraciones del producto. Para ello Kubernetes y Service Catalog fueron dos herramientas que permiten brindar esta escalabilidad iterable.
Arquitectura de EKS
https://www.nclouds.com/blog/5-reasons-aws-service-catalog-sexy-devops-cloud/
https://dev.to/ajeetraina/top-200-kubernetes-tools-for-devops-engineer-like-you-3h7e
Mencionar Kubernetes y Service Catalog no es algo que aplique para todos los modelos, es más diría que si me objetivo es lanzar un MVP rápidamente al mercado con una solución que escale, tenga buenas prácticas pero no necesariamente ponga un overkill para gestionarlo tomaría la decisión de utilizar ECS. Elastic Container Service plataforma de orquestación tiene varias similitudes con Kubernetes, algunas de ellas es el concepto de ‘promesa’ de Kubernetes llevado a tools nativas de AWS como la definición de Servicios, Task Definitions y AutoScallings Groups. Si a nivel negocio vemos que no vamos a tener más que un par de aplicaciones la decisión obvia sería ir por ECS que simplifica de sobre manera cómo desplegar aplicaciones en el cluster, la configuración del ingress del cluster, la configuración de cómo tienen que escalar las aplicaciones entre otros factores. Utilizar Kubernetes bajo mi opinión no es para todas las operaciones y cada uno de los cloud providers vamos a encontrar alguna solución que es más sencilla de gestionar en el corto plazo.
ECS proporciona una forma programática conveniente de verificar y modificar el estado de su clúster, realizar operaciones en contenedores y acceder directamente a los servicios de Amazon relacionados con su clúster, como IAM, CloudWatch y CloudTrail.
Un tip que a mi me hubiera gustado saber es cuándo va a desplegar ECS podemos ya sea desplegarlo con Servidores provisionados por nosotros o utilizar Fargate que AWS se haga cargo de todo del servidor. Esto muchas veces las startups se ven tentadas en utilizar Fargate ya que con el mismo eliminó todo el overhead de infra, si bien es totalmente correcto esto Fargate tiene dos grandes issues, primero escala extremadamente lento y el segundo es más costoso. El hecho de que escale lento puede llegar a ser un gran problema si nuestra startup es más exitosa que lo que prevemos ya que vamos a tener varios momentos de Errores debido a que el escalado de estas instancias es lento.
Entonces que elegimos ECS o EKS (Kubernetes), bueno para ello vamos a compararlos brevemente.
Dejó de lado administrar servicios manualmente como puede ser directamente con EC2, utilizando ya sea Kubernetes instalado manualmente como desplegar las aplicaciones en nodos independientes. Estos modelos pueden a veces parecer más rápidos en el corto plazo pero sería el peor error a realizar pensando en escalabilidad y resiliencia.
Además de las tools ya mencionadas AWS cuenta con todo un apartado de DevOps, en los cuales vamos a poder construir de forma sencilla todos los pipelines de CI / CD como también el repositorio de código, infra como código en Cloudformation. Es de los módulos que más fue evolucionando en los últimos años y que AWS apuesta fuerte por su crecimiento! La industria está más familiarizada con Github, Gitlab, Jenkins, CircleCI entre otros pero realmente AWS nos brinda suites muy completas sin salirse el propio servicio. En el link de dev.to se dejan algunas de las herramientas top para gestionar Kubernetes.
https://aws.amazon.com/devops/
Es de igual importancia desarrollar y poner a correr aplicaciones, como saber cual es el estado y que está pasando en las mismas. Para los que venimos del mundo de infra el monitoreo que empieza desde el día cero, desde cosas básicas como hacer un Ping para validar que esté respondiendo hasta scripts que permitan ver una línea específica en un log. AWS provee un buen motor de monitoreo que es Cloudwatch, que puede ser suficiente en muchísimos casos ! Esto es importante porque nativamente podemos todo tipo de Observabilidad sin necesidad de ir por una tool como New Relic, Datadog o Splunk.
Bien , ya tenemos nuestras aplicaciones corriendo! ¡Genial ! ahora que paso con la data? , para los que venimos de un mundo onpremise sabemos que de las cosas que generan mayores dolores de cabeza son las bases de datos y filesystem donde se guardan los datos. Continuamente hay que expandir las bases, continuamente hay que tunearlas para que sigan funcionando como es de esperarse. Creo que tanto para el mundo Startup como para el ecosistema empresarial como un todo una de las grandes fortalezas de AWS es como nos ayudan a gestionar nuestra información, desde soluciones de Filesystem con el reconocido y simple S3 ( Simple Storage Service, y es realmente simple! hasta soluciones de bases de datos SQL ( Mysql, Postgres o SQL server ) como bases de datos NO-SQL ( DynamoDB, Redis, MongoDB, Elasticsearch ). Como todos los demás servicios estos no son la excepción AWS nos da los servicios pero nos saca los ‘Big Pain’ de los mismos. Ejemplo de esto generar una base de datos SQL con múltiples réplicas e incluso que la misma corra múltiples zonas de disponibilidades es un estándar cosa que si queremos realizar esto on-premise es una locura de trabajo!
Otro gran ejemplo de esto en la comunidad es el producto diseñado por el propio Werner Vogels (CTO AWS) DynamoDB base de datos que escala sola, que no hay que hacerle ningún tipo de mantenimiento y solo hay que tener ojo en que no nos cueste muy caro!
¿Y la Seguridad ? Por ser una startup no debemos descuidar la seguridad, forma parte de uno de los 5 pilares mencionados anteriormente y AWS le da muchísima importancia a esto.
Para ello en los últimos tiempos han surgido varias soluciones que nos permiten implementar ‘as Business as Usual’. Alguna de las tools que provee por ejemplo para tratar IAM, para la generación de policies IAM en AWS de modo automático.
IAMlive: Herramienta opensource que genera policies a medida que ejecutan comandos en el Cli https://github.com/iann0036/iamlive
AWS IAM Access Analyzer (servicio gratuito) puede generar policies automáticamente a partir del uso analizando el CloudTrail.
Y si quieren saber qué hace un permiso, o si están buscando agregar un permiso buscando por la descripción, pueden hacerlo usando esta herramienta: https://www.awsiam.info/
Pueden usar estas herramientas para reducir los permisos otorgados a lo mínimo necesario.
Más allá de todas las tools que nos podremos encontrar, es muy importante seguir el Framework ya que tools hacer seguridad se trata de buenas prácticas. Para validar si estamos utilizando buenas prácticas AWS tiene un servicio que es de mucha ayuda que es Trusted Advisor, esta herramienta nos está constantemente escaneando el contenido de la cuenta buscando irregularidades frente a las buenas prácticas.
https://aws.amazon.com/es/premiumsupport/technology/trusted-advisor/
Buenas prácticas que nos enmarca como vamos a diseñar nuestra plataforma, recordemos ya no lo llamamos nuestra infraestructura, para ello los pilares nos dan buen material. Desde tener que tener segregación de funciones por cuentas de AWS un modelo simple de realizar es separar por ambiente, ambiente de desarrollo, testing o preproducción y producción. Según la industria y necesidades del negocio este esquema puede variar. Cuando uno plantea un esquema multi cuenta en AWS empiezan a surgir muchas preguntas nuevas, como voy a manejar los cambios, como mantengo la idempotencia entre cuentas, cómo mantengo los usuarios en sync con la nómina de la empresa. De esto tenemos varios modelos distintos que podemos aplicar y creo que es de vital importancia hacerlo bien desde el inicio! El modelo de IAM y de gestión de multicuenta es clave armarlo bien de forma que funcione bien para 10 desarrolladores como para 1000 desarrolladores. En el pilar referido a seguridad nos muestra que el mejor camino es no utilizar usuarios y gestionar todo a través de roles vinculando un SSO.
También cuando se habla de buenas prácticas son buenas prácticas de diseño como nuestra arquitectura es de microservicios ? ¿Cómo hacemos para comunicarnos entre ellos ? Estamos aplicando prácticas de desacople de los mismos? Para esto AWS nos brinda herramientas como SQS ( Simple Queue Service ), Kafka administrado, MQ administrado que aplicarlo en todos los flujos posibles nos va a permitir escalar y soportar grandes picos de carga.
El equipo tiene los skills necesarios para trabajar sobre AWS ? En este sentido AWS provee varios cursos gratuitos además de toda la documentación que es totalmente pública! Se pueden encontrar los cursos en https://explore.skillbuilder.aws/learn.
Recomiendo también A Cloud Guru plataforma muy copada con muchos escenarios HandOns para aquellos que nos gusta aprender by doing, liberan cursos gratis todos los meses. Si bien no es directamente AWS pero tiene cursos muy copados sobre AWS con profesionales de primera línea!
Dados los mini consejos y razones de porque AWS es una startup builder, ¡nos faltó hablar del negocio! Por esto lo primero que tenemos que hacer es respondernos ¿ que necesita el negocio Hoy, Mañana en 1 año y 5 años ? Esta respuesta frecuentemente es muy difícil de responder más del Hoy y el Mañana, pero tenemos que poder tener la visión de poder responder ya que las decisiones que hoy tomamos nos van a perjudicar dentro de 1 año. Veámoslo con más ejemplos nos referimos con la necesidad del negocio:
- ¿En qué negocio está nuestra startup? ¿Está el sector de ecommerce? fintech? logística? Cada uno de estos sectores tienen particularidades únicas del sector que tenemos que atender desde la infraestructura. Una de las primeras cosas que tenemos que entender muy bien, y varias veces se me debatió esto. Tenemos que entender como la palma de la mano el negocio en el que nos estamos involucrando. Muchos dirán ¿por qué?, la principal razón de esto se debe al simple hecho que cada negocio viene atado cientos o miles requerimientos, desde requerimientos del producto como puede ser una empresa de pagos online donde toda la transacción tiene que ocurrir en tiempo real y en flujo vivo, como algo un negocio basado en datos sensibles puede que tenga que tener distintas regulaciones de cumplimiento.
- Cual es la estrategia y relevancia que se le da a la infra en la startup? Tenemos que nivel de importancia la startup le quiere dar al equipo de infra, si es incluso que ve un equipo como tal día uno.
- La startup tiene en vista procesar en varios países? Si así fuera en qué países tiene pensado procesar ? Existen regulaciones que tenemos que tener en cuenta ? Vamos a armar una solución multi-tenant o una sola big platform para todos? En base a que podemos tomar esta decisión?.
- Que tan grande es el equipo de la empresa a corto plazo ( meses ) y a largo plazo ( los próximos 3 años ), de acá directamente hay que entender la relación de desarrolladores, producto, seguridad y personal no-it. Esto es importante para la estrategia de escalamiento que vayamos a utilizar, e_l modelo de infraestructura puede ser un habilitador de crecimiento exponencial o el peor enemigo_.
- El equipo que tenemos hoy en dia tiene algun skills preponderante, cuando uno está en una startup está en una carrera de validación de modelo de negocio vs buenas prácticas, muchas se toman atajos ‘atadas con alambre’ con solamente la idea de salir en funcionamiento lo más rápido posible que raramente es la mejor forma de salir en funcionamiento. En esto juega muchísimo el skills de los primeros integrantes de la empresa ya que estos van a marcar la forma de trabajar que ellos conocen para ir lo más rápido posible.
Todas estas preguntas que nos debemos hacer combinada con las buenas prácticas que provee AWS mas toda la comunidad de apoyo debería ayudar para que nuestra tecnología sea un enabler para que sea exitosa nuestra startup!
Dejo un video que AWS nos muestra una mini demo del panel AWS Activate!
Si te copo este artículo, alguna pregunta del mismo o crítica para mejorarlo no dudes en contactarme en cualquiera de mis redes.
Gracias a todos los que se tomaron un tiempo de leerlo y dar tips sobre el articulo!