De la Extinción de Incendios a la Preparación para el Futuro: El Recorrido de Atlassian con una Estrategia Multicuenta

Publicado el 28 de octubre de 2024

Escrito por Artem Koshelev, Principal Engineer.

Revisa el texto original aquí.

La escalabilidad es un desafío gratificante. Generalmente, significa que su producto ha tenido éxito y que hay más demanda de la que su infraestructura puede manejar.

Sin embargo, el escalamiento también es un reto complejo. Por lo general, implica que un diseño previamente eficiente ya no cumple su función, y que se requieren ajustes o rediseños significativos en partes clave de su sistema.

La ampliación es un problema dependiente del tiempo. Si se aborda demasiado pronto, puede resultar en esfuerzos mal dirigidos. Si se deja para más tarde, puede encontrarse atrapado en un ciclo interminable de soluciones temporales, que, en el mejor de los casos, no son óptimas.

Recientemente, completamos el proyecto “Account Sharding”, que consistió en rediseñar nuestra plataforma de nube interna para resolver los problemas de escalabilidad. Nos gustaría compartir la historia de este proyecto, las decisiones que tomamos y algunos detalles de su implementación.

¿Qué es Atlassian PaaS?

Antes de profundizar en la ampliación de la plataforma como servicio (PaaS) de Atlassian, hagamos un breve repaso de su funcionamiento. La plataforma como servicio de Atlassian se llama Micros. Esta plataforma implementa y ejecuta la mayoría de nuestros servicios en la nube. Micros actúa como una capa de abstracción sobre AWS, lo que permite a nuestros desarrolladores centrarse en los productos y funcionalidades para nuestros usuarios, sin preocuparse por la infraestructura subyacente. A su vez, esta estructura permite a nuestros equipos de PaaS concentrarse en escalar la infraestructura para satisfacer las crecientes demandas de nuestros productos.

El contrato de Micros es sencillo: usted proporciona una imagen de Docker junto con una lista de los recursos necesarios, y nosotros nos encargamos de brindarle una infraestructura altamente disponible, resistente y segura, todo ello a través de un único punto de entrada DNS.

Actualmente, más de 2,000 servicios están en ejecución en nuestros entornos de producción, con alrededor de 5,500 implementaciones diarias (lo que equivale a una implementación cada 15 segundos).

Si deseas más detalles, te invitamos a leer este artículo de 2019, aún mayoritariamente preciso, titulado Por qué Atlassian utiliza un PaaS interno para regular el acceso a AWS’ en Work Life de Atlassian.

¿Por qué necesitamos fragmentación de cuentas?

Hasta hace unos años, cuando iniciamos el proyecto Account Sharding, todos nuestros flujos de trabajo de producción se ejecutaban en tres cuentas gigantes de AWS. ¿Qué queremos decir con “gigante”? Podemos definirlo desde un punto de vista operativo como el hecho de alcanzar regularmente todo tipo de límites: blandos y duros, de recursos y API. Para comprender esto mejor, profundicemos en las limitaciones de las cuentas de AWS.

En primer lugar, existen dos tipos de límites de cuenta en AWS: límites flexibles y límites estrictos. Los límites flexibles significan que se pueden aumentar mediante una solicitud a través del servicio AWS Service Quotas. Por lo general, se aplican a una cantidad de recursos que se pueden aprovisionar en una región determinada de la cuenta. Algunos ejemplos de límites flexibles son:

• Número de instancias EC2
• Número de EIP (IP elástica) o ENI (interfaz de red elástica)
• Número de clústeres memcached

Un límite estricto significa que no se puede aumentar. Algunos ejemplos de límites estrictos son:

• Número de roles de IAM en la cuenta
• Número de depósitos S3 en la cuenta
• Número de zonas alojadas en el certificado ACM

Otra dimensión es “a qué se aplica el límite”, que se puede resumir en:

