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

El mercado laboral global avanza rápido y siempre hay demanda de nuevos productos. Tuvimos que encontrar la manera de mantener el beneficio en toda la industria.

Somos una empresa de tecnología con una estrategia audaz

En 2022, creamos un ADR (Architectural Decision Record) que decía: "serverless-first y containers-as-need." Y generó debate entre casi 40 equipos de ingeniería.

Vamos a explicar primero un poco de terminología

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

  • Reducir la sobrecarga operativa al no gestionar la infraestructura

  • Escala según sea necesario, incluyendo el escalado a cero para que sean completamente elásticos

  • Ten precios elásticos (solo pagas por lo que usas) 

En G-P, serverless-first se refiere a nuestro uso de AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, Interfaz de programación de aplicaciones 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 empezaran con una opción serverless. Una nota importante: si el servicio serverless no satisface la necesidad, los equipos deberían recurrir a un servicio más pesado — uno que requiera una mayor inversión operativa.

"Contenedores según necesidad" aclara que sin servidor primero no significa solo sin servidor. Hay momentos en los que necesitamos contenedores (por ejemplo, instalar un producto de software COTS) — y eso está bien.

Una estrategia tecnológica que priorice a los clientes

Nos movemos a un ritmo ágil para satisfacer las necesidades de nuestros clientes y usuarios. Servicios como Lambda, S3y DynamoBD son increíblemente resistentes y rápidos. Al descargar el trabajo pesado indiferenciado, podemos dedicar más tiempo a crear funciones para los usuarios, en lugar de trabajar en una configuración genérica de infraestructura.

Un principio clave en G-P es: "Tú lo construyes, tú lo diriges." Nuestros equipos son los dueños de su software. Así que no lanzamos software por encima del muro a un equipo de DevOps. 

Beneficios del "serverless-first"

El servidor sin servidor es inherentemente impulsado por eventos.

Nuestra arquitectura está completamente orientada a eventos. Empleando EDA (Arquitectura Orientada a Eventos), podemos escalar tanto nuestra organización como nuestro software. El sistema sin servidor nos obliga a mantener un radio de explosión pequeño y comunicarnos de forma completamente nativa en la nube a través de eventos.

Habilitación de restricciones

Como plataforma global de empleo, nos tomamos el cumplimiento normativo muy en serio. Nuestra infraestructura cloud está bien arquitectada y empleamos una estrategia multi-cuenta que separa las cargas de trabajo y automatiza el cumplimiento en la nube. El sistema sin servidor nos ayuda a imponer altos estándares controlando cómo aprovisionamos los recursos en la nube.

Descarga el trabajo

Nuestro proveedor de nube gestiona nuestros servicios serverless. Un único conjunto de bloques básicos —integrados, seguros, ajustados, habilitados y mantenidos por AWS— nos permite centrarnos en una posición más alta en la cadena de valor para los clientes.

Cargas de trabajo bien arquitectadas

Cada carga de trabajo que creamos se revisa con el AWS Well-Architected Framework. Nos centramos en la escala, la seguridad, la fiabilidad y la optimización de costos para cerciorarnos de que no solo cumplimos, sino que también superamos nuestro SLA (Acuerdo de Nivel de Servicio). Esto empodera a nuestros equipos de ingeniería mientras seguimos evolucionando con entornos en la nube. 

Sobre nuestros equipos

Nuestra estrategia tecnológica es ambiciosa, y eso la hace un reto. Muchos ingenieros no trabajaron en una arquitectura serverless (o distribuida). La transición a la arquitectura serverless no es fácil, y buscamos ingenieros que se sientan cómodos aprendiendo, pensando en grande y avanzando a buen ritmo.

Algunos ingenieros no están seguros del término serverless (sí, sabemos que existen servidores) porque el enfoque va más allá de escribir código en funciones. Nuestra estrategia requiere un enfoque holístico de los principios tradicionales de cloud-native.

El resultado

Logramos un progreso extraordinario en dos años. La modernización tiene muchos beneficios (ver nuestro artículo sobre AWS / valor empresarial conocido de la modernización en la nube). Específicamente, observamos lo siguiente:

1. Velocidad: La forma en que dividimos nuestro sistema permite que equipos y productos innoven y evolucionen de forma independiente. Esto tiene un impacto enorme en la agilidad empresarial.

2. Cumplimiento: Empleamos el AWS Well-Architected Framework para revisar todas las cargas de trabajo. Como empleamos muchos Servicios Gestionados de AWS, podemos confiar en su excelencia operativa y partir de un lugar de alta calidad.

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

4. Innovación: Serverless significa que todo es una API. Esta restricción forzada requiere un enfoque de Interfaz de programación de aplicaciones-first. Cuando nos consideramos una plataforma, podemos alcanzar un nuevo nivel de innovación conectando fácilmente sistemas a través de APIs, como integrar G-P Gia™ en una nueva base de conocimiento.

5. Propiedad: AWS es dueño de nuestra infraestructura, pero nosotros somos dueños de nuestro dominio empresarial. El diseño sin servidor primero con dominio nos obligó a centrarnos en el problema empresarial. Esto mantiene clara la propiedad de la capacidad.

El modo serverless-first no siempre es más rápido, pero es más beneficioso. Preferimos optimizar para la velocidad del sistema que para la velocidad individual del revelador. El serverless-first es menos sobre usar funciones y más sobre pensar: "El código es una carga. El sistema es el activo." Cuanto menos código tengamos que escribir, más podremos considerar y moldear el sistema empresarial que estamos construyendo.

A medida que compartamos nuestra historia, se hará evidente la velocidad a la que trabajamos, que es un resultado directo del serverless-first. Estad atentos.