Desarrollo sin servidor en AWS

Capítulo 1. Introducción a la tecnología sin servidor en AWS

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

El secreto para salir adelante es empezar.

Mark Twain

¡Bienvenido a serverless! Estás entrando en el vibrante ecosistema de una tecnología informática moderna y apasionante que ha cambiado radicalmente nuestra forma de pensar sobre el software, ha desafiado las ideas preconcebidas sobre cómo creamos aplicaciones y ha permitido que el desarrollo en la nube sea más accesible para todos. Es una tecnología increíble que encanta a mucha gente, y estamos deseando enseñarte todo sobre ella.

La industria del software evoluciona constantemente, y el ritmo de evolución de la ingeniería de software es más rápido que el de casi cualquier otra disciplina. La velocidad del cambio perturba a muchas organizaciones y a sus departamentos informáticos. Sin embargo, para los optimistas, el cambio trae oportunidades. Cuando las empresas aceptan el cambio y ajustan sus procesos, marcan el camino. Por el contrario, las que se resisten al cambio se ven pisoteadas por la competencia y las exigencias de los consumidores.

Siempre estamos buscando formas de mejorar nuestras vidas. Las necesidades humanas y la tecnología van de la mano. La evolución de nuestras necesidades cotidianas exige una tecnología cada vez mejor, que a su vez inspira la innovación. Cuando nos damos cuenta del poder de estas innovaciones, mejoramos nuestras necesidades, y el ciclo continúa. La industria lleva décadas avanzando de este modo, no siempre a pasos agigantados, sino en pequeños incrementos, a medida que una mejora desencadena la siguiente.

Para valorar plenamente la tecnología sin servidor y las capacidades que ofrece, es beneficioso comprender su historia. Para centrarnos en nuestro tema sin viajar en el tiempo hasta los orígenes de los bits y bytes, empezaremos con la nube y cómo se convirtió en una fuerza a tener en cuenta.

Siéntate, relájate y prepárate para viajar por el apasionante mundo de la tecnología sin servidor.

El camino hacia el sin servidor

En, a principios de la década de 2000, yo (Sheen) me dedicaba a crear aplicaciones distribuidas que se comunicaban principalmente mediante buses de servicios y servicios web, una típica arquitectura orientada a servicios (SOA). Fue en esa época cuando me topé por primera vez con el término "la nube", que ocupaba algunos titulares en el sector tecnológico. Unos años más tarde, recibí instrucciones de la alta dirección para estudiar esta nueva tecnología e informar sobre ciertas características clave. La primera oferta de nube que me pidieron que explorara no era otra que Amazon Web Services.

Mi búsqueda para acercarme a la nube empezó ahí, pero tardé unos años más en apreciar y comprender plenamente el efecto transformador que estaba teniendo en el sector. Como el efecto mariposa, era fascinante considerar cómo los acontecimientos del pasado nos habían traído al presente.

Nota

El efecto mariposa es un término utilizado para referirse al concepto de que un pequeño cambio en el estado de un sistema complejo puede tener repercusiones no lineales en el estado de ese sistema en un momento posterior. El ejemplo más citado es el de una mariposa que agita sus alas en algún lugar del mundo y actúa como desencadenante para provocar un tifón en otro lugar.

De la informática mainframe a la nube moderna

En , a mediados de la década de 1900, los ordenadores centrales se hicieron populares por su enorme potencia de cálculo. Aunque enormes, toscos, muy caros y laboriosos de mantener, eran los únicos recursos disponibles para ejecutar tareas empresariales y científicas complejas. Sólo unas pocas organizaciones e instituciones educativas afortunadas podían permitírselos, y ejecutaban los trabajos por lotes para aprovechar al máximo los costosos sistemas. Se introdujo el concepto de tiempo compartido para programar y compartir los recursos informáticos para ejecutar programas para varios equipos (ver Figura 1-1). Esta distribución de los costes y los recursos hizo que la informática fuera más asequible para distintos grupos, de forma similar a los modelos de uso de recursos bajo demanda y de computación de pago por uso de la nube moderna.

Figura 1-1. Ordenador Mainframe de tiempo compartido (fuente: adaptado de una imagen de Guide to Operating Systems de Greg Tomsho [Cengage])

La aparición del trabajo en red

Los primeros ordenadores centrales eran independientes y no podían comunicarse entre sí. La idea de una Red Informática Intergaláctica o Red Galáctica para interconectar ordenadores remotos y compartir datos fue introducida por el informático J.C.R. Licklider, cariñosamente conocido como Lick, a principios de los años 60. La Agencia de Proyectos de Investigación Avanzada (ARPA) del Departamento de Defensa de Estados Unidos fue pionera en el trabajo, que se materializó en la Red de la Agencia de Proyectos de Investigación Avanzada (ARPANET). Fue uno de los primeros desarrollos de redes que utilizó el protocolo TCP/IP, uno de los principales componentes básicos de Internet. Este avance en la creación de redes supuso un gran paso adelante.

El comienzo de la virtualización

La década de 1970 vio cómo tomaba forma otra tecnología central de la nube moderna. En 1972, el lanzamiento del Sistema Operativo de Máquina Virtual por IBM permitió alojar múltiples entornos operativos dentro de un único ordenador central. Basándose en los primeros conceptos de tiempo compartido y redes, la virtualización completó la otra pieza principal del rompecabezas de la nube. La velocidad de las iteraciones tecnológicas de los años 90 hizo realidad esas ideas y nos acercó a la nube moderna. Las redes privadas virtuales (VPN) y las máquinas virtuales (VM) pronto se convirtieron en productos básicos.

El término cloud computing (computación en nube ) se originó a mediados o finales de los años 90. Algunos lo atribuyen al gigante informático Compaq Corporation, que lo mencionó en un informe interno en 1996. Otros lo atribuyen al profesor Ramnath Chellappa y a su conferencia en INFORMS 1997 sobre un "paradigma emergente para la informática". En cualquier caso, con la velocidad a la que evolucionaba la tecnología, la industria informática ya estaba en una trayectoria de innovación y crecimiento masivos.

El primer vistazo a Amazon Web Services

A medida que maduraba la tecnología de virtualización de , muchas organizaciones crearon capacidades para aprovisionar automática o programáticamente máquinas virtuales para sus empleados y para ejecutar aplicaciones empresariales para sus clientes. Una empresa de comercio electrónico que hizo un buen uso de estas capacidades para apoyar sus operaciones fue Amazon.com.

A principios del año 2000, los ingenieros de Amazon estaban explorando cómo su infraestructura podría ampliarse eficientemente para satisfacer la creciente demanda de los clientes. Como parte de ese proceso, desacoplaron la infraestructura común de las aplicaciones y la abstrajeron como servicio para que pudieran utilizarla varios equipos. Este fue el inicio del concepto conocido hoy en como infraestructura como servicio (IaaS). En el verano de 2006, la empresa lanzó Amazon Elastic Compute Cloud (EC2) para ofrecer máquinas virtuales como servicio en la nube para todo el mundo. ¡Aquello marcó el humilde comienzo del mamotreto actual Amazon Web Services, conocido popularmente como AWS!

Modelos de Implementación en la Nube

A medida que los servicios en la nube cobraron impulso gracias a los esfuerzos de empresas como Amazon, Microsoft, Google, Alibaba, IBM y otras, empezaron a atender las necesidades de distintos segmentos empresariales. Empezaron a surgir diferentes modelos de acceso y patrones de uso (ver Figura 1-2).

Figura 1-2. Comparación figurativa de diferentes entornos en la nube

Estas son las principales variantes actuales:

Nube pública

El servicio en la nube al que la mayoría de nosotros accedemos para trabajo y uso personal es la nube pública, en la que se accede a los servicios a través de la Internet pública. Aunque los proveedores de la nube utilizan recursos compartidos en sus centros de datos, las actividades de cada usuario están aisladas con estrictos límites de seguridad. Esto se conoce comúnmente como entorno multiusuario .

Nube privada

En general, una nube privada es una nube corporativa en la que una sola organización tiene acceso a la infraestructura y a los servicios alojados en ella. Es un entorno de inquilino único. Una variante de la nube privada es la nube gubernamental (por ejemplo, AWS GovCloud), donde la infraestructura y los servicios son específicos para un gobierno concreto y sus organizaciones. Se trata de un entorno altamente seguro y controlado, operado por los ciudadanos del país respectivo.

Nube híbrida