1. ¿Cuántos recursos (como instancias EC2, roles IAM, clústeres Redis) pueden residir en una sola cuenta?
2. API de administración de AWS: con qué frecuencia puede llamar a una API de AWS específica antes de que se limite la velocidad

Alcanzar los límites de recursos puede ser doloroso: ralentiza la experiencia de la consola de AWS y requiere una carga de soporte constante para aumentar los límites flexibles. Sin embargo, es algo con lo que se puede vivir.

Alcanzar los límites de la API es otra historia. En primer lugar, la mayoría de estos son límites estrictos y no se pueden aumentar. En segundo lugar, muchos de ellos no se divulgan en absoluto: solo podemos observar los efectos de estar limitados por la velocidad, pero no sabemos dónde está el límite. Por ejemplo, imaginemos que AWS CloudFormation tiene un límite estricto de 5 solicitudes por segundo (el límite real se desconoce) para la API DescribeStacks. Entonces, si 6 desarrolladores inician sesión en la consola de AWS para ver las pilas de CloudFormation al mismo tiempo, 1 de ellos tendrá un límite de velocidad y deberá volver a intentarlo. ¿Qué sucede si hay 10 desarrolladores, o miles de desarrolladores, como tenemos en Atlassian?

Nuestra PaaS también utiliza las mismas API. Cada vez que se implementa un servicio, se realizan múltiples llamadas a AWS STS, KMS, CloudFormation, Route53, EC2 y otros servicios de AWS para aprovisionar o modificar recursos. Y, como he mencionado antes, se realizan más de 5000 implementaciones por día y no se distribuyen de manera uniforme. Por ejemplo, hay picos de actividad al comienzo de la jornada laboral porque los equipos tienden a tener implementaciones programadas para sus servicios.

Generamos los gráficos a continuación para comprender mejor la escala del problema de limitación de velocidad en una fase temprana del proyecto. Representan visualmente todas las llamadas API que realizamos a la API DescribeStacks de AWS CloudFormation en un intervalo de 24 horas, según los datos disponibles en los registros de AWS CloudTrail.

Representa nuestra cuenta de desarrollo:

Al principio, puede resultar difícil interpretar un gráfico con dos ejes de tiempo, pero con la práctica te acostumbrarás. Tomemos como ejemplo un único punto con coordenadas x=04:00, y=30. Este punto representa la cantidad de solicitudes realizadas a las 04:00:30 UTC. El color verde indica 1 solicitud, los tonos de naranja van de 2 a 10 solicitudes, y el color rojo señala 11 o más solicitudes. Las áreas vacías (blancas) indican que no se realizaron solicitudes en ese momento.

¿Qué podemos observar en este gráfico?

1. La carga está distribuida uniformemente a lo largo de un período de 24 horas.
2. Existe un aumento leve en la carga desde las 00:00 hasta las 07:00, que coincide con el horario comercial de Sídney, donde se encuentran algunos de nuestros equipos de ingeniería más grandes.
3. Se observan clústeres verticales regulares, lo que corresponde a llamadas API adicionales realizadas durante implementaciones y limpiezas sintéticas (más detalles sobre esto en otros entornos).

Ahora, comparemos esto con uno de nuestros entornos menos utilizados: una región en una de nuestras cuentas de prueba, específicamente en <eu-central-1>.

1. Está mayoritariamente desactivado y, en su mayoría, verde.
2. Se puede observar actividad a las 00:00 (hora de la mañana en Sídney), cuando las personas activan tuberías para realizar implementaciones y pruebas en el entorno de ensayo.
3. Se destacan grupos verticales muy visibles: los despliegues sintéticos y las limpiezas son fácilmente identificables, especialmente en momentos de menor actividad ‘natural’.

Finalmente, uno de nuestros entornos más activos, la región de producción <us-east-1>, solía lucir de esta manera:

1. Hay una línea horizontal ‘vacía’ que representa nuestra estrategia de retirada.
2. Esta es mucho más naranja que los entornos de preproducción anteriores, lo que indica que las implementaciones en producción tardaron más tiempo debido a las limitaciones de velocidad y los reintentos.

