Cuando las relaciones con el servicio técnico no funcionan

Tutoriales
AWS

Piensa en aquellos días en los que conociste al amor de tu vida. El sentimiento era mutuo. El mundo parecía un lugar mejor, y estabas en un emocionante viaje con tu pareja. Ambos estaban “totalmente comprometidos” mientras hacían planes para una vida juntos.

La vida era asombrosa… hasta que dejó de serlo.

Cuando las cosas no salen como se planeó, entonces tienes que hacer el trabajo duro de deshacer la relación. Comunicarte entre ustedes y con los demás. Ordenar las compras compartidas. Seguir adelante. Bleh.

Créelo o no, nuestra relación con la tecnología no es tan diferente.

Rompiendo con un Servicio

Hubo un tiempo en el que decidiste adoptar un servicio — tal vez era un SaaS, o un PaaS, o algo más genérico. En aquel entonces, ¿tomaste la decisión considerando también el momento en que ya no planeabas usar el servicio? Probablemente no. Solo pensabas en todas las maravillosas posibilidades para el futuro.

Pero, ¿qué pasa cuando optar por ese servicio ya no es lo mejor para ti? Ahora te enfrentas a un desafío, y se llama abdicación del servicio. Si bien los servicios pueden cerrarse con un esfuerzo razonable, obtener los datos subyacentes puede ser problemático. Esto a menudo depende del tipo de servicio y del volumen de datos que posee ese proveedor de servicios.

A veces, el deshacer ideal se ve así: Deja de pagar por el servicio, pero conserva el acceso a la fuente de datos durante algún tiempo. ¿Es esto siquiera una posibilidad? ¡Sí, lo es!

El Poder del Peering VPC

Los principales proveedores de nube han adoptado la nube privada virtual (VPC) como el enfoque de facto para establecer conectividad entre recursos. Por ejemplo, una instancia EC2 en AWS puede acceder a una fuente de datos utilizando VPC y servicios de punto final de VPC. Piénsalo como una conexión punto a punto.

Las VPC nos permiten otorgar acceso a otros recursos en el mismo proveedor de nube, pero también podemos usarlas para otorgar acceso a servicios externos. Considera un servicio que fue recientemente abandonado pero con la fuente de datos original aún en su lugar. Así es como podría verse:

Este concepto se llama emparejamiento de VPC, y permite establecer una conexión privada desde otra red.

Un Ejemplo de Migración de Servicio

Consideremos un ejemplo más concreto. En tu organización, se tomó la decisión empresarial de optimizar su funcionamiento en la nube. Mientras continuaba aprovechando algunos servicios de AWS, tu organización quería optimizar cómo construye, despliega y gestiona sus aplicaciones al dar de baja un servicio basado en la nube de terceros que se ejecutaba en AWS. Hicieron los números y concluyeron que los ingenieros de software internos podrían crear y mantener un nuevo servicio autoescalable en Heroku por una fracción del costo que estaban pagando al proveedor de terceros.

Sin embargo, debido a una larga permanencia con el proveedor de servicios, migrar la fuente de datos no es una opción en el corto plazo. No quieres el servicio, y no puedes mover los datos, pero aún quieres acceso a los datos. Afortunadamente, el proveedor ha aceptado un nuevo contrato para continuar alojando los datos y proporcionar acceso — a través de VPC peering.

Aquí está cómo se vería el nuevo acuerdo:

VPC Peering con Heroku

Para que tu nuevo servicio (una aplicación de Heroku) acceda a la fuente de datos original en AWS, primero necesitarás ejecutar tu aplicación dentro de un Espacio Privado. Para más información, puedes leer sobre la adopción segura de la nube y mi descubrimiento de los Espacios Privados de Heroku.

Luego, necesitarás cumplir con los siguientes requisitos de red simples:

  • La VPC debe usar un bloque CIDR IPv4 compatible en su configuración de red.
  • La VPC debe usar un bloque CIDR RFC1918 (10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16).
  • El bloque CIDR de la VPC no debe superponerse con los rangos CIDR de tu Espacio Privado. Los rangos predeterminados son 10.0.0.0/16, 10.1.0.0/16, y 172.17.0.0/16. 

Con tu Espacio Privado en funcionamiento, necesitarás recuperar su información de emparejamiento:

Shell

 

Copia el ID de cuenta de AWS (647xxxxxx317) y el ID de VPC de AWS (vpc-e285ab73). Deberás proporcionar esa información al proveedor de terceros que controla la fuente de datos de AWS. A partir de ahí, pueden utilizar tanto la Consola de AWS como la CLI para crear una conexión de emparejamiento. Su operación se vería algo así:

Shell

 

Esto crea una solicitud de emparejamiento. Una vez que el proveedor haya realizado esto, puedes ver la solicitud pendiente en el lado de Heroku:

Shell

 

En la captura de pantalla a continuación, podemos ver el estado de pendiente de aceptación para la conexión de emparejamiento.

Desde aquí, puedes aceptar la solicitud de conexión de emparejamiento:

Shell

 

Comprobamos el estado de la solicitud por segunda vez:

Shell

 

Vemos que la conexión entre pares está activa.

En este punto, la aplicación que se ejecuta en nuestro Espacio Privado de Heroku podrá acceder a la fuente de datos de AWS sin ningún problema.

Conclusión

Una verdad desafortunada en la vida es que las relaciones pueden ser tan infructuosas con la misma frecuencia que duraderas. Esto se aplica a las personas y también a la tecnología.

Cuando se trata de decisiones tecnológicas, a veces las situaciones cambiantes y las necesidades nos llevan a movernos en diferentes direcciones. A veces, las cosas simplemente no funcionan. Y en estas situaciones, el mayor desafío suele ser deshacer una implementación existente, sin perder acceso a datos persistentes.

Afortunadamente, Heroku proporciona una solución para migrar lentamente desde soluciones basadas en la nube existentes mientras se mantiene el acceso a datos alojados externamente. Su fácil integración para peerings de VPC con AWS te permite acceder a recursos que aún necesitan permanecer en la implementación heredada, incluso si el resto de ustedes ya ha avanzado.

Tomar este enfoque permitirá que tu nuevo servicio prospere sin interrupciones en el servicio al consumidor.

Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out