Una nube híbrida utiliza infraestructuras y servicios tanto en nubes públicas como privadas o en las propias instalaciones. Mantener estos entornos requiere unos límites claros en materia de seguridad y compartición de datos .

Nota

Las empresas que prefieren ejecutar sus cargas de trabajo y consumir servicios de varios proveedores de nubes públicas operan en lo que se denomina un entorno multicloud. Hablaremos de ello con más detalle en el próximo capítulo.

La influencia de ejecutarlo todo como un servicio

La idea de de ofrecer algo "como servicio" no es nueva ni específica del software. Las bibliotecas públicas son un gran ejemplo de ofrecer información y conocimiento como un servicio: tomamos prestados libros, los leemos y los devolvemos. El alquiler de ordenadores físicos para empresas es otro ejemplo, que elimina el gasto de capital en comprar y mantener recursos. En su lugar, los consumimos como un servicio por un precio asequible. Esto también nos permite la flexibilidad de utilizar el servicio sólo cuando lo necesitamos: la virtualización hace que pase de ser un bien físico a uno virtual.

En tecnología, una oportunidad lleva a varias oportunidades, y una idea lleva a muchas. De las máquinas virtuales desnudas, las posibilidades se extendieron a la infraestructura de red, las bases de datos, las aplicaciones, la inteligencia artificial (IA), e incluso a simples funciones de propósito único. En poco tiempo, la idea de algo como servicio avanzó hasta un punto en el que ahora podemos ofrecer casi cualquier cosa y todo como servicio.

Infraestructura como servicio (IaaS)

IaaS es uno de los servicios fundamentales de la nube, junto con la plataforma como servicio (PaaS), el software como servicio (SaaS) y la función como servicio (FaaS). Representa la base de una plataforma en nube: los recursos de red, computación y almacenamiento, alojados habitualmente en un centro de datos. Una comprensión de alto nivel de la IaaS es beneficiosa, ya que constituye la base de la tecnología sin servidor.

La Figura 1-3 muestra a vista de pájaro la disposición de los centros de datos de AWS en una zona geográfica determinada, conocida como Región. Para ofrecer un servicio resistente y de alta disponibilidad, AWS ha creado redundancia en cada Región mediante grupos de centros de datos conocidos como Zonas de Disponibilidad (AZ). Las principales ofertas de IaaS de AWS incluyen Amazon EC2 y Amazon Virtual Private Cloud (VPC).

Figura 1-3. Una región de AWS con sus zonas de disponibilidad

Plataforma como servicio (PaaS)

PaaS es una capa de abstracción de servicios sobre IaaS para ofrecer un entorno de desarrollo de aplicaciones en la nube. Proporciona la plataforma y las herramientas necesarias para desarrollar, ejecutar y gestionar aplicaciones sin aprovisionar la infraestructura, el hardware y el software necesarios, reduciendo así la complejidad y aumentando la velocidad de desarrollo. AWS Elastic Beanstalk es un PaaS popular disponible hoy en día.

Software como servicio (SaaS)

SaaS es probablemente la más utilizada y abarca muchas de las aplicaciones que usamos a diario, para tareas como consultar el correo electrónico, compartir y almacenar fotos, transmitir películas y conectar con amigos y familiares mediante servicios de conferencia.

Además de los proveedores de la nube, numerosos proveedores de software (ISV) independientes de utilizan la nube (ofertas IaaS y PaaS) para llevar sus soluciones SaaS a millones de usuarios. Se trata de un mercado en rápida expansión, gracias a los bajos costes y a la fácil adopción de la computación en la nube y sin servidor. La Figura 1-4 muestra cómo encajan estas tres capas de infraestructura en la nube.

Figura 1-4. Las diferentes capas de la infraestructura de la nube

Base de datos como servicio (DBaaS)

DBaaS es un tipo de SaaS que abarca varias opciones y operaciones de almacenamiento de datos. Junto con los tradicionales sistemas de gestión de bases de datos relacionales SQL (RDBMS), ahora hay otros tipos de almacenes de datos disponibles como servicios gestionados, como las bases de datos NoSQL, de almacenamiento de objetos, de series temporales, de gráficos y de búsqueda.

Amazon DynamoDB es una de las bases de datos NoSQL más populares disponibles como servicio (ver Figura 1-5). Una tabla de DynamoDB puede almacenar miles de millones de registros de elementos y, aun así, proporcionar operaciones CRUD (Crear, Leer, Actualizar y Eliminar) con una latencia de un solo dígito o de un milisegundo de bajo doble dígito. Verás el uso de DynamoDB en muchos ejemplos sin servidor a lo largo de este libro.

Figura 1-5. Representación pictórica de Amazon DynamoDB y sus tablas de datos

Amazon Simple Storage Service (S3) es un servicio de almacenamiento de objetos capaz de manejar miles de millones de objetos y petabytes de datos (ver Figura 1-6). Similar al concepto de tablas en los RDBMS y DynamoDB, S3 almacena los datos encubos , teniendo cada cubo sus propias características específicas.

La aparición de servicios como DynamoDB y S3 son sólo algunos ejemplos de cómo las necesidades de almacenamiento han cambiado con el tiempo para atender a los datos no estructurados y cómo la nube permite a las empresas alejarse de la limitada escalabilidad vertical y el funcionamiento mundano de los RDBMS tradicionales para centrarse en crear soluciones a escala de la nube que aporten valor al negocio.

Figura 1-6. Representación pictórica de Amazon S3 y sus buckets de datos

Función como servicio (FaaS)

En términos sencillos , FaaS es un tipo de servicio de computación en la nube que te permite ejecutar tu código de funciones sin tener que aprovisionar tú mismo ningún hardware. FaaS proporcionó una pieza fundamental del rompecabezas de la computación en nube al aportar la tan necesaria computación como servicio, y pronto se convirtió en el catalizador de la adopción generalizada de la tecnología sin servidor. AWS Lambda es la implementación de FaaS más utilizada actualmente (ver Figura 1-7).

Figura 1-7. Representación pictórica del servicio y las funciones de AWS Lambda

Servicios gestionados frente a servicios totalmente gestionados

Antes de explorar las características de serverless en detalle, es esencial comprender qué se entiende por los términos servicios gestionados y servicios totalmente gestionados. Como desarrollador, a menudo consumes API de distintos proveedores para realizar tareas empresariales y cumplir los contratos de API. No tienes acceso a la implementación ni al funcionamiento del servicio, porque el proveedor de servicios los gestiona. En este caso, estás consumiendo un servicio gestionado.

La distinción entre servicios gestionados y totalmente gestionados es a menudo borrosa. Algunos servicios gestionados requieren que crees y mantengas la infraestructura necesaria antes de consumirlos. Por ejemplo, Amazon Relational Database Service (RDS) es un servicio gestionado para RDBMS como MySQL, SQL Server, Oracle, etc. Sin embargo, su configuración estándar requiere que crees una frontera de red virtual, conocida como nube privada virtual (VPC), con grupos de seguridad, tipos de instancia, clústeres, etc., antes de consumir el servicio. En cambio, DynamoDB es un servicio de base de datos NoSQL que puedes configurar y consumir casi al instante. Esta es una forma de distinguir un servicio gestionado de uno totalmente gestionado. Los servicios totalmente gestionados se denominan a veces servicios sin servidor.

Ahora que tienes algunos antecedentes sobre los orígenes y la evolución de la nube y comprendes la sencillez de los servicios totalmente gestionados, es el momento de echar un vistazo más de cerca a la tecnología sin servidor y ver el increíble potencial que tiene para .

Características de la tecnología sin servidor

Sin servidor es un concepto tecnológico que utiliza servicios en la nube totalmente gestionados para llevar a cabo tareas pesadas indiferenciadas, abstrayéndose de los entresijos de la infraestructura y de las tareas de mantenimiento de los servidores.