Operar dentro de una cuenta que constantemente alcanza varios límites tiene un impacto significativo tanto en nuestra plataforma como en la experiencia de los desarrolladores:

• Cuando se alcanza el límite flexible de recursos, todas las implementaciones se bloquean hasta que establezcamos un nuevo límite con AWS.
• Cuando se alcanza el límite máximo de recursos, las implementaciones se bloquean hasta que limpiemos recursos para aumentar la capacidad, aunque en la mayoría de los casos monitoreamos proactivamente el uso de recursos y evitamos esto.
• Cuando se alcanza un límite de API, no podemos hacer más que retroceder y volver a intentarlo. En situaciones críticas, los intentos de reintento se agotan, y las implementaciones comienzan a fallar.

Las implementaciones lentas o bloqueadas temporalmente pueden generar múltiples efectos negativos:

• Desperdicio operativo para los usuarios de la plataforma: los ingenieros deben dedicar tiempo a investigar las implementaciones fallidas.
• Desperdicio operativo para los desarrolladores de la plataforma: los ingenieros deben investigar y abordar la causa raíz.
• Ciclo de desarrollo más lento, mayor tiempo de entrega a producción y cronogramas de proyectos incumplidos.
• Capacidad limitada para implementar correcciones críticas o parches de seguridad.
• Lanzamientos más grandes y riesgosos: la mayoría de nuestros servicios siguen prácticas de CI/CD e implementan el código más reciente varias veces al día; los lanzamientos lentos o bloqueados significan menos lanzamientos y, por lo tanto, más grandes.

Un claro ejemplo del impacto de esto se puede observar en la implementación de Jira, nuestro producto estrella y el servicio más grande que se ejecuta en la PaaS. Jira implementa cientos de microservicios casi idénticos que brindan servicio a un subconjunto de clientes (inquilinos). La implementación de Jira desencadena cientos de implementaciones en nuestra plataforma, lo que genera una carga sustancial en las API subyacentes de AWS.

Hemos llegado al punto en el que implementar todos los fragmentos de Jira simultáneamente se volvió imposible, y nuestra plataforma se detuvo debido a los límites de velocidad constantes, los errores y los reintentos. Como resultado, nos vimos obligados a dividir las implementaciones de Jira en grupos para reducir la concurrencia, lo que llevó a implementaciones más largas y afectó negativamente el ciclo de desarrollo, además de nuestra capacidad para enviar funciones rápidamente.

Descubrimiento y decisiones

Tan pronto como comenzamos a analizar lo que se necesitaría para agregar nuevas cuentas a la plataforma, nos dimos cuenta de que el alcance del trabajo sería enorme y que debíamos tomar decisiones críticas para reducirlo y hacer que los plazos de entrega fueran realistas. Estas decisiones jugaron un papel fundamental en la entrega de este proyecto, tanto desde la perspectiva técnica como de gestión del proyecto.”

¿Cuántas cuentas nuevas queremos agregar?

Esta fue una de las primeras preguntas que tuvimos que responder y consideramos una amplia gama de opciones, desde “solo una más” hasta “miles” para admitir una cuenta por servicio. Tener una cuenta por cada servicio ofrece varias ventajas, como mayor seguridad, eficiencia operativa y mejor asignación de costos. Sin embargo, pasar a este modelo planteaba varios riesgos que debían considerarse cuidadosamente:

1. El modelo operativo es completamente diferente: Hasta ahora, solo habíamos trabajado con un número limitado de cuentas, por lo que existían varias incógnitas que debíamos resolver.
2. Es un modelo operativo completamente diferente para los usuarios de la plataforma: Es necesario desarrollar nuevas herramientas y capacitarlos para operar en un entorno nuevo.
3. Existen equipos externos integrados con nosotros: Los equipos de gestión de cuentas, seguridad o finops no tenían sus herramientas listas para integrarse con miles de cuentas.

