Tuvimos un problema interesante hace unos años. Somos una empresa totalmente remota con todo nuestro software en la nube. Y teníamos un conjunto de aplicaciones Spring Boot que se ejecutaban en contenedores con Infraestructura como Código. Pero necesitábamos agilidad empresarial.

El mercado laboral global se mueve rápido y siempre hay demanda de nuevos productos. Tuvimos que encontrar una manera de mantener nuestro liderazgo en toda la industria.

Somos una empresa de tecnología con una estrategia audaz

En 2022, creamos un registro de decisiones de arquitectura (Architecture Decision Record, ADR) que decía: "sin servidor primero y contenedores según sea necesario". Y generó debates en casi 40 equipos de ingeniería.

Expliquemos primero algo de terminología

Serverless-first no es solo funciones como servicio. También es un grupo de servicios gestionados de proveedores de nube que: 

  • Disminuir los gastos operativos generales al no administrar la infraestructura

  • Escalar según sea necesario, incluida la escala a cero para que sean completamente elásticas

  • Tener precios elásticos (usted solo paga por lo que usa) 

En G-P, serverless-first se refiere a nuestro uso de AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB y otros.

Serverless-first significa que cuando seleccionamos una solución para computación, almacenamiento, mensajería o similar, nos gustaría que los equipos comiencen con una opción sin servidor. Una nota importante: Si el servicio sin servidor no satisface la necesidad, los equipos deben volver a un servicio más pesado, uno que requiera más inversión operativa.

“Contenedores según sea necesario” aclara que Serverless-first no significa Serverless-only. Hay ocasiones en las que necesitamos contenedores (p. ej., instalar un producto de software COTS), y eso está bien.

Una estrategia tecnológica que prioriza a los clientes

Nos movemos a un ritmo ágil para satisfacer las necesidades de nuestros clientes y usuarios. Servicios como Lambda, S3 y DynamoBD son increíblemente resilientes y rápidos. Al descargar la carga pesada indiferenciada, podemos dedicar más tiempo a crear características para los usuarios, en lugar de trabajar en la configuración de infraestructura genérica.

Un principio clave en G-P es: “Lo construyes, lo ejecutas”. Nuestros equipos son propietarios de su software. No solo lanzamos software sobre la pared a un equipo de DevOps. 

Beneficios de “sin servidor primero”

Serverless está inherentemente impulsado por eventos.

Nuestra arquitectura está completamente impulsada por eventos. Al usar EDA (Arquitectura impulsada por eventos), podemos escalar tanto nuestra organización como nuestro software. Sin servidor nos obliga a mantener un pequeño radio de voladura y comunicarnos de manera completamente nativa de la nube a través de eventos.

Restricciones de habilitación

Como empresa global employment platform , nos tomamos el cumplimiento en serio. Nuestra infraestructura en la nube está bien diseñada y utilizamos una estrategia de cuentas múltiples que separa las cargas de trabajo y automatiza el cumplimiento de la nube. Serverless nos ayuda a aplicar altos estándares al controlar cómo aprovisionamos recursos en la nube.

Descargar el trabajo

Nuestro proveedor de nube administra nuestros servicios sin servidor. Un único conjunto de bloques de construcción —integrados, seguros, ajustados, habilitados y mantenidos por AWS— nos libera para enfocarnos más en la cadena de valor para los clientes.

Cargas de trabajo bien diseñadas

Cada carga de trabajo que creamos se revisa con AWS Well-Architected Framework. Nos enfocamos en la escala, la seguridad, la confiabilidad y la optimización de costos para garantizar que no solo cumplamos, sino que también excedamos nuestro Acuerdo de nivel de servicio (Service Level Agreement, SLA). Esto empodera a nuestros equipos de ingeniería a medida que continuamos evolucionando con entornos en la nube. 

Acerca de nuestros equipos

Nuestra estrategia tecnológica es ambiciosa y eso la hace desafiante. Muchos ingenieros no han trabajado en una arquitectura sin servidor (o una arquitectura distribuida). La transición a la arquitectura sin servidor no es fácil, y buscamos ingenieros que se sientan cómodos con el aprendizaje, el pensamiento en grande y el movimiento al ritmo.

Algunos ingenieros no están seguros del término sin servidor (sí, sabemos que hay servidores) porque el enfoque es más que escribir código en funciones. Nuestra estrategia requiere un enfoque holístico de los principios clásicos nativos de la nube.

El resultado

Hemos logrado un progreso extraordinario en dos años. La modernización tiene muchos beneficios (consulte nuestro artículo sobre AWS/valor comercial conocido de la modernización de la nube). Específicamente, hemos observado lo siguiente:

1. Velocidad: la forma en que hemos dividido nuestro sistema permite a los equipos y productos innovar y evolucionar de manera independiente. Esto tiene un impacto masivo en la agilidad comercial.

2. Cumplimiento: utilizamos el marco bien diseñado de AWS para revisar todas las cargas de trabajo. Debido a que utilizamos muchos servicios gestionados por AWS, podemos confiar en su excelencia operativa y comenzar desde un lugar de alta calidad.

3. Pensamiento sistémico: tuvimos que estandarizar muchos de nuestros procesos para poder razonar sobre el sistema, la confiabilidad y el valor comercial. No dedicamos tiempo a trabajar en componentes de bajo valor.

4. Innovación: Sin servidor significa que todo es una API. Esta restricción forzada requiere un enfoque de API primero. Cuando pensamos en nosotros mismos como una plataforma, podemos alcanzar un nuevo nivel de innovación conectando fácilmente sistemas a través de API, como conectar G-P Gia™ a una nueva base de conocimientos.

5. Propiedad: AWS es propietario de nuestra infraestructura, pero nosotros somos propietarios de nuestro dominio comercial. Serverless-first con diseño basado en dominios nos ha obligado a centrarnos en el problema comercial. Esto mantiene clara la propiedad de la capacidad.

Serverless-first no siempre es más rápido, pero es más beneficioso. Preferimos optimizar la velocidad del sistema en lugar de la velocidad del desarrollador individual. Serverless-first se trata menos de usar funciones y más de pensar: “El código es una responsabilidad. El sistema es el activo”. Cuanto menos código tengamos que escribir, más podremos considerar y moldear el sistema comercial que estamos construyendo.

A medida que compartimos nuestra historia, será evidente la velocidad en la que estamos trabajando, que es un resultado directo de Serverless-first. Manténgase atento.