{"id":52367,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pereshel-s-terraform-na-cloudformation-i-pozhalel"},"modified":"2020-02-18T14:00:04","modified_gmt":"2020-02-18T11:00:04","slug":"pereshel-s-terraform-na-cloudformation-i-pozhalel","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/pereshel-s-terraform-na-cloudformation-i-pozhalel","title":{"rendered":"Pas\u00e9 de Terraform a CloudFormation y lo lament\u00e9.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Presentar la infraestructura como c\u00f3digo en un formato de texto reproducible es una buena pr\u00e1ctica sencilla para sistemas que no requieren complicaciones. Esta pr\u00e1ctica ha sido denominada - Infrastructure as Code<\/a><\/noindex>, y hasta ahora, para llevarla a cabo, especialmente en AWS, hay dos herramientas populares: Terraform<\/a><\/noindex> y CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Pas\u00e9
\nComparando la experiencia de trabajo con Terraform y CloudFormation<\/em><\/p>\n

<\/p>\n

Antes de unirme a Twitch<\/a><\/noindex> (tambi\u00e9n conocido como Amazon Jr.<\/a><\/noindex>) trabaj\u00e9 en una startup<\/a><\/noindex> y durante unos tres a\u00f1os utilic\u00e9 Terraform. En mi nuevo puesto tambi\u00e9n utilic\u00e9 Terraform a fondo, pero luego la empresa impuls\u00f3 la transici\u00f3n a todo lo relacionado con Amazon, incluyendo CloudFormation. Me esforc\u00e9 por desarrollar las mejores pr\u00e1cticas tanto para uno como para el otro, y us\u00e9 ambas herramientas en flujos de trabajo organizacionales muy complejos. M\u00e1s tarde, tras considerar cuidadosamente las implicaciones de la transici\u00f3n de Terraform a CloudFormation, conclu\u00ed que Terraform probablemente es la mejor opci\u00f3n para la organizaci\u00f3n.<\/p>\n

<\/a><\/noindex><\/p>\n

Terraform es Horrible<\/h2>\n

<\/p>\n

Versi\u00f3n Beta del Software<\/h3>\n

<\/p>\n

Terraform ni siquiera ha lanzado la versi\u00f3n 1.0, y esta es una raz\u00f3n v\u00e1lida para no usarlo. Desde que lo prob\u00e9 por primera vez, ha cambiado mucho, pero en ese entonces terraform apply<\/code> a menudo fallaba despu\u00e9s de varias actualizaciones o simplemente tras un par de a\u00f1os de uso. Dir\u00eda que 'ahora todo es diferente', pero... as\u00ed parece que todos dicen, \u00bfno? Hay cambios que no son compatibles con versiones anteriores, aunque son adecuados, y siento que la sintaxis y las abstracciones de los recursos ahora son las correctas. La herramienta parece haber mejorado de verdad, pero... :-0<\/p>\n

<\/p>\n

Por otro lado, AWS se ha esforzado mucho por mantener la compatibilidad con versiones anteriores. Todo, probablemente, porque sus servicios a menudo se prueban a fondo internamente antes de ser publicados bajo un nuevo nombre. Por lo tanto, 'se han esforzado' es una forma suave de decirlo. Mantener la compatibilidad con versiones anteriores de la API para un sistema tan variado y complejo como AWS es incre\u00edblemente dif\u00edcil. Cualquiera que haya tenido que mantener APIs p\u00fablicas utilizadas de manera tan extensa debe entender lo complicado que es hacerlo durante tantos a\u00f1os. Sin embargo, el comportamiento de CloudFormation, hasta donde recuerdo, no ha cambiado en absoluto a lo largo de los a\u00f1os.<\/p>\n

<\/p>\n

Con\u00f3ceme, pie... este es un proyectil<\/h3>\n

<\/p>\n

Hasta donde s\u00e9, eliminar un recurso externo<\/strong> No se puede importar un stack de CloudFormation desde su propio stack CF. La situaci\u00f3n es similar con Terraform. Permite importar recursos existentes a su stack. La funci\u00f3n, se podr\u00eda decir, es asombrosa, pero con gran poder viene una gran responsabilidad. Una vez que se a\u00f1ade un recurso al stack, no se puede eliminar o modificar mientras se trabaja con ese stack. Una vez, esto tuvo consecuencias. En el sitio de Twitch, alguien, sin mala intenci\u00f3n, import\u00f3 accidentalmente un grupo de seguridad de AWS a su propio stack de Terraform. Ejecut\u00f3 algunos comandos y\u2026 el grupo de seguridad (junto con el tr\u00e1fico entrante) desapareci\u00f3.<\/p>\n

<\/p>\n

Terraform El Grande<\/h2>\n

<\/p>\n

Recuperaci\u00f3n de estados incompletos<\/h3>\n

<\/p>\n

A veces CloudFormation no puede transitar completamente de un estado a otro. En este caso, intentar\u00e1 volver al anterior. Lamentablemente, esto no siempre es factible. Volver a lo que result\u00f3 puede ser muy estresante: nunca sabes si CloudFormation estar\u00e1 contento de que lo est\u00e9n manipulando \u2014aunque sea para repararlo. No sabe exactamente si podr\u00e1 volver al estado anterior y por defecto se queda esperando un milagro durante horas.<\/p>\n

<\/p>\n

Por el contrario, Terraform tiende a recuperarse de transiciones fallidas de manera m\u00e1s elegante y ofrece una amplia gama de herramientas de depuraci\u00f3n.<\/p>\n

<\/p>\n

Cambios m\u00e1s claros en los estados del documento<\/h3>\n

<\/p>\n

'Est\u00e1 bien, equilibrador de carga, est\u00e1s cambiando. \u00bfPero c\u00f3mo?'<\/p>\n

\u2014un ingeniero preocupado, listo para pulsar el bot\u00f3n 'aceptar'.<\/p><\/blockquote>\n

A veces necesito hacer algunas manipulaciones con el balanceador de carga en el stack de CloudFormation \u2014por ejemplo, a\u00f1adir un n\u00famero de puerto o cambiar el grupo de seguridad. CloudFormation muestra los cambios de manera poco clara. Yo, como en un nerviosismo extremo, reviso el archivo yaml diez veces para asegurarme de que no he borrado nada importante ni a\u00f1adido nada innecesario.<\/p>\n

<\/p>\n

Terraform en este aspecto es mucho m\u00e1s transparente. A veces incluso es demasiado transparente (es decir: molesto). Afortunadamente, la \u00faltima versi\u00f3n incluye una mejor visualizaci\u00f3n de los cambios \u2014ahora es evidente lo que se est\u00e1 modificando.<\/p>\n

<\/p>\n

Flexibilidad<\/h3>\n

<\/p>\n

Escriba software desde el final.<\/p><\/blockquote>\n

En t\u00e9rminos claros, la caracter\u00edstica diferenciadora m\u00e1s importante de un software duradero es su capacidad para adaptarse a los cambios. Cualquier software que escribas, hazlo al rev\u00e9s. A menudo me he visto atrapado en la situaci\u00f3n de tomar un servicio 'sencillo' y luego tratar de encajarlo todo en una \u00fanica pila de CloudFormation o Terraform. Y, por supuesto, tras meses, me daba cuenta de que hab\u00eda entendido mal y el servicio en realidad no era simple. As\u00ed que necesitaba dividir de alguna manera la gran pila en partes m\u00e1s peque\u00f1as. Cuando trabajas con CloudFormation, esto solo es posible recreando primero la pila existente, algo que yo, con mis bases de datos, no hago. Terraform, en cambio, permit\u00eda diseccionar la pila y dividirla en partes m\u00e1s comprensibles.<\/p>\n

<\/p>\n

M\u00f3dulos en git<\/h3>\n

<\/p>\n

Compartir c\u00f3digo de Terraform entre numerosos stacks es mucho m\u00e1s f\u00e1cil que con el c\u00f3digo de CloudFormation. Con Terraform, puedes colocar tu c\u00f3digo en un repositorio git y acceder a \u00e9l utilizando control de versiones sem\u00e1ntico. Cualquiera que tenga acceso a ese repositorio puede reutilizar el c\u00f3digo compartido. El equivalente en CloudFormation es S3, pero no tiene las mismas ventajas y no hay raz\u00f3n para abandonar git a favor de S3.<\/p>\n

<\/p>\n

La organizaci\u00f3n creci\u00f3 y la capacidad de compartir stacks comunes alcanz\u00f3 un nivel cr\u00edtico. Con Terraform, todo esto es f\u00e1cil y natural, mientras que CloudFormation te har\u00e1 saltar a trav\u00e9s de aros antes de lograr algo parecido.<\/p>\n

<\/p>\n

Operaciones como c\u00f3digo<\/h3>\n

<\/p>\n

'Script\u00e9moslo y ya est\u00e1'.<\/p>\n

\u2014 ingeniero tres a\u00f1os antes de inventar el 'bicicleta' Terraform.<\/p><\/blockquote>\n

Cuando se trata de desarrollo de software, Go o un programa en Java no son solo c\u00f3digo.<\/p>\n

<\/p>\n

\"Pas\u00e9
\nC\u00f3digo como c\u00f3digo<\/em><\/p>\n

<\/p>\n

Tambi\u00e9n existe la infraestructura sobre la que se ejecuta.<\/p>\n

<\/p>\n

\"Pas\u00e9
\nInfrastructure as Code<\/em><\/p>\n

<\/p>\n

Pero, \u00bfde d\u00f3nde viene? \u00bfC\u00f3mo se monitorea? \u00bfD\u00f3nde reside tu c\u00f3digo? \u00bfLos desarrolladores necesitan permiso para acceder?<\/p>\n

<\/p>\n

\"Pas\u00e9
\nOperaciones como c\u00f3digo<\/em><\/p>\n

<\/p>\n

Ser desarrollador de software no es solo escribir c\u00f3digo.<\/p><\/blockquote>\n

No solo AWS: seguramente est\u00e1s utilizando servicios de otros proveedores. SignalFx, PagerDuty o Github. Quiz\u00e1s tengas un servidor Jenkins interno para CI\/CD o un panel de control interno de Grafana para monitoreo. Infra como c\u00f3digo se elige por diversas razones, y cada una es igualmente importante para todo lo relacionado con el software.<\/p>\n

<\/p>\n

Cuando trabaj\u00e9 en Twitch, aceler\u00e1bamos los servicios dentro de sistemas h\u00edbridos y sistemas de AWS. Cre\u00e1bamos y manten\u00edamos m\u00faltiples microservicios, aumentando los costos operativos. Las discusiones se llevaban a cabo m\u00e1s o menos as\u00ed:<\/p>\n

<\/p>\n