Decidimos avanzar de manera gradual para mitigar estos riesgos:

• Comenzamos con 3 cuentas nuevas en cada tipo de entorno (tenemos dev, staging y prod disponibles para todos los desarrolladores de Atlassian, además de “platform dev” para nuestro uso interno), aumentando efectivamente la capacidad 4 veces.
• En el futuro, agregaríamos más cuentas para reducir gradualmente la cantidad de servicios asignados por cuenta.
• Desarrollaríamos capacidades para habilitar cuentas por servicio cuando fuera necesario.
• Analizaríamos nuevos datos a lo largo del camino para ajustar la decisión.

¿Debemos evacuar servicios y recursos de grandes cuentas existentes?

Para responder a esta pregunta, necesitábamos entender cómo sería la migración entre cuentas para un servicio típico. En términos generales, los recursos de un microservicio se dividen en tres tipos:

1. Cargas de trabajo computacionales: Instancias EC2, Lambdas, funciones de paso, etc., que son efímeras y se recrean constantemente durante su ciclo de vida, lo que las hace fáciles de migrar.
2. Recursos efímeros: Colas de SQS, SNS, Elasticache, Kinesis, etc., que no almacenan datos pero existen durante la vida útil del servicio, lo que requiere más esfuerzo para su migración y puede causar tiempo de inactividad o pérdida parcial de datos si se vuelven a crear.
3. Recursos persistentes: Depósitos S3, tablas DynamoDB, RDS, que requieren migración de datos y posibles cambios en el código para gestionar dos almacenes durante el período de transición o incluso tiempo de inactividad.

Involucrar a los propietarios de los servicios en las migraciones era inviable, dado que la mayoría de los servicios tiene recursos persistentes. Esto generaría un alto riesgo y requeriría un gran esfuerzo de ingeniería.

Decidimos centrarnos en los fragmentos de Jira, que son similares y se pueden migrar en masa sin grandes esfuerzos. Esto permitió que la migración fuera más eficiente y menos riesgosa, ya que los fragmentos de Jira son casi idénticos, lo que permite aplicar el mismo proceso de migración en varias ocasiones sin sobrecargar la ingeniería.

¿Deberíamos separar las cargas de trabajo computacionales de los recursos?

Otra opción tentadora fue crear cuentas dedicadas solo para los recursos de AWS, separadas de las cargas de trabajo computacionales. Esta topología tiene algunas ventajas similares a la de “cómputo por recurso”: proporciona un límite claro y simplifica las operaciones. Sin embargo, presenta ciertos inconvenientes:

• Requiere cambios por parte de los propietarios de los servicios: El acceso entre cuentas de AWS requiere configurar roles y políticas, lo que implica cambios en el código de los servicios.
• Operación en varias cuentas: Para depurar problemas durante incidentes, necesitaríamos múltiples sesiones de navegador autenticadas en diferentes cuentas, lo que podría complicar la gestión.

Al final, decidimos no adoptar esta topología de red, ya que los beneficios de las cuentas dedicadas no superaban los costos de implementación, especialmente para la mayoría de los servicios.

¿Deberíamos utilizar una nueva topología de red?

Simultáneamente con el proyecto de “Account Sharding”, se implementó otro proyecto de toda la empresa: “Network Segmentation”, cuyo objetivo era crear un límite a nivel de red entre los servicios orientados al cliente y la infraestructura interna. El equipo de red necesitaba gestionar VPC y la infraestructura de red relacionada y compartirla con todos (Uso compartido de VPC: un nuevo enfoque para múltiples cuentas y administración de VPC | Amazon Web Services). Esto era contrario a lo que habíamos hecho antes en nuestras cuentas existentes, donde aprovisionábamos y gestionábamos VPC e infraestructura de red.

Por un lado, este cambio redujo nuestro alcance, ya que no necesitaríamos gestionar la red. Por otro lado, lo aumentó, ya que tendríamos que rediseñar la plataforma para que funcionara con la nueva configuración de red.

Decidimos correr el riesgo e incorporar los cambios necesarios desde el principio, ya que tarde o temprano tendríamos que adaptarnos a la nueva red para soportar seis nuevas regiones para 
la residencia de datos . Esto permitió reducir el alcance de algunas tareas, pero también lo amplió al depender de otro proyecto de la empresa.

¿Deberíamos dar a los propietarios de servicios control sobre la asignación de cuentas?

Anteriormente, los servicios solo existían en la misma cuenta para una región de producción determinada. Esto era una característica implícita de la plataforma, y como sabemos por la Ley de Hyrum y xkcd:

“Con un número suficiente de usuarios de una API, no importa lo que prometas en el contrato: alguien dependerá de todos los comportamientos observables de tu sistema.”

Estábamos bastante seguros de que varios servicios dependían del hecho de residir en la misma cuenta. También existían grupos de microservicios que trabajaban conjuntamente como un solo producto. Por ejemplo, OpsGenie comprende casi cien microservicios desplegados en cada región. Es razonable suponer que, al considerar el lanzamiento de un nuevo servicio, los equipos preferirían que se ubicara junto con los servicios existentes. Esto iba en contra de uno de los principales objetivos del proyecto: detener el crecimiento de las cuentas existentes.

En lugar de seguir con el supuesto de que las cuentas deben ser iguales, decidimos romper con esa idea. En lugar de asignar las cuentas nosotros mismos, delegamos esta tarea a la plataforma para que realizara una asignación más aleatoria. Este enfoque garantiza que los propietarios de servicios no puedan anticipar a qué cuenta se les asignará. Para compensar este comportamiento, realizamos cambios en las herramientas de cara al usuario, de manera que los usuarios de la plataforma no tuvieran que lidiar con identificadores de cuenta específicos en sus interacciones diarias.

En algunos casos, esto requirió trabajo por parte de los propietarios de los servicios, como aplicar cambios de configuración para establecer relaciones de confianza en las nuevas cuentas o actualizar los manuales operativos. El alcance de estos ajustes fue limitado a unos pocos servicios, por lo que se consideró aceptable. Como resultado, ahora tenemos control total para evitar un mayor deterioro de las cuentas existentes y el problema de la ubicación conjunta de cuentas ya no es una preocupación para el futuro.

Diseño técnico

Una vez tomadas estas decisiones críticas, comenzamos a diseñar nuestra futura topología de cuenta.

Mirando la imagen de arriba, es fácil detectar dos diferencias:

1. Las cuentas estaban basadas en la ubicación geográfica: por ejemplo, la cuenta “Prod US” solo albergaba entornos para las regiones de AWS de EE. UU. En la nueva configuración, cada cuenta alberga todas las regiones disponibles.
2. Los entornos se asignaban 1:1 a las cuentas: el entorno de “producción este” siempre se refería a la cuenta de producción de EE. UU. En la nueva configuración, el entorno de “producción este” se asigna a una de las 4 cuentas.

Si bien la primera diferencia no es tan significativa, abordar la segunda requirió cambios importantes. ¿Recuerdas que acabamos de hablar de la Ley de Hyrum en la sección anterior?

Estábamos bastante seguros de que existían servicios dependiendo del hecho de que residían dentro de la misma cuenta.

Lo curioso es que esto también se aplica a nosotros. Los componentes de Micros se basaban en el hecho de que estaban dentro de la misma cuenta en la que implementaban otros servicios y que existía una correlación 1:1 entre un entorno y una cuenta. Pero antes de profundizar en cómo rompimos esas suposiciones, necesitamos introducir un nuevo término.

Introducción de particiones

En la sección anterior, presentamos el modelo de fragmentación de cuentas para agregar cuentas adicionales, en el que agregamos entornos a cuentas adicionales. Sin embargo, cuando se trata de implementar un servicio en un entorno, debemos enviar nuestra implementación a una cuenta de AWS específica. Nos referimos a una combinación específica de entorno de Micros y cuenta de AWS como una “partición de Micros“.

Este concepto de partición se convirtió en nuestra unidad operativa principal en Micros. Agregar nuevas cuentas significa agregar nuevas particiones, al igual que agregar nuevas regiones.

Aunque la infraestructura provista en cada partición para un entorno de Micros determinado es, en su mayoría, la misma, algunos recursos deben aprovisionarse en exactamente una partición. Las particiones que alojan dichos recursos se denominan particiones primarias. Por ejemplo:

• Cada entorno tiene una zona alojada asociada (para el entorno de Prod-East Micros), que solo puede existir en una única cuenta: *.us-east-1.prod.atl-paas.net.
• Los depósitos S3 que almacenan registros del equilibrador de carga.

Cada partición que existía antes de la fragmentación de cuentas se convirtió naturalmente en una partición primaria. El entorno prod-east en la cuenta Prod US es una partición primaria para el entorno prod-east. Todas las demás particiones prod-east se consideran particiones secundarias.

Rompiendo suposiciones sobre la plataforma

El primer supuesto con el que trabajamos fue el mapeo 1:1 entre el entorno y la cuenta. Nuestra implementación estuvo impulsada por decisiones que tomamos al principio:

1. Como no tenemos intención de mover servicios y recursos entre cuentas, la asignación de particiones debe ser persistente.
2. Como queremos controlar la asignación de cuentas y evitar suposiciones por parte del usuario, la asignación de particiones debe ser no determinista.
3. Como queremos mantener todos los recursos ubicados en una sola cuenta para un entorno determinado, necesitamos propagar la asignación de particiones a todos los componentes de la plataforma.

Para cumplir con todos estos requisitos, que parecen algo contradictorios, necesitábamos una única fuente de verdad para la asignación de particiones. Un sistema de este tipo debería realizar la asignación de particiones una sola vez de manera no determinista y luego conservar el resultado. Este sistema debe permitir recuperar la asignación más tarde para propagarla a los componentes de la plataforma.

El segundo supuesto de la plataforma se refería a los servicios de la plataforma ubicados junto con los servicios que implementan. Tener particiones adicionales significa que los servicios de la plataforma deben aprender a aprovisionar recursos en otras cuentas. Como se mencionó en From Firefighting to Future-Proofing: Atlassian’s Journey with a Multi-Account Strategy | Should we separate computing workloads from resources?, el acceso a IAM se vuelve bastante complejo para los casos de cuentas cruzadas e incluso puede llegar a ser imposible en ciertos casos. Por lo tanto, adoptamos un enfoque de “asumir el rol”. Para cada componente de la plataforma, aprovisionamos un rol de IAM en cada una de las particiones, configurado con los permisos necesarios para el aprovisionamiento de recursos específicos, y con una política de confianza que permite que los componentes de la plataforma asuman ese rol desde su cuenta “de inicio”.

Como se ilustra arriba, los componentes de Micros ahora pueden aprovisionar recursos en particiones no locales. Al aplicar el mismo enfoque a las particiones existentes, simplificamos la arquitectura al eliminar la necesidad de distinguir entre particiones “antiguas” y “nuevas”.

Además, dado que los componentes de la plataforma ahora reciben detalles de la partición a través de la carga útil de la API, nuestro diseño está preparado para el futuro. Agregar más cuentas no requerirá cambios en los componentes de Micros, ya que reciben la información de la partición mediante una API y están listos para actuar siempre que exista la función IAM adecuada en la cuenta de destino. Para agregar una nueva cuenta a nuestro sistema, solo necesitamos agregarla en un lugar: el sistema de asignación de particiones.

Aterrizando el impacto

Avanzando rápidamente 2,5 años desde la implementación en múltiples equipos y servicios, vamos a hablar del resultado final.

Estabilidad de la plataforma

Como se mencionó anteriormente, asumimos que evacuar algunos de los fragmentos de Jira sería suficiente para llevar las cuentas existentes a un estado estable. Colaboramos ampliamente con Jira para asegurarnos de que todo estuviera en orden. Este proyecto fue una situación en la que todos ganaron: ellos se beneficiaron de implementaciones más rápidas, mientras que nosotros logramos un entorno estable y confiable. Después de migrar solo 50 de los aproximadamente 200 fragmentos, pudimos reducir la duración total de la implementación de Jira en un factor de 5. Esto también eliminó la presión sobre los servicios que permanecían en las cuentas antiguas y aumentó la estabilidad general de la plataforma.

Acelerando el desarrollo de plataformas

Anteriormente en este artículo, analizamos la iniciativa de toda la empresa para ofrecer 6 nuevas regiones para la residencia de datos. Con los cambios implementados para adoptar la nueva topología de red y establecer un diseño unificado en todos los componentes de la plataforma, entregamos con éxito las 6 regiones en solo 2 meses. Este plazo coincide con el que se necesitaba anteriormente para entregar una sola región a la plataforma antes de la fragmentación de cuentas.

Preparando el escenario para el trabajo futuro

Para concluir, me gustaría destacar las principales oportunidades que nos brinda Account Sharding para el futuro. Hemos resuelto algunas limitaciones previas, como el costo prohibitivamente alto de agregar nuevas cuentas o el requisito de que los componentes de la plataforma estuvieran en la misma cuenta que los servicios de usuario. Ahora podemos volver a considerar funciones de la plataforma que antes no eran viables, tales como:

1. Cuentas a demanda: Como se indicó anteriormente, limitamos el alcance inicial a solo 3 cuentas más por tipo de entorno. Queremos avanzar gradualmente hacia un conjunto más amplio de cuentas de AWS más pequeñas, con una opción de cuenta dedicada por servicio. Si bien hemos realizado la mayoría de los cambios necesarios en los componentes de la plataforma de alto nivel, aún necesitamos una reestructuración sustancial de nuestro sistema de aprovisionamiento de infraestructura de bajo nivel para lograr este objetivo.

2. Cuentas exclusivas para recursos: Si bien la adopción de cuentas dedicadas para recursos estaba fuera del alcance del proyecto inicial, esta nueva topología nos permite desvincular aún más a los equipos de la plataforma y sus procesos, lo que permitirá ciclos de desarrollo más rápidos e innovaciones ágiles.

3. Cuentas de AWS propias: Aunque la mayoría de los servicios de nube de Atlassian se ejecutan en Micros, nuestras 20 cuentas de AWS representan solo una pequeña fracción de las más de 500 cuentas de AWS en Atlassian. Algunos equipos ejecutan servicios de AWS que no son compatibles con nuestra plataforma, otros gestionan su propio servicio que no se adapta a la arquitectura de microservicios, o prefieren tener un entorno aislado para ejecutar una solución de terceros. Sin embargo, queremos facilitarles a estos equipos la adopción de Micros. Tener la capacidad de implementar servicios en cuentas arbitrarias nos permite integrar estas cuentas en nuestra plataforma, simplificando las migraciones. El mismo enfoque puede aplicarse a las adquisiciones: en lugar de migrar todo a nuestras cuentas, podemos integrar nuevas cuentas en la plataforma para una adopción gradual.

---

Publicado el 28 de octubre de 2024

Escrito por Artem Koshelev, Principal Engineer.

Revisa el texto original aquí.

---

Somos S4E Solutions for Eveyone, Platinium Solution Partner de Atlassian en Latinoamérica visítanos y otras soluciones digitales para tu compañía. ¡Conversemos!

Nos puedes encontrar en redes sociales, ¡Síguenos para tener actualizaciones diarias! 

LinkedIn , YouTube, Facebook y Twitter.

S4E cuenta con un equipo de soporte certificado en herramientas Atlassian y AWS.