John Chapin y Mike Roberts, los autores de Programming AWS Lambda (O'Reilly), destilan esto en términos sencillos:

Las empresas que crean y soportan aplicaciones sin servidor no se ocupan de ese hardware ni de los procesos asociados a las aplicaciones. Están externalizando esta responsabilidad a otra persona, es decir, a proveedores de servicios en la nube como AWS.

Como señala Roberts en su artículo "Arquitecturas sin servidor", los primeros usos del término "sin servidor" parecen haberse producido en torno a 2012, a veces en el contexto de proveedores de servicios que asumían la responsabilidad de gestionar servidores, almacenes de datos y otros recursos de infraestructura (lo que a su vez permitía a los desarrolladores centrarse en tareas y flujos de procesos), y a veces en el contexto de sistemas de integración continua y control de código fuente alojados como servicio en lugar de en los servidores locales de una empresa. El término comenzó a ganar popularidad tras el lanzamiento de AWS Lambda en 2014 y Amazon API Gateway en 2015, con el objetivo de incorporar servicios externos a los productos construidos por los equipos de desarrollo. Su uso cobró fuerza cuando las empresas empezaron a utilizar servicios sin servidor para crear nuevas capacidades empresariales, y desde entonces no ha dejado de ser tendencia.

Nota

Durante los primeros días, especialmente tras el lanzamiento de AWS Lambda (la oferta FaaS de AWS), mucha gente utilizaba los términos serverless y FaaS indistintamente, como si ambos representaran el mismo concepto. Hoy en día, FaaS se considera uno de los muchos tipos de servicio que forman parte del ecosistema sin servidor.

Las definiciones de sin servidor suelen reflejar las características principales de una aplicación sin servidor. Junto con las definiciones, estas características se han ido refinando y redefiniendo a medida que la tecnología sin servidor ha ido evolucionando y ganando una mayor adopción en el sector. Echemos un vistazo a algunas de las más importantes.

Pago por uso

Pago por uso es la principal característica que todo el mundo asocia a la tecnología sin servidor. Se originó principalmente en los primeros días de serverless, cuando se equiparaba con FaaS: pagas por cada invocación a una función. Esa interpretación es válida para servicios efímeros como AWS Lambda; sin embargo, si tu aplicación maneja datos, puede que tengas un requisito empresarial para almacenar los datos durante un periodo más largo y para que estén accesibles durante ese tiempo. Los servicios totalmente gestionados como Amazon DynamoDB y Amazon S3 son ejemplos de servicios utilizados para el almacenamiento de datos a largo plazo. En estos casos, hay un coste asociado al volumen de datos que tus aplicaciones almacenan cada mes, a menudo medido en gibibytes (GiB). Recuerda que sigue siendo un pago por uso basado en tu volumen de datos, y no se te cobra por una unidad de disco o matriz de almacenamiento completa.

La Figura 1-8 muestra una sencilla aplicación sin servidor en la que una función Lambda opera sobre los datos almacenados en una tabla de DynamoDB. Mientras que pagas por la función Lambda en función del número de invocaciones y del consumo de memoria, en el caso de DynamoDB, además del coste de pago por uso que conllevan las invocaciones a su API para leer y escribir datos, también pagas por el espacio consumido para almacenar los datos. En el Capítulo 9, verás en detalle todos los elementos de coste relacionados con AWS Lambda y DynamoDB.

Figura 1-8. Una aplicación sencilla sin servidor, que ilustra los elementos del coste del pago por uso y del almacenamiento de datos

Autoescalado y Escala a cero

Una de las características principales de un servicio totalmente gestionado es la capacidad de escalar hacia arriba y hacia abajo en función de la demanda, sin intervención manual. El término escalar a cero es exclusivo de serverless. Tomemos, por ejemplo, una función Lambda de . AWS Lambda administra el aprovisionamiento de infraestructura para ejecutar la función. Cuando la función finaliza y ya no se utiliza, tras un cierto periodo de inactividad el servicio reclama los recursos utilizados para ejecutarla, escalando el número de entornos de ejecución de nuevo a cero.

Entornos de ejecución de AWS Lambda

Cuando se invoca una función Lambda , el servicio AWS Lambda ejecuta el código de la función dentro de un entorno de ejecución. El entorno de ejecución se ejecuta en una máquina virtual virtualizada por hardware (MicroVM) conocida como Firecracker. El entorno de ejecución proporciona un entorno de ejecución seguro y aislado para la ejecución de la función. Consiste en el código de la función, cualquier extensión, el espacio temporal del sistema de archivos local y el tiempo de ejecución del lenguaje.

Un entorno de ejecución se asocia a una función Lambda y nunca se comparte entre funciones.

Por el contrario, cuando hay un gran volumen de solicitudes para una función Lambda, AWS escala automáticamente aprovisionando la infraestructura para ejecutar tantas instancias concurrentes del entorno de ejecución como sean necesarias para satisfacer la demanda. Esto se suele denominarescalado infinito en , aunque la capacidad total depende en realidad del límite de concurrencia de tu cuenta.

Consejo

Con AWS Lambda, puedes optar por mantener un determinado número de contenedores de la función "calientes" en un estado listo estableciendo el valor de concurrencia aprovisionada de una función .

Ambos comportamientos de escalado hacen que serverless sea ideal para muchos tipos de aplicaciones.

Tiempo de espera de la función lambda

En el momento de escribir esto, una función Lambda puede ejecutarse durante un tiempo máximo de 15 minutos. Esto se conoce comúnmente como tiempo de espera. Mientras desarrollas una función Lambda, puedes establecer el tiempo de espera en cualquier valor hasta 15 minutos. Estableces este valor en función del tiempo que necesite la función para completar la ejecución de su lógica, y esperas que termine antes de su tiempo de espera. Si la función sigue ejecutándose cuando alcanza el tiempo de espera establecido, el servicio AWS Lambda la finaliza.

Alta disponibilidad

Una aplicación de alta disponibilidad (HA) evita un único punto de fallo añadiendo redundancia. Para una aplicación comercial, el acuerdo de nivel de servicio (SLA) establece la disponibilidad en términos de un porcentaje. En serverless, como empleamos servicios totalmente gestionados, AWS se encarga de la redundancia y la replicación de datos distribuyendo los recursos informáticos y de almacenamiento en múltiples AZs, evitando así un único punto de fallo. Por tanto, la adopción de serverless proporciona alta disponibilidad de serie.

Arranque en frío

El arranque en frío se asocia habitualmente con FaaS. Por ejemplo, como has visto antes, cuando una función Lambda de AWS está inactiva durante un periodo de tiempo, su entorno de ejecución se apaga. Si la función vuelve a ser invocada después de estar inactiva durante un tiempo, AWS aprovisiona un nuevo entorno de ejecución para ejecutarla. La latencia en esta configuración inicial suele denominarse tiempo de arranque en frío. Una vez finalizada la ejecución de la función, el servicio Lambda conserva el entorno de ejecución durante un periodo no determinista. Si la función se invoca de nuevo durante este periodo, no incurre en la latencia de arranque en frío. Sin embargo, si hay más invocaciones simultáneas, el servicio Lambda aprovisiona un nuevo entorno de ejecución para cada invocación concurrente, lo que provoca un arranque en frío.

Muchos factores contribuyen a esta latencia inicial: el tamaño del paquete de implementación de la función, el entorno de ejecución del lenguaje de programación, la memoria (RAM) asignada a la función, el número de preconfiguraciones (como las inicializaciones de datos estáticos), etc. Como ingeniero que trabaja en serverless, es esencial comprender el arranque en frío, ya que influye en tus decisiones arquitectónicas, de desarrollo y operativas (ver Figura 1-9).

Figura 1-9. Latencia de invocación de funciones para inicios en frío y ejecuciones en caliente: las peticiones 1 y 2 se inician en frío, mientras que un contenedor caliente se encarga de la petición 3

Las ventajas únicas de la tecnología sin servidor

Junto con las características principales de serverless que has visto en la sección anterior, comprender algunas de sus ventajas únicas es esencial para optimizar el proceso de desarrollo y permitir a los equipos mejorar su velocidad en la entrega de resultados empresariales. En esta sección, echaremos un vistazo a algunas de las características clave que admite la tecnología sin servidor.

Individualidad y granularidad de los recursos

La "talla única" no se aplica a los servicios sin servidor. La capacidad de configurar y operar servicios sin servidor a nivel individual te permite considerar tu aplicación sin servidor no sólo como un todo, sino a nivel de cada recurso, trabajando con sus características específicas. A diferencia de lo que ocurre con las aplicaciones de contenedor tradicionales, ya no necesitas establecer un conjunto común de características operativas a nivel de contenedor.

Supongamos que tu aplicación tiene varias funciones Lambda. Algunas funciones gestionan las peticiones de los usuarios desde tu sitio web, mientras que otras realizan trabajos por lotes en el backend. Puedes proporcionar más memoria a las funciones orientadas al usuario para que puedan responder rápidamente, y optar por un tiempo de espera más largo para las funciones de trabajo por lotes del backend, donde el rendimiento no es crítico. Con las colas de Amazon Simple Queue Service (SQS), por ejemplo, configuras la rapidez con la que quieres procesar los mensajes a medida que llegan a la cola, o puedes decidir si quieres retrasar el momento en que un mensaje esté disponible para su procesamiento.

Nota

Amazon SQS es un servicio de cola de mensajes totalmente administrado y altamente escalable que se utiliza para enviar, recibir y almacenar mensajes. Es uno de los servicios principales de AWS y ayuda a construir microservicios débilmente acoplados. Cada cola SQS tiene varios atributos; puedes ajustar estos valores para configurar la cola según tus necesidades.

Cuando construyes una aplicación que utiliza varios recursos -funciones Lambda, colas SQS, tablas DynamoDB, buckets S3, etc.- tienes la flexibilidad de ajustar el comportamiento de cada recurso según dicten los requisitos empresariales y operativos. Esto se representa en la Figura 1-10, que muestra parte de un microservicio de procesamiento de pedidos.

La capacidad de operar a nivel granular aporta muchas ventajas, como verás a lo largo de este libro. Comprender la individualidad de los recursos y desarrollar una mentalidad granular mientras construyes aplicaciones sin servidor te ayuda a diseñar soluciones seguras, rentables y sostenibles que son fáciles de manejar.

Figura 1-10. Una sección de un microservicio de procesamiento de pedidos, que ilustra cómo cada recurso sin servidor tiene diferentes configuraciones

Capacidad para optimizar los servicios en cuanto a coste, rendimiento y sostenibilidad

Las técnicas de optimización de costes y de rendimiento son habituales en el desarrollo de software. Cuando optimizas para reducir el coste, tu objetivo es reducir la potencia de procesamiento, el consumo de memoria y la asignación de almacenamiento. Con una aplicación tradicional, ejerces estos cambios a alto nivel, afectando a todas las partes de la aplicación. No puedes seleccionar una función o tabla de base de datos concreta a la que aplicar los cambios. En tales situaciones, si no se equilibran adecuadamente, los cambios que realices podrían provocar degradaciones del rendimiento o mayores costes en otros lugares. Serverless ofrece un modelo de optimización mejor.

Sin servidor permite una optimización más profunda

Una aplicación sin servidor se compone de varios servicios gestionados, y puede contener varios recursos del mismo servicio gestionado. Por ejemplo, en la Figura 1-10, has visto tres funciones Lambda del servicio AWS Lambda. No estás obligado a optimizar todas las funciones de la misma manera. En su lugar, dependiendo de tus requisitos, puedes optimizar una función por rendimiento y otra por coste, o dar a una función un tiempo de espera más largo que a las demás. También puedes permitir diferentes necesidades de ejecución concurrente.

Basándote en sus características, puedes exhibir el mismo principio con otros recursos, como colas, tablas, API, etc. Imagina que tienes varios microservicios, cada uno de los cuales contiene varios recursos sin servidor. Para cada microservicio, puedes optimizar cada recurso individual a un nivel granular. ¡Esto es optimización en su nivel más profundo y fino en acción!

Optimizar para la sostenibilidad

Además de las estrategias tradicionales de optimización de costes y rendimiento, ahora es necesario considerar también la sostenibilidad. El Capítulo 10 explica esto en detalle, presentando varios patrones para desarrollar y operar tus aplicaciones en un entorno sostenible en la nube de AWS.

Optimizar para la sostenibilidad puede repercutir en el coste y el rendimiento. Como principio general, cuando optimizas para reducir costes, es probable que consumas menos recursos informáticos, lo que se traduce en un menor consumo de energía, fomentando así la sostenibilidad. Sin embargo, optimizar para obtener un mayor rendimiento a menudo conlleva consumir más energía y puede no alinearse con los objetivos de sostenibilidad. En tales situaciones, tendrás que hacer concesiones: identifica el nivel de rendimiento esperado, y optimiza hasta él y no más allá.

Optimización del almacenamiento

Las modernas aplicaciones en la nube ingieren enormes volúmenes de datos: datos operativos, métricas, registros, etc. Los equipos propietarios de los datos pueden querer optimizar su almacenamiento (para minimizar costes y, en algunos casos, mejorar el rendimiento) aislando y conservando sólo los datos críticos para el negocio.

Los servicios de datos gestionados proporcionan funciones integradas para eliminar o transicionar datos innecesarios. Por ejemplo, Amazon S3 admite políticas de retención de datos por cubo para eliminar datos o transicionarlos a una clase de almacenamiento diferente, y DynamoDB te permite configurar el valor Time to Live (TTL) en cada elemento de una tabla. Las opciones de optimización del almacenamiento no se limitan a los almacenes de datos principales; puedes especificar el periodo de retención de mensajes para cada cola SQS, flujo Kinesis, caché API, etc.

Advertencia

DynamoDB gestiona la configuración TTL de los elementos de la tabla de forma eficiente, independientemente de cuántos elementos haya en una tabla y cuántos de esos elementos tengan una marca de tiempo TTL establecida. Sin embargo, en algunos casos, un elemento puede tardar hasta 48 horas en eliminarse de la tabla. En consecuencia, ésta puede no ser una solución ideal si necesitas una eliminación de elementos garantizada en el momento TTL exacto.

Gestión de Identidad y Acceso (IAM) de AWS

AWS IAM es un servicio que controla la autenticación y autorización del acceso a los servicios y recursos de AWS. Ayuda a definir quién puede acceder a qué servicios y recursos, y en qué condiciones. El acceso a un servicio o recurso puede concederse a una identidad, como un usuario, o a un recurso, como una función Lambda. El objeto que contiene los detalles de los permisos se conoce como política y se almacena como un documento JSON, como se muestra en el Ejemplo 1-1.

Ejemplo 1-1. Política IAM para permitir acciones de lectura en la tabla Pedidos de DynamoDB

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:BatchGet*",
        "dynamodb:Get*",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:eu-west-1:12890:table/Orders"
    }
  ]
}

Apoyo a medidas de seguridad y privacidad de datos más profundas

Ahora comprendes cómo la individualidad y granularidad de los servicios en serverless te permiten ajustar cada parte de una aplicación a las distintas demandas. Las mismas características te permiten aplicar medidas de protección a un nivel más profundo, según sea necesario, en todo el ecosistema.

Permisos a nivel de función

La Figura 1-11 muestra una sencilla aplicación sin servidor que permite almacenar pedidos y consultar el estado de un pedido determinado a través de los endpoints POST /orders y GET /orders/{id}/status, respectivamente, que son gestionados por las correspondientes funciones Lambda. La función que consulta la tabla Pedidos para encontrar el estado realiza una operación de lectura. Dado que esta función no modifica los datos de la tabla, sólo requiere el privilegio dynamodb:Query. Esta idea de proporcionar los permisos mínimos necesarios para completar una tarea se conoce como el principio del menor privilegio.

Nota

El principio del menor privilegio es una buena práctica de seguridad que sólo concede los permisos necesarios para realizar una tarea. Como se muestra en el Ejemplo 1-1, lo defines como una política IAM limitando las acciones permitidas en recursos específicos. Es uno de los principios de seguridad más fundamentales en AWS y debería formar parte del pensamiento de seguridad de todo ingeniero. Aprenderás más sobre este tema en el Capítulo 4.

Figura 1-11. Aplicación sin servidor que muestra dos funciones con diferentes privilegios de acceso a la misma tabla de datos

Permisos granulares a nivel de registro

La política IAM de del Ejemplo 1-1 mostraba a cómo configurar el acceso para leer (consultar) datos de la tabla Pedidos. La Tabla 1-1 contiene datos de muestra de algunos pedidos, en los que un pedido se divide en tres partes para mejorar el acceso y la privacidad: SOURCE, STATUS, y ADJUSTED.

Tabla 1-1. Ejemplo de tabla de Pedidos con varios tipos de artículos

PK	SK	Estado	Seguimiento	Total	Artículos
FUENTE	100-255-8730	Procesando	44tesYuwLo	299.99	{ ... }
ESTADO	100-255-8730	Procesando	44tesYuwLo
FUENTE	100-735-6729	Entregado	G6txNMo26d	185.79	{ ... }
AJUSTADO	100-735-6729	Entregado	G6txNMo26d	175.98	{ ... }
ESTADO	100-735-6729	Entregado	G6txNMo26d

Según el principio del menor privilegio, la función Lambda que consulta el estado de un pedido sólo debe poder acceder al registro STATUS de ese pedido. En la Tabla 1-2 se indican los registros a los que debe poder acceder la función.

Tabla 1-2. STATUS registros accesibles para la función de consulta de estado

PK	SK	Estado	Seguimiento	Total	Artículos
FUENTE	100-255-8730	Procesando	44tesYuwLo	299.99	{ ... }
ESTADO	100-255-8730	Procesando	44tesYuwLo
FUENTE	100-735-6729	Entregado	G6txNMo26d	185.79	{ ... }
AJUSTADO	100-735-6729	Entregado	G6txNMo26d	175.98	{ ... }
ESTADO	100-735-6729	Entregado	G6txNMo26d

Para conseguirlo, puedes utilizar una política IAM con una condición dynamodb:LeadingKeys y los detalles de la política que aparecen en el Ejemplo 1-2.

Ejemplo 1-2. Política para restringir el acceso de lectura a un tipo específico de elemento

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOrderStatus",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": [
        "arn:aws:dynamodb:…:table/Orders"
      ],
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": [
            "STATUS"
          ]
        }
      }
    }
  ]
}

La política condicional que se muestra aquí funciona a nivel de registro. DynamoDB también admite condiciones a nivel de atributo para obtener los valores sólo de los atributos permitidos de un registro, para aplicaciones que requieren un control de acceso aún más granular.

Políticas como ésta son habituales en AWS y aplicables a varios servicios comunes que utilizarás para crear tus aplicaciones. Conocer y comprender dónde y cuándo utilizarlas te beneficiará enormemente como ingeniero de serverless .

Desarrollo incremental e iterativo

Desarrollo iterativo permite a los equipos desarrollar y entregar productos en pequeños incrementos pero en rápida sucesión. Como dice Eric Ries en su libro The Startup Way (Penguin), empiezas de forma sencilla y escalas rápido. Tu producto evoluciona constantemente con nuevas funciones que benefician a tus clientes y añaden valor empresarial.

La arquitectura basada en eventos (EDA), que exploraremos en detalle en el Capítulo 3, es el núcleo del desarrollo sin servidor. En la arquitectura sin servidor, compones tus aplicaciones con servicios libremente acoplados que interactúan mediante eventos, mensajes y API. Los principios EDA te permiten construir aplicaciones sin servidor modulares y extensibles.¹ Cuando evitas las dependencias rígidas entre tus servicios, resulta más fácil ampliar tus aplicaciones añadiendo nuevos servicios que no interrumpan el funcionamiento de los existentes.

Equipos de ingenieros multicualificados y diversos

Adoptar una nueva tecnología conlleva cambios y también retos en una organización. Cuando los equipos se pasan a un nuevo lenguaje, base de datos, plataforma SaaS, tecnología de navegador o proveedor de nube, los cambios en esa área suelen requerir cambios en otras. Por ejemplo, adoptar un nuevo lenguaje de programación puede exigir modificaciones en los procesos de desarrollo, compilación e implementación. Del mismo modo, trasladar tus aplicaciones a la nube puede crear la demanda de muchos procesos y habilidades nuevos.

Influencia de la cultura DevOps

El enfoque DevOps elimina las barreras entre el desarrollo y las operaciones, haciendo más rápido el desarrollo de nuevos productos y más fácil su mantenimiento. Adoptar un modelo DevOps lleva a un ingeniero de software que de otro modo se centra en el desarrollo de aplicaciones a realizar tareas operativas. Ya no trabaja en un ciclo de desarrollo de software aislado, sino que participa en sus múltiples fases, como la integración y entrega continuas (CI/CD), el monitoreo y la observabilidad, la puesta en marcha de la infraestructura de la nube y la seguridad de las aplicaciones, entre otras cosas.

Adoptar un modelo sin servidor te lleva muchos pasos más allá. Aunque te libera de gestionar servidores, ahora estás programando la lógica empresarial, componiendo tu aplicación utilizando servicios gestionados, tejiéndolos juntos con infraestructura como código (IaC) y operándolos en la nube. No basta con saber escribir software. Tienes que proteger tu aplicación de usuarios malintencionados, hacer que esté disponible 24 horas al día, 7 días a la semana, para clientes de todo el mundo, y observar sus características operativas para mejorarla continuamente. Convertirse en un exitoso ingeniero sin servidor requiere, por tanto, desarrollar todo un nuevo conjunto de habilidades, y cultivar una mentalidad DevOps (ver Figura 1-12).

Figura 1-12. Ingenieros especializados tradicionales en silos frente a ingenieros multidisciplinares sin servidor

Tu evolución como ingeniero sin servidor

Considera la sencilla aplicación sin servidor mostrada en la Figura 1-8, donde una función Lambda lee y escribe en una tabla DynamoDB. Imagina que dominas TypeScript y has elegido Node.js como entorno de ejecución de Lambda. A medida que implementas la función, se convierte en tu responsabilidad codificar las interacciones con DynamoDB. Para ser eficiente, aprende conceptos NoSQL, identifica los atributos de clave de partición (PK) y clave de ordenación (SK), así como los patrones de acceso a datos adecuados para escribir tus consultas, etc. Además, puede haber requisitos de replicación de datos, TTL, almacenamiento en caché y otros. La seguridad también es una preocupación, por lo que a continuación aprenderás sobre AWS IAM, cómo crear roles y políticas y, lo más importante, el principio del menor privilegio. De ser un programador competente en un lenguaje concreto, tu papel de ingeniero da un giro de 360 grados. A medida que te conviertes en un ingeniero sin servidor, adquieres muchas habilidades y responsabilidades nuevas.

Como has visto en la sección anterior, tu trabajo requiere tener la capacidad de construir la canalización de implementación para tu aplicación, comprender las métricas del servicio y actuar de forma proactiva en los incidentes de producción. Ahora eres un ingeniero multidisciplinar, y cuando la mayoría de los ingenieros de un equipo son multidisciplinares, se convierte en un equipo de ingeniería diverso capaz de realizar una entrega eficiente de extremo a extremo sin servidor. Para las organizaciones en las que es necesario mejorar las cualificaciones de los ingenieros, el Capítulo 2 trata en detalle las formas de hacer crecer los talentos de serverless .

Las partes de una aplicación sin servidor y su ecosistema

Un ecosistema es un área geográfica donde plantas, animales y otros organismos, así como el clima y el paisaje, trabajan juntos para formar una burbuja de vida.

NationalGeographic.org

En la naturaleza , un ecosistema contiene partes vivas y no vivas, también conocidas como factores. Cada factor de un ecosistema depende de todos los demás factores, directa o indirectamente. La superficie de la Tierra es una serie de ecosistemas conectados.

La analogía con el ecosistema es intencionada. Demasiado a menudo se imagina la tecnología sin servidor como un diagrama de arquitectura o un plano, pero es mucho más que FaaS y un simple marco. Tiene asociados elementos técnicos y no técnicos. ¡Sin servidor es un ecosistema tecnológico!

Como has aprendido antes en este capítulo, los servicios gestionados forman la mayor parte de una aplicación sin servidor. Sin embargo, por sí solos no pueden dar vida a una aplicación: intervienen muchos otros factores. La Figura 1-13 muestra algunos de los elementos centrales que componen el ecosistema sin servidor.

Figura 1-13. Partes del ecosistema de la tecnología sin servidor

Incluyen:

La plataforma en la nube

Este es el habilitador del ecosistema sin servidor -AWS en nuestro caso-. El entorno de alojamiento en la nube proporciona los recursos informáticos, de almacenamiento y de red necesarios.

Servicios gestionados en la nube

Servicios gestionados de son los componentes básicos de las aplicaciones sin servidor. Compones tus aplicaciones consumiendo servicios de computación, transporte de eventos, mensajería, almacenamiento de datos y otras actividades diversas.

Arquitectura

Es el plano que describe el propósito y el comportamiento de tu aplicación sin servidor. Definir y acordar una arquitectura es una de las actividades más importantes en el desarrollo sin servidor.

Definición de infraestructura

La definición de infraestructura -también conocida como infraestructura como código (IaC) y expresada como un guión descriptivo- es como el diagrama de circuitos de tu aplicación. Lo entreteje todo con las características, dependencias, permisos y controles de acceso adecuados. El IaC, cuando se actúa en la nube, tiene el poder de dar vida a tu aplicación sin servidor o derribarla.

Herramientas de desarrollo y prueba

El entorno de ejecución de tu FaaS dicta el lenguaje de programación, las bibliotecas, los plug-ins, los marcos de pruebas y varias otras ayudas para el desarrollador. Estas herramientas pueden variar de un ecosistema a otro, según el dominio del producto y las preferencias de los equipos de ingeniería.

Repositorio y canalizaciones

El repositorio es un almacén versionado para todos tus artefactos, y los pipelines realizan las acciones que llevan tu aplicación sin servidor desde un entorno de desarrollo hasta sus clientes objetivo, pasando por varios puntos de control a lo largo del camino. La definición de la infraestructura desempeña un papel fundamental en este proceso.

Herramientas de observabilidad

Observabilidad Las herramientas y técnicas de actúan como un espejo para reflejar el estado operativo de tu aplicación, ofreciendo una visión más profunda de cómo se comporta con respecto a su finalidad prevista. Un sistema no observable no puede sostenerse.

Buenas prácticas

Para salvaguardar tu aplicación sin servidor frente a las amenazas a la seguridad y las demandas de escalado, y garantizar que sea observable y resistente frente a interrupciones inesperadas, necesitas principios bien diseñados y buenas prácticas que actúen como barandillas. El Marco Bien Arquitectado de AWS es una guía de buenas prácticas esencial; la examinaremos más adelante en este capítulo.

Constructores y partes interesadas

Las personas de que plantean los requisitos para una aplicación y las que la diseñan, construyen y operan en la nube también forman parte del ecosistema. Además de todas las herramientas y técnicas, el papel de los seres humanos en un ecosistema sin servidor es vital: son los responsables de tomar las decisiones correctas y realizar las acciones necesarias, ¡de forma similar al papel que todos desempeñamos en nuestro ecosistema medioambiental !

¿Por qué AWS es una gran plataforma para Serverless?

Como mencionó anteriormente en este capítulo, aunque el término sin servidor apareció por primera vez en la industria en torno a 2012, ganó tracción tras el lanzamiento de AWS Lambda en 2014. Aunque el gran número de personas que se subieron al carro de Lambda elevó la tecnología sin servidor a nuevas cotas, AWS ya contaba en ese momento con un par de servicios sin servidor totalmente gestionados que prestaban servicio a los clientes. Amazon SQS se lanzó casi 10 años antes que AWS Lambda. Amazon S3, el muy querido y utilizado almacén de objetos en la nube, se lanzó en 2006, mucho antes de que la nube llegara a los rincones de la industria informática.

Este salto temprano a la nube con una visión futurista, ofreciendo servicios de contenedores y servicios sin servidor totalmente gestionados, permitió a Amazon lanzar nuevos productos más rápido que cualquier otro proveedor. Reconociendo el potencial, muchos de los primeros en adoptar la nube hicieron realidad rápidamente sus ideas de negocio y lanzaron sus aplicaciones en AWS. Aunque el mercado de la nube está creciendo rápidamente, AWS sigue siendo el principal proveedor de servicios en la nube a nivel mundial.

La popularidad de los servicios sin servidor de AWS

Trabajar estrechamente con los clientes y monitorear las tendencias de la industria ha permitido a AWS iterar rápidamente las ideas y lanzar varios servicios sin servidor importantes en áreas como API, funciones, almacenes de datos, streaming de datos, IA, aprendizaje automático, transporte de eventos, flujo de trabajo y orquestación, y más.

¿Qué hay en un nombre?

Cuando mires los nombres de los servicios de AWS, notarás una mezcla de prefijos "Amazon" y "AWS", por ejemplo, Amazon DynamoDB y AWS Step Functions. Esto confunde a todo el mundo, incluidos los empleados de Amazon. Aparentemente, no se trata de una selección aleatoria, sino de una forma de diferenciar los servicios en función de sus características fundamentales.

La teoría más popular y relevante sugiere que los servicios con el prefijo Amazon funcionan por sí solos (servicios independientes), mientras que los que llevan el prefijo AWS dan soporte a otros servicios (servicios de utilidad) y no están pensados para ser utilizados por sí solos. AWS Lambda, por ejemplo, es activado por otros servicios. Sin embargo, a medida que los servicios evolucionan con el tiempo con nuevas capacidades, puedes encontrar excepciones en las que esta distinción ya no sea válida.

AWS es una completa plataforma en la nube que ofrece más de 200 servicios para construir y operar tanto cargas de trabajo sin servidor como cargas de trabajo sin servidor. La Tabla 1-3 enumera algunos de los servicios gestionados sin servidor más utilizados. Verás que muchos de estos servicios aparecen en nuestros debates a lo largo de este libro.

Tabla 1-3. Servicios populares sin servidor de AWS

Categoría	Servicio
Analítica	Amazon Kinesis, Amazon Athena, AWS Glue, Amazon QuickSight
Creación de aplicaciones	AWS Amplify
Construcción de API	Amazon API Gateway, AWS AppSync
Integración de aplicaciones	Amazon EventBridge, AWS Step Functions, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), Amazon API Gateway, AWS AppSync
Calcula	AWS Lambda
Entrega de contenidos	Amazon CloudFront
Base de datos	Amazon DynamoDB, Amazon Aurora Sin Servidor
Herramientas para desarrolladores	AWS CloudFormation, AWS Kit de desarrollo en la nube (CDK), AWS Modelo de aplicación sin servidor (SAM), AWS CodeBuild, AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline
Correos electrónicos	Amazon Simple Email Service (SES)
Arquitectura basada en eventos	Amazon EventBridge, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), AWS Lambda
Gobernanza	Herramienta bien diseñada de AWS, AWS Trusted Advisor, AWS Systems Manager, Organizaciones de AWS
Streaming de eventos de gran volumen	Amazon Kinesis Data Streams, Amazon Kinesis Data Firehose
Identidad, autenticación y seguridad	AWS Identity and Access Management (IAM), Amazon Cognito, AWS Secrets Manager, AWS WAF, Amazon Macie
Aprendizaje automático	Amazon SageMaker, Amazon Translate, Amazon Comprehend, Amazon DevOps Guru
Red	Ruta 53 de Amazon
Almacén de objetos	Servicio de almacenamiento simple de Amazon (S3)
Observabilidad	Amazon CloudWatch, AWS X-Ray, AWS CloudTrail
Orquestación	Funciones escalonadas de AWS
Seguridad	AWS Identity and Access Management (IAM), Amazon Cognito, AWS Secrets Manager, AWS Systems Manager Parameter Store

El marco bien diseñado de AWS

El marco AWS Well-Architected Framework es una colección de buenas prácticas arquitectónicas para diseñar, construir y operar aplicaciones seguras, escalables, altamente disponibles, resistentes y rentables en la nube. Consta de seis pilares que cubren áreas fundamentales de un sistema moderno en la nube:

Excelencia operativa

El pilar Excelencia Operativa proporciona principios de diseño y buenas prácticas para concebir objetivos organizativos que permitan identificar, preparar, operar, observar y mejorar las cargas de trabajo operativas en la nube. La previsión de fallos y los planes de mitigación, la evolución de las aplicaciones en incrementos pequeños pero frecuentes, y la evaluación y mejora continuas de los procedimientos operativos son algunos de los principios básicos de este pilar.

Seguridad

El pilar de seguridad se centra en la gestión de la identidad y el acceso, la protección de las aplicaciones en todas las capas, la garantía de la privacidad y el control de los datos, así como la trazabilidad y la auditoría de todas las acciones, y la preparación y respuesta ante sucesos de seguridad. Inculca el pensamiento de seguridad en todas las fases del desarrollo y es responsabilidad de todos los implicados.

Fiabilidad

Una aplicación implementada y operada en la nube debe ser capaz de escalar y funcionar de forma coherente a medida que cambia la demanda. Los principios y prácticas del pilar Fiabilidad incluyen el diseño de aplicaciones para que funcionen con cuotas y límites de servicio, la prevención y mitigación de fallos, y la identificación y recuperación de fallos, entre otras orientaciones.

Rendimiento Eficiencia

El pilar Eficiencia del rendimiento trata del enfoque de la selección y el uso de la tecnología y los recursos adecuados para construir y hacer funcionar un sistema eficiente. El monitoreo y las métricas de datos desempeñan aquí un papel importante en la revisión constante y la realización de compensaciones para mantener la eficiencia en todo momento.

Optimización de costes

El pilar Optimización de Costes guía a las organizaciones para operar aplicaciones empresariales en la nube de forma que ofrezcan valor y mantengan los costes bajos. Las buenas prácticas se centran en la gestión financiera, la concienciación sobre los costes de la nube, el uso de recursos y tecnologías rentables, como la ausencia de servidor, y el análisis y la optimización continuos en función de la demanda empresarial.

Sostenibilidad

El pilar Sustainability (Sostenibilidad) es la última incorporación al Marco de trabajo bien diseñado de AWS. Se centra en contribuir a un medio ambiente sostenible mediante la reducción del consumo de energía; la arquitectura y el funcionamiento de aplicaciones que reduzcan el uso de potencia informática, espacio de almacenamiento y viajes de ida y vuelta por la red; el uso de recursos bajo demanda como los servicios sin servidor; y la optimización al nivel requerido y no sobre.

Planes de AWS Technical Support

Dependiendo de la escala de tu operación en la nube y el tamaño de la empresa, Amazon ofrece cuatro planes de soporte técnico que se adaptan a tus necesidades:

Desarrollador

Este es el modelo de soporte básico, adecuado para experimentar, crear prototipos o probar aplicaciones sencillas al principio de tu viaje sin servidor.

Empresa

A medida que pasas de la fase de experimentación a la de implementaciones de producción y aplicaciones empresariales operativas al servicio de los clientes, éste es el nivel de soporte recomendado. Además de otras funciones de soporte, añade garantías de tiempo de respuesta para los sistemas de producción que se estropeen o se caigan (<4 horas y <1 hora, respectivamente).

Rampa de acceso a la empresa

La principal diferencia entre éste y el plan Empresa es la garantía de tiempo de respuesta cuando se caen las aplicaciones críticas para la empresa (<30 minutos, frente a <15 minutos con el plan de nivel superior). Los planes de nivel inferior no ofrecen esta garantía.

Empresa

Si formas parte de una gran organización con varios equipos que desarrollan y operan cargas de trabajo de alto perfil y misión crítica, el plan de asistencia Enterprise te proporcionará la atención más inmediata. En caso de incidencia con tus aplicaciones de misión crítica, obtendrás asistencia en 15 minutos. Este plan también incluye varias ventajas adicionales de , entre las que se incluyen :

• Un Gestor Técnico de Cuentas (TAM) dedicado que actúa como primer punto de contacto entre tu organización y AWS

• Cadencia de reuniones regulares (normalmente mensuales) con tu TAM

• Asesoramiento de expertos de AWS, como arquitectos de soluciones especializados en tu dominio empresarial, a la hora de crear una aplicación

• Evaluación de tus sistemas existentes y recomendaciones basadas en las buenas prácticas de AWS Well-Architected Framework

• Formación y talleres para mejorar tus habilidades internas en AWS y las buenas prácticas de desarrollo

• Noticias sobre el lanzamiento de nuevos productos y funciones

• Oportunidades de probar nuevos productos en versión beta antes de que estén disponibles en general

• Invitaciones a jornadas de inmersión y reuniones presenciales con los equipos de producto de AWS relacionados con las tecnologías con las que trabajas

Nota

El principio rector número uno de Amazon es la obsesión por el cliente: "Los líderes empiezan por el cliente y trabajan hacia atrás. Trabajan enérgicamente para ganarse y mantener la confianza del cliente. Aunque los líderes prestan atención a los competidores, se obsesionan con los clientes".

Soporte de la comunidad de desarrolladores de AWS

La comunidad de desarrolladores de AWS es un foro técnico increíblemente activo y solidario. Hay varias vías que puedes seguir para formar parte de esta comunidad, y hacerlo es muy recomendable, tanto para tu crecimiento como ingeniero sin servidor como para garantizar la adopción con éxito de la tecnología sin servidor en tu empresa. Entre ellas están:

Comprométete con los Defensores del Desarrollador (DA) de AWS.

Los DA de AWS conectan a la comunidad de desarrolladores con los diferentes equipos de producto de AWS. Puedes seguir los desarrollos sin servidor en las redes sociales. Encontrarás a los DA especialistas en sin servidor ayudando a la comunidad respondiendo a preguntas y aportando contenido técnico a través de blogs, transmisiones en directo y vídeos, código compartido en GitHub, conferencias, reuniones, etc.

Acércate a los Héroes de AWS y a los Constructores de la Comunidad.

El programa Héroes de AWS reconoce a Expertos de AWS cuyas contribuciones tienen un impacto real en la comunidad tecnológica. Fuera de AWS, estos expertos comparten sus conocimientos e historias de adopción sin servidor desde las trincheras.

En el momento de escribir este libro, Sheen Brisals ha sido reconocido como Héroe sin Servidor de AWS.

El programa de Constructores de la Comunidad de AWS es una iniciativa mundial para reunir a entusiastas de AWS y expertos en ascenso a los que les apasiona compartir conocimientos y conectar con los equipos de productos y DA de AWS, Héroes y expertos del sector. Identificar a los constructores que contribuyen al espacio sin servidor y aprender de sus experiencias profundizará tus conocimientos.

En el momento de escribir este libro, Luke Hedger ha sido reconocido como AWS Community Builder.

Únete a un Club de la Nube de AWS.

Hay una próspera comunidad dirigida por estudiantes, con Clubes de la Nube de AWS en múltiples regiones de todo el mundo. Los estudiantes pueden unirse a su club local para establecer contactos, aprender sobre AWS y desarrollar sus carreras. Los capitanes de los Clubes Nube organizan eventos para aprender juntos, conectar con otros clubes y obtener créditos AWS y vales de certificación, entre otras oportunidades.

Inscríbete en AWS Startup o AWS Educate.

AWS tiene programas populares para ayudarte a hacer realidad tus ideas. AWS Actívate es para cualquier persona con grandes ideas y ambiciones o empresas de nueva creación de menos de 10 años. AWS ofrece las herramientas, recursos, créditos y consejos necesarios para impulsar el éxito en cada etapa del viaje.

AWS Educate es un recurso de aprendizaje para estudiantes y profesionales. Ofrece créditos de AWS que pueden utilizarse para cursos y proyectos, acceso a formación gratuita y oportunidades para establecer contactos.

Asiste a las conferencias de AWS.

Una parte esencial del viaje de adopción sin servidor de una empresa es evaluar continuamente sus procesos de desarrollo, dominios, organización del equipo, cultura de ingeniería, buenas prácticas, etc. Las conferencias y eventos colaborativos son las plataformas perfectas para encontrar soluciones a tus preocupaciones, validar tus ideas e identificar las acciones a corregir antes de que sea demasiado tarde.

El tipo y la escala de las conferencias varían. Por ejemplo, AWS re:Invent es una conferencia anual de una semana de duración que reúne a decenas de miles de entusiastas de la tecnología y los negocios con cientos de sesiones repartidas en cinco días, mientras que AWS Summits y AWS Community Summits son eventos locales -la mayoría de un día- celebradosen todo el mundo para acercar a la comunidad y a los expertos en tecnología. La mayor parte del contenido también se comparte online. Eventos y seminarios web de AWS es un buen lugar para identificar eventos que puedan adaptarse a tus propósitos .

Resumen

Al iniciar tu viaje sin servidor, ya sea como aprendiz independiente o como parte de un equipo empresarial, es valioso tener una comprensión de cómo evolucionó la nube y cómo facilitó el desarrollo de la tecnología sin servidor. Este capítulo ha proporcionado esa base y ha esbozado el importante potencial de la tecnología sin servidor y las ventajas que puede aportar a una organización.

Toda tecnología requiere una plataforma sólida para prosperar y una comunidad apasionada que la apoye. Aunque no es ni mucho menos la única opción que existe, Amazon Web Services (AWS) es una plataforma fantástica con numerosas ofertas de servicios y programas de apoyo dedicados a los desarrolladores. Como se subraya en este capítulo, para tener éxito en tu adopción sin servidor, es primordial que compartas tus experiencias y aprendas de expertos contrastados del sector.

En el próximo capítulo, examinaremos la adopción de la tecnología sin servidor en una empresa. Examinaremos algunas de las cosas fundamentales que una organización debe evaluar y hacer para incorporar la tecnología sin servidor y convertirla en una empresa de éxito para sus ingenieros, usuarios y negocio.

Entrevista con un experto del sector

Danilo Poccia, Evangelista Jefe (EMEA), Amazon Web Services

Danilo trabaja en con start-ups y empresas de todos los tamaños para apoyar su innovación. En su puesto de Evangelista Jefe (EMEA) de Amazon Web Services, aprovecha su experiencia para ayudar a la gente a hacer realidad sus ideas, centrándose en las arquitecturas sin servidor y la programación basada en eventos, así como en el impacto técnico y empresarial del aprendizaje automático y la informática de perímetro. Es autor de AWS Lambda in Action: Event-Driven Serverless Applications (Manning) y da conferencias en todo el mundo.

P: ¿Por qué necesita la industria del software la tecnología sin servidor?

Cuando creas una aplicación, puede resultar complejo implementarla, probarla o añadir una nueva función antes o después sin romper las funcionalidades existentes. En los últimos 20 años, la complejidad se ha convertido en una ciencia que ha encontrado similitudes en muchos campos diferentes, como las matemáticas, la física y las ciencias sociales. La teoría de la complejidad descubre que cuando existen fuertes dependencias entre componentes, incluso entre componentes simples, se puede experimentar la aparición de comportamientos "complejos" y difíciles de predecir. Por ejemplo, el comportamiento de una hormiga es simple, pero juntas, las hormigas pueden descubrir comida escondida en lugares remotos y llevarla de vuelta a su nido. La aparición de comportamientos inesperados se aplica muy bien al desarrollo de software.

Cuando tienes una gran base de código, requiere mucho esfuerzo reducir los efectos secundarios para no romper otra cosa cuando añades una nueva función. Según mi experiencia, las aplicaciones monolíticas con una gran base de código sólo funcionan cuando hay un pequeño equipo central de desarrolladores que han trabajado durante años en la misma aplicación y han acumulado una gran experiencia en el dominio empresarial. Los microservicios ayudan, pero sigues necesitando conocimientos del dominio empresarial para saber dónde dividir la aplicación. Eso es lo que el diseño orientado al dominio (DDD) llama el "contexto delimitado". Y por eso los microservicios tienen más éxito si se implementan como migración de una aplicación existente que cuando se empieza de cero. Si los límites están bien elegidos y definidos, limitas las dependencias internas para reducir la complejidad general del código y la aparición de problemas inesperados.

Pero aún así, cada microservicio conlleva sus requisitos no funcionales en términos de seguridad, fiabilidad, escalabilidad, observabilidad, rendimiento, etc. La arquitectura sin servidor ayuda a implementar estos requisitos no funcionales de una forma mucho más sencilla. Puede reducir el tamaño total del código utilizando servicios para implementar funcionalidades que no son exclusivas de tu implementación. Te permite centrarte en las funcionalidades que quieres construir y no en gestionar la infraestructura necesaria para ejecutar la aplicación. De este modo, pasar de la idea a la producción es mucho más rápido, y la ventaja de las tecnologías sin servidor no es sólo para los equipos técnicos, sino también para los equipos empresariales, que pueden ofrecer más y más rápido a sus clientes.

P: Como autor del primer libro sobre AWS Lambda, ¿qué ha cambiado en serverless desde tu primera experiencia?

Cuando escribí el libro en 2016, había muy pocas herramientas en torno a AWS Lambda. En algunos ejemplos de mi libro, llamo a funciones Lambda directamente desde el navegador utilizando el SDK de AWS para JavaScript. En cierto modo, eso no me disgusta. Hace que te centres más en las funciones empresariales que necesitas implementar. Además, aunque muchos clientes estaban interesados en AWS Lambda en aquel momento, había muy pocos ejemplos de cargas de trabajo sin servidor en producción.

La idea del libro partió de un taller que creé en el que quería mostrar cómo facilitar la creación de una aplicación. Por ejemplo, empiezo con los datos. ¿Los datos están estructurados? Ponlos en una base de datos totalmente gestionada como Amazon DynamoDB. ¿Son datos no estructurados? Ponlos en un bucket de Amazon S3. ¿Dónde está tu lógica empresarial? Divídela en pequeñas funciones y ejecútalas en AWS Lambda. ¿Pueden esas funciones ejecutarse en un cliente o en un navegador web? Ponlas ahí, y no ejecutes ese código en el backend. Puede que el resultado sea lo que ahora llamamos arquitectura "servicial".

Hoy en día, disponemos de muchas herramientas que permiten crear aplicaciones sin servidor basadas en eventos para administrar eventos (como Amazon EventBridge) o coordinar la ejecución de tu lógica empresarial (como AWS Step Functions). Con mejores herramientas, los clientes construyen ahora aplicaciones más avanzadas. No se trata sólo de funciones sin servidor, como en 2016. Hoy tienes que considerar cómo utilizar las herramientas juntas para crear aplicaciones más rápidamente y tener menos código que mantener.

P: En tu papel de evangelista tecnológico, trabajas con varios equipos. ¿Cómo permite la tecnología sin servidor a equipos de distintos tamaños innovar y crear soluciones más rápidamente?

Los equipos pequeños trabajan mejor. La ausencia de servidor permite a los equipos pequeños hacer más, porque les permite eliminar las partes que pueden ser implementadas por un servicio existente. Les lleva naturalmente a adoptar una arquitectura de microservicios y a utilizar sistemas distribuidos. Puede ser difícil al principio si no tienen experiencia en estos campos, pero es gratificante cuando aprenden y ven los resultados.

Si necesitas hacer un gran cambio en tu forma de crear aplicaciones, por ejemplo, adoptando la tecnología sin servidor o los microservicios, ponte en un lugar donde puedas cometer errores. Es cometiendo errores como aprendemos. A medida que pasas a producción, recopilar métricas sobre la complejidad del código en tu canal de implementación ayuda a mantener el código base bajo control. Para ir un paso más allá, me parece muy interesante la idea de una "función de adecuación" (como se describe en el libro Building Evolutionary Architectures de Rebecca Parsons, Neal Ford y Patrick Kua [O'Reilly]), especialmente si defines "guardarraíles" sobre cuál debe ser la adecuación de tu aplicación.

La automatización ayuda a cualquier escala, pero es increíblemente eficaz para los equipos pequeños. El AWS Well-Architected Framework también ofrece una forma de medir la calidad de tu implementación y proporciona un Serverless Lens con orientación específica.

P: Como plataforma en la nube líder en el desarrollo de aplicaciones sin servidor, ¿qué medidas toma AWS para pensar en el futuro y ofrecer nuevos servicios a sus consumidores?

Empecé en AWS hace más de 10 años. Las cosas eran diferentes entonces. Poner en marcha una instancia EC2 en un par de minutos se consideraba impresionante. Pero aunque haya pasado algún tiempo, en AWS siempre utilizamos el mismo enfoque para crear nuevos servicios y características: escuchamos a nuestros clientes. Nuestra hoja de ruta se basa en un 90 o 95% en lo que nos dicen nuestros clientes. Para el resto, intentamos añadir nuevas ideas a partir de la experiencia que hemos acumulado a lo largo de los años en Amazon y AWS.

Queremos construir herramientas que ayuden a resolver los problemas de los clientes, no cuestiones teóricas. Las construimos de forma que los clientes puedan elegir qué herramientas utilizar. Queremos iterar rápidamente sobre las nuevas ideas y obtener el máximo feedback posible cuando lo hagamos.

P: ¿Qué consejo darías a los lectores que están iniciando su viaje personal u organizativo de adopción de la tecnología sin servidor?

Aprende el modelo mental. No te centres en los detalles de la implementación. Comprende los pros y los contras de utilizar microservicios y arquitecturas distribuidas. El tiempo se vuelve importante porque hay que tener en cuenta la latencia y la concurrencia. Diseña tus sistemas para la comunicación asíncrona y la coherencia final.

Los fallos son una parte natural de cualquier arquitectura. Piensa en tu estrategia para recuperar y gestionar los fallos. ¿Puedes registrar y repetir lo que hace tu aplicación? ¿Pueden los eventos ayudarte a hacerlo? Además, dos requisitos básicos que ahora son más importantes que antes son la observabilidad y la sostenibilidad. Están más relacionados de lo que se podría pensar en un principio.

Descarga las partes que no son exclusivas de tu aplicación en servicios y ofertas SaaS que puedan implementar esas funcionalidades por ti. Céntrate en lo que quieres construir. Es ahí donde puedes marcar una diferencia .

¹ Un módulo es una unidad de software independiente y autónoma.