Creación de una aplicación que se lanzará en producción y no está seguro de cómo manejar los entornos de desarrollo/producción en AWS.
Si utilizo varios cubos, varias tablas de DynamoDB, varias funciones de Lambda, varias instancias de Elastic Search, EC2, puerta de enlace API, ¿parece SÚPER engorroso tener un entorno de producción y desarrollo?
Actualmente solo hay UN entorno, y una vez que la aplicación se active, cualquier cambio cambiará el entorno de producción.
Entonces, ¿cómo maneja dos entornos en AWS? La única manera que se me ocurre es hacer copias de cada función lambda, cada base de datos, cada instancia de EC2, cada API y depósito... Pero eso costaría literalmente el doble y sería muy tedioso actualizar una vez que se haya puesto en marcha.
¿Alguna sugerencia?
Hay un par de enfoques. Sin embargo, independientemente de la opción, he encontrado que es mejor mantener la mayor cantidad posible de infraestructura como código. Esto brinda la máxima flexibilidad en términos de configuración del entorno y capacidad de recuperación.
Existe el enfoque de cuenta separada
Entonces está ejecutando 2 instancias separadas de todo. Sin embargo, puede implementar algunos controles de costos, como instancias EC2 más pequeñas. O simplemente puede eliminar toda la pila de Cloudformation cuando no la esté usando y luego activarla cuando sea necesario. Hay más costos iniciales en términos de tiempo con este enfoque, pero puede ahorrar $$$ a largo plazo. Además, la separación de cuentas es excelente desde una perspectiva de seguridad.
Enfoque de una cuenta
Esto puede complicarse un poco, pero hay varias características que pueden ayudarlo a dividir una cuenta en desarrollo y producción.
Versionado de Lambda. Si está utilizando lambdas, puede obtener versiones y alias. Lo que en efecto significa que puede tener una lambda configurada con una versión de producción y desarrollo con el mismo nombre de función.
API Gate way tiene 'Etapas'. Se trata de entornos efectivos y puede etiquetar una producción y un desarrollo para dividir las separaciones de interés para una sola API.
Cubos S3. Siempre puede crear una clave en el nivel superior del directorio S3://mybucket/prod/ y s3://mybucket/dev/. Es un poco complicado, pero es mejor que tener todo en un directorio.
Sin embargo, lo que realmente debe preguntarse es cuánto cuesta realmente ejecutar una segunda cuenta frente a una cuenta para este caso de uso. y la respuesta es probablemente casi la misma.
Esa es la ventaja de AWS y de la computación en la nube en general. solo paga por lo que usas. Ejecutar una lambda en dos cuentas cuesta lo mismo que ejecutar una lambda en una sola cuenta pero invocándola exactamente la misma cantidad de veces.
El enfoque de dos cuentas también brinda mucha más claridad sobre lo que está sucediendo y ayuda a prevenir problemas en la producción en los que una pieza de código de desarrollo encuentra su camino porque está todo en una sola cuenta.
Sugiero dos cuentas de AWS. Luego, cree una plantilla de CloudFormation que aprovisione todos los recursos que necesita. Una vez que crea la plantilla, ya no es engorrosa, y tener entornos en paralelo facilita probar las actualizaciones de código antes de que se activen. No es una buena idea probar los cambios en un entorno de producción.
Sí, esto significará el doble de los costos, pero siempre puede eliminar la pila de CloudFormation en su cuenta previa a la producción cuando haya terminado la prueba para que no haya recursos inactivos. Simplemente gírelos cuando necesite probarlos, luego gírelos hacia abajo cuando haya terminado. Por lo tanto, solo está duplicando los costos durante ese pequeño período de tiempo cuando está probando. E impulsar los cambios en vivo es solo una cuestión de actualizar la pila de CloudFormation.
Estas capacidades de la nube son uno de los grandes puntos de venta para pasar a la nube en primer lugar: pueden resolver el problema que describe sin que sea engorroso, pero requiere una inversión para crear la plantilla de CloudFormation (infraestructura como código). .