Introducción a las API´s web y a la arquitectura de microservicios
1. Definición de API. Funcionamiento. Tipos. Protocolos. Ventajas.
Algunos ejemplos
2. API REST. Funcionamiento. Ejemplos de API REST
3. Diferencias entre una Servicio Web SOAP (API SOAP) y una API
REST
4. API RESTful. Diferencias entre REST ful y RESTless
5. Consumir una API REST
6. Arquitectura de microservicios
7. Fuentes y enlaces de interés
1. Definición de API. Funcionamiento. Tipos. Protocolos. Ventajas.
Algunos ejemplos
Una API (Application Programming Interface – Interfaz de Programación de
Aplicaciones) es un conjunto de patrones que forman parte de una interfaz y
que permiten que los desarrolladores puedan crear plataformas de una forma
más sencilla y práctica. Se basan en un conjunto de definiciones y protocolos
que tienen el propósito de integrar sistemas y facilitar la comunicación entre
aplicaciones de software según una serie de reglas.
La transformación digital ha permitido que personas y organizaciones tengan
acceso a miles de aplicaciones e interfaces con el propósito de simplificar sus
rutinas y procesos diarios incluso de forma integrada. LAS API son interfaces
que nos van a permitir integrar sistemas permitiendo que sus funcionalidades
puedan ser reutilizadas por otras aplicaciones o software.
Así una API sirve para intercambiar datos entre diferentes tipos de software y
así automatizar procedimientos y desarrollar nuevas funcionalidades.
¿Cómo funciona? Las APIs están diseñadas para la interacciónentre programas y
aplicaciones así permiten que un sistema de software realice solicitudes a otro
sistema para obtener datos o funcionalidad específica.Una API es una especie
de puente que conecta diversos tipos de software o aplicaciones y puede
crearse en varios lenguajes de programación. Además de un buen desarrollo,
una API debe tener una documentación clara y objetiva para poder facilitar su
implementación. Asimismo, suele utilizarse un formato predefinido de datos
para compartir información entre los sistemas con el objetivo de lograr la
integración entre ellos.
Los más usados son XML (Extensible Markup Language), YAML (originalmente
Yet Another Markup Language, pero oficialmente YAML Ain't Markup Language)
y JSON (JavaScript Object Notation) para las aplicaciones web.
Tipos de API
En lo que se refiere a sus políticas de uso:
1. APIs públicas
Las APIs públicas también son conocidas como API abiertas y están
disponibles para que otros usuarios o desarrolladores las empleen con
mínimas restricciones o, en algunos casos incluso, están totalmente
accesibles.
Algunos ejemplos de API públicas:
Las mejores API públicas para practicas programación.
https://medium.com/@diego.coder/las-mejores-apis-p%C3%BAblicas-
para-practicar-programaci%C3%B3n-a7419ecc968e
2. APIs privadas o internas
Las APIs privadas o internas están ocultas de los usuarios externos y se
exponen únicamente para los sistemas internos de una organización. Se
emplean para el desarrollo interno de la empresa, optimizando la
productividad y la reutilización de servicios.
3. APIs comerciales. No están disponibles para todos, se necesita una
autorización especial para usarlas.
En lo que se refiere a los casos de uso:
1. API de datos
Las APIs de datos proporcionan a varios bancos de datos o proveedores
SaaS (Software as a Service o Software como Servicio) acceso CRUD
(Create, Read, Update, Delete) a conjuntos de datos subyacentes,
permitiendo la comunicación entre una aplicación y un sistema de
gestión de bases de datos.
2. API de sistemas operativos
Este grupo de APIs definen cómo las aplicaciones usan los recursos
disponibles y servicios del sistema operativo. Por lo que cada OS
(Operative System) posee un conjunto de APIs, por ejemplo, Windows API
o Linux API tienen el kernel-user space API y kernel internal API.
3. APIs remotas
Este grupo define los estándares de interacción que las aplicaciones
tienen en diferentes dispositivos, es decir, un software accede a ciertos
recursos ubicados fuera del dispositivo que los solicita, como dice su
nombre. Como dos aplicaciones se conectan de forma remota a través
de una red, las APIs remotas usan protocolos para lograr la conexión.
4. APIs web
Esta clase de API es la más común, dado que las APIs web proporcionan
datos que los dispositivos pueden leer y transferirlos entre sistemas
basados en la web o arquitectura cliente-servidor
Protocolos de API
Los protocolos de API permiten estandarizar el intercambio de datos entre los
diferentes servicios web. Esto brinda la oportunidad de acceder a capacidades
en diversos sistemas, a través de diferentes lenguajes de programación y en
distintos sistemas operativos.
Entre los más importantes se encuentran:
- Remote Procedure Call (RPC)
El llamado de procedimiento remoto o RPC permite que las APIs web puedan
adherirse a los principios de intercambio de recursos. Lo que pretende este
protocolo es definir la interacción entre aplicaciones basadas en un programa
que solicita datos—cliente— y otro que lo proporciona —servidor— de forma
remota.
- Service Object Access Protocol (SOAP)
Es un protocolo realmente ligero para el intercambio de información
estructurada y un ambiente descentralizado y distribuido. Sus especificaciones
contienen las reglas de sintaxis para las solicitudes y respuestas enviadas por
las aplicaciones.
Las aplicaciones que cumplen con estos principios permiten mensajería en XML
entre el sistema a través de HTTP (Hypertext Transfer Protocol) o SMTP (Simple
Mail Transfer Protocol).
- Representational State Transfer (REST)
REST es un estilo de arquitectura de software con seis restricciones para crear
aplicaciones que funcionen sobre HTTP, sobre todo servicios web. Es
considerado como una alternativa de SOAP, dado que múltiples desarrolladores
encuentran dificultades en su uso al tener que escribir grandes cantidades de
código para realizar una tarea. Y, por otro lado, REST sigue otra lógica ya que
facilita la disponibilidad de datos como recursos.
Ventajas de las APIs
Como casi cualquier elemento o solución de la Industria 4.0, las APIs
proporcionan diversos beneficios, entro los que se encuentran:
1. Garantiza mayor flexibilidad en procesos de transferencia de
información.
2. Permite crear capas de aplicaciones con el objetivo de distribuir
información a diferentes audiencias.
3. Permite soluciones personalizadas y diferenciadas según los permitiendo
adaptar protocolos, funciones y comandos según requerimientos
específicos.
4. Al tener contenido que se publica de forma automática y se hace
disponible en diversos canales simultáneamente, las APIs permiten
distribuir más eficientemente los datos.
5. Uno de los grandes beneficios de las APIs es la capacidad que tienen de
adaptarse a cambios a través de la migración de datos y la flexibilidad
de servicios.
Algunos ejemplos de APIs
Google Maps: gracias a los estándares aplicados por Google, la mayoría de los
sitios web pueden usar las APIs de Google Maps para integrar mapas.
Vulcan: esta API multiplataforma permite que los desarrolladores creen
interfaces gráficas en tiempo real y de alta calidad en aplicaciones, brindando
mayor rapidez y eficiencia en la comunicación entre apps y unidades de
procesamiento gráfico.
Skyscanner: esta plataforma de metabúsqueda facilita que viajeros puedan
encontrar mejores tarifas para sus vuelos. Además, proporciona una API para
aliados comerciales compatible con XML y JSON para el intercambio de datos.
Weather API: un proveedor de servicios de geolocalización e información
meteorológica con diversas APIs que van desde el pronóstico del clima, hasta
búsquedas de zonas horarias, astronomía y más.
Otros ejemplos de APIs son las APIs de redes sociales (por ejemplo, la API de
Twitter), las APIs de pasarelas de pago (por ejemplo, la API de PayPal) y las APIs
de servicios en la nube (por ejemplo, la API de AWS). Las APIs para pagos se
suelen integrar dentro del sitio web o la app con la intención de ampliar los
métodos de pago para productos y servicios. Las Redes sociales utilizan APIs
para enriquecer la experiencia del usuario e incorporar funcionalidades para
obtener información sobre los visitantes o crear usuarios o perfiles desde
cuentas de Facebook, Google, entre otros.
2. API REST. Funcionamiento. Ejemplos de API REST
Una API REST es una API web basadas en REST (REpresentational State
Transfer), un sistema estilo arquitectónico para los servicios de internet que se
ajusta a las necesidades de las aplicaciones móviles y los servicios web ligeros.
Dado que se trata de un conjunto de pautas, la implementación de las
recomendaciones depende de los desarrolladores.
Así, una API REST será la API que se adapta a los límites de la arquitectura
REST.
Entre las reglas de una arquitectura REST se encuentran:
- Una arquitectura cliente-servidor compuesta por clientes, servidores y
recursos.
- Interfaz uniforme. La interfaz se basa en recursos, el interior de la base de
datos es transparente para el cliente. Al haber un único identificador de recurso
uniforme (URI) por recurso, es más fiable y la información es transferida de
forma estandarizada.
- Peticiones sin estado. Cada solicitud debe incluir toda la información necesaria
para procesarla y la comunicación cliente-servidor es sin estado. Esto significa
que el contenido de los clientes no se almacena en el servidor entre las
solicitudes.
- Cacheable. Los datos pueden almacenarse en caché para eliminar la
necesidad de algunas interacciones cliente-servidor.
- Separación de cliente y servidor. La interfaz hace de nexo entre cliente y
servidor porque las aplicaciones de cliente y servidor deben ser completamente
independientes entre sí.
- Sistema de Capas. El cliente no sabe si está conectado al servidor o a un
intermediario (es irrelevante) ya que las interacciones cliente-servidor están
mediadas por capas jerárquicas.
Funcionamiento de una API REST
Cuando se envía una solicitud de datos a una API de REST se suele hacer a
través de un protocolo de transferencia de hipertexto, comúnmente
denominado HTTP. Una vez que reciben la solicitud, las API diseñadas para
REST pueden devolver mensajes en distintos formatos: HTML, XML, texto sin
formato y JSON. El formato preferido para los mensajes es la notación de
objetos JavaScript (JSON), ya que, a pesar de su nombre, puede leerlo cualquier
lenguaje de programación, es ligero y lo comprenden tanto las personas como
las máquinas.
Ejemplos de API REST
- Google Translate o DeepL disponen de API REST para poder embeberlas
dentro de una web, una app o un servicio. Esto es clave en empresas con
clientes en países con otro idioma.
- Instagram, Facebook, WhatsApp (META) son reds sociales que disponen de
varias API REST con la que se pueden recuperar cuentas de usuarios, fotos o
etiquetas en Instagram. También es posible leer los 'me gusta' públicos o usar
la API para crear mapas de relaciones, muy útil en estudios sociológicos o sobre
burbuja mediáticas tanto en Instagram como Facebook. En WhatsApp Business
es posible utilizar la API para generar registros de clientes.
- Con la API REST de GitHub es posible, entre otros aspectos, rastrear la
actividad del usuario, seguir los problemas o crear repositorios. Quizá uno de
los puntos fuertes de este repositorio sea cómo la comunidad ha confeccionado
guías de uso para las API, incluida una guía de inicio rápido. Dado que esta
reserva de código es de las más grandes del planeta, conviene vigilarla desde
el punto de vista empresarial.
-La API REST de Wikipedia puede ser particularmente útil para empresas de
cierto tamaño, ya que es posible automatizar envíos de actualizaciones de las
páginas, entre otros usos. Con ella es posible estar informados sobre el impacto
de nuestra marca dentro de la gran enciclopedia y subsanar errores.
- Muchas empresas necesitan datos sobre el pronóstico del tiempo (reparto
urbano para predecir atascos, empresas de aventura en exterior, restaurantes
terraza). Weatherstack dispone de API REST para realizar prospecciones a
medio plazo, o lecturas en tiempo real.
Pruebas de APIs
Para hacer pruebas con estas APIs podemos implementar el código para
consumirlas o utilizar un cliente especial para el consumo de stos servicios
como PostMan, Thunder Client, Insomnia o Advance REST Client
3. Diferencias entre una Servicio Web SOAP (API SOAP) y una API
REST
Ambos son servicios web, la diferencia está en que SOAP es un protocolo para
los servicios web (protocolo simple de acceso a objetos) y REST es un estilo
arquitectónico. REST y SOAP son, por tanto, dos enfoques distintos para la
transmisión de datos en línea. Específicamente, ambos definen cómo diseñar
interfaces de programación de aplicaciones (API), las cuales permiten la
comunicación de datos entre aplicaciones web. Por lo general, alguno de los dos
regirá a las API, según el caso práctico y las preferencias del desarrollador.
Dado que REST es un conjunto de principios arquitectónicos y no un protocolo
las API de REST son más flexibles, ligeras y se pueden configurar con mayor
facilidad que las de SOAP, pues estas últimas constituyen un protocolo estándar
oficial cuyo mantenimiento está a cargo del Consorcio World Wide Web (W3C).
SOAP se creó originalmente para posibilitar la comunicación entre las
aplicaciones que se diseñaban con diferentes lenguajes y en distintas
plataformas. Como es un protocolo impone reglas integradas que aumentan la
complejidad y la sobrecarga, lo cual puede retrasar el tiempo que tardan las
páginas en cargarse. Sin embargo, estos estándares también ofrecen normas
integradas que pueden ser ideales para el sector empresarial. Los estándares
de cumplimiento integrados incluyen la seguridad, la atomicidad, la
uniformidad, el aislamiento y la durabilidad (ACID), que forman un conjunto de
propiedades que garantizan operaciones confiables de las bases de datos.
Así las especificaciones comunes de los servicios web SOAP incluyen:
- Seguridad de los servicios web (WS-Security): estandariza la forma de
proteger y transferir los mensajes usando identificadores únicos
llamados tokens.
- Mensajería segura de los servicios web (WS-ReliableMessaging):
estandariza el control de errores entre mensajes que se transfieren en
infraestructuras de TI poco confiables.
- Abordaje de los servicios web (WS-Addressing): paquetes que enrutan la
información como metadatos dentro de los encabezados SOAP
- Lenguaje de descripción de los servicios web (WSDL): describe qué hace
un servicio web, así como dónde comienza y termina.
El envío de una solicitud de datos a una API de SOAP se puede administrar a
través de cualquiera de los protocolos de la capa de la aplicación: HTTP (para
los exploradores web), SMTP (para el correo electrónico), TCP, entre otros. Sin
embargo, una vez que se recibe una solicitud, los mensajes SOAP de retorno
deben ser documentos XML.
Es posible que muchos sistemas heredados sigan rigiéndose por SOAP, aunque
REST haya surgido más tarde y se considere una alternativa más rápida en los
escenarios basados en la Web. Al ser más ligeras las API REST resultan ideales
para los contextos más nuevos como el Internet de las cosas (IoT), el desarrollo
de aplicaciones móviles y la informática sin servidor. Asimismo, muchas API
públicas, como la API de Google Maps, siguen las pautas de REST.
Por su parte los servicios web de SOAP ofrecen seguridad y ofrecen operaciones
integradas que coinciden con muchas de las necesidades empresariales por lo
que son interesantes para muchas empresas a pesar de ser más pesados y
menos flexibles.
4. API RESTful. Diferencia entre API REST ful y REST less
Dentro de las API REST existen las REST ful. Una API RESTful es una API REST
que usa métodos HTTP como GET, POST, PUT y DELETE para transmitir servicios
web a través del protocolo HTTP.
GET. Solicita un recurso en la URL de la solicitud. Se usa para consultar
información.
POST. Envía información al servicio para su procesamiento, creando un nuevo
registro.
PUT. Actualiza un registro o recurso existente.
DELETE. Elimina un registro existente.
Puedes consultar el siguiente enlace para ver las diferencias entre una API REST
y una API RESTful:
https://youtu.be/JD6VNRdGl98?si=sXsEEXrUiJGe0e4u
5.Consumir una API REST
Una API se puede consumir de formas diferentes:
Front - End: Desde el cliente (Programacion Asíncrona con AJAX)
Back - End: Desde el Servidor
Híbrido: uso mixto según necesidades
Cada URL/URI ofrece una funcionalidad concreta, unos parámetros de entrada y
una salida (recurso de respuesta)
Consumir el API significa:
- Consultar el recurso (con cualquier Cliente Web (y herramientas)) (a
veces auténticándose)
- Ver la respuesta. Una vez devuelta, el API se olvida del cliente
(arquitectura sin estado)
- Autenticación en APIs REST (necesitas consultar la documentación
particular):
Pública: sin autenticación
Autenticación HTTP: basado en credenciales usuario/contraseña con
métodos HTTP (básica / digest).
Basada en claves de acceso (tokens). Por ejemplo Autenticación en
OpenWeather
Con clave de acceso específica
Uso de Autenticación (API) de terceros: OAuth por ejemplo Autenticación
con Youtube
Podemos realizar ejemplos de consumo con la API públicas de Chuck
Norris Jokes (chistes en categorías) Podemos:
- Consulta de un chiste aleatorio
- Consulta un chiste aleatorio pero de una categoría concreta
- Consulta las diferentes categorías disponibles
- Consulta los chistes que contengan la palabra «spain»
Una API REST ful cumple complétamente todos los criterios REST. Una API REST
less no.
6. Arquitectura de microservicios. Ejemplos
Algunas de las arquitecturas de microservicios más innovadoras y rentables
entre las empresas del mundo (como Amazon, Netflix, Uber y Etsy) atribuyen el
enorme éxito de sus iniciativas de TI en parte a la adopción de microservicios.
Con el tiempo, estas empresas desmantelaron sus aplicaciones monolíticas y
luego las refactorizaron en arquitecturas basadas en microservicios para lograr
rápidamente ventajas de escalabilidad, mayor agilidad empresarial y ganancias
inimaginables.
Los microservicios son un enfoque para crear aplicaciones que constan de
múltiples servicios pequeños e independientes. Empresas como Amazon,
Netflix, Uber y Etsy han adoptado microservicios para lograr ventajas de
escalabilidad, agilidad comercial y rentabilidad.Los microservicios ofrecen
beneficios como agilidad, conectabilidad, escalabilidad y la capacidad de
adaptarse a los requisitos comerciales cambiantes.
¿Qué son los microservicios?
La mejor manera de presentar este concepto es citar a James Lewes y Martin
Fowler, quienes desempeñaron un papel clave en la promoción de los
microservicios como estilo arquitectónico. Su prestigioso artículo titulado
"Microservicios" define los microservicios como un enfoque para crear una
única aplicación que consta de múltiples servicios pequeños que funcionan de
forma independiente, cada uno de los cuales se ejecuta en su propio proceso y
se comunica mediante mecanismos ligeros como las API de recursos HTTP.
Estos servicios están diseñados en torno a capacidades empresariales
específicas y se pueden implementar de forma independiente mediante
herramientas de implementación totalmente automatizadas. Existe una gestión
centralizada mínima de estos servicios, que se pueden escribir en diferentes
lenguajes de programación y utilizar varias tecnologías de almacenamiento de
datos.
Por ejemplo, los microservicios en Java hacen referencia a un patrón de
arquitectura de software en el que una aplicación se crea como una colección
de servicios pequeños, independientes y débilmente acoplados que trabajan
juntos para proporcionar una funcionalidad completa. Cada microservicio es un
componente independiente que se puede desarrollar, implementar y escalar de
forma independiente, lo que permite una mayor flexibilidad y escalabilidad en
aplicaciones a gran escala.
En el contexto de Java, los microservicios se implementan normalmente
mediante marcos y herramientas que respaldan el desarrollo de sistemas
distribuidos. Algunos marcos populares basados en Java para crear
microservicios incluyen Spring Boot, Dropwizard y Micronaut. Estos marcos
proporcionan las abstracciones y utilidades necesarias para simplificar el
desarrollo, la implementación y la gestión de microservicios.
Características y principios clave asociados con los microservicios:
- Independencia del servicio: cada microservicio es una unidad autónoma
con su propia funcionalidad empresarial, base de datos y mecanismos de
comunicación dedicados. Esta independencia permite que los equipos
trabajen en diferentes microservicios simultáneamente sin interferir
entre sí.
- Comunicación ligera: los microservicios se comunican entre sí mediante
protocolos ligeros como REST (Representational State Transfer) o
sistemas de mensajería como RabbitMQ o Apache Kafka. Esto permite
que los servicios se implementen y escalen de forma independiente, sin
un acoplamiento estricto.
- Escalabilidad y resiliencia: los microservicios permiten un escalamiento
horizontal, en el que los servicios individuales se pueden replicar y
distribuir entre varios servidores para gestionar una mayor carga. Este
enfoque mejora la resiliencia del sistema en general y garantiza una alta
disponibilidad.
- Persistencia políglota: los microservicios brindan a los desarrolladores la
flexibilidad de elegir diferentes tipos de bases de datos o tecnologías de
almacenamiento de datos que mejor se adapten a los requisitos de cada
servicio. Esto permite el uso de diferentes bases de datos (SQL, NoSQL,
etc.) dentro de la misma aplicación.
- Entrega continua y DevOps: los microservicios promueven la adopción de
prácticas de DevOps, lo que permite a los equipos desarrollar, probar e
implementar servicios de forma independiente. Las canalizaciones de
integración continua y despliegue continuo (CI/CD) se utilizan
comúnmente para automatizar el despliegue y la gestión de
microservicios.
Así, Los microservicios ofrecen un enfoque modular y escalable para desarrollar
aplicaciones complejas al dividirlas en componentes más pequeños y
manejables. Este estilo arquitectónico fomenta la flexibilidad, la resiliencia y la
capacidad de adaptarse a los requisitos empresariales cambiantes.
¿Por qué las empresas adoptan la arquitectura de microservicios?
Algunas de las empresas más innovadoras y rentables del mundo (como
Amazon, Netflix, Uber y Etsy) atribuyen el enorme éxito de sus iniciativas de TI
en parte a la adopción de microservicios. Con el tiempo, estas empresas
desmantelaron sus aplicaciones monolíticas y las refactorizaron en
arquitecturas basadas en microservicios. Esto ayudó a lograr rápidamente
ventajas de escalabilidad, mayor agilidad empresarial y ganancias
inimaginables.
Construyendo una arquitectura de microservicios
Los desarrolladores pueden optar por dividir la funcionalidad de un monolito en
pequeños microservicios que se ejecutan de forma independiente. Los
microservicios se conectan libremente a través de API para formar una
arquitectura de aplicación basada en microservicios. La arquitectura de
microservicios ofrece mayor agilidad y capacidad de conexión porque las
empresas pueden desarrollar, implementar y escalar de forma independiente
cada microservicio. Pueden hacer esto sin incurrir necesariamente en
interrupciones del servicio, lo que afecta negativamente a otras partes de la
aplicación o la necesidad de refactorizar otros microservicios. El proceso es más
simple y, cuando es necesario ajustar o actualizar una parte de la aplicación,
esto se puede hacer sin afectar todo lo demás.
Muchas empresas ahora diseñan su arquitectura de microservicios desde el
principio.
Estos son los pasos para diseñar una arquitectura de microservicios :
1. Entender el monolito
Estudie el funcionamiento del monolito y determine las funciones y servicios
que realiza. Dado que todas las funciones se mezclarán, esto puede suponer un
desafío. Es una parte importante de la determinación de lo que se necesita para
los microservicios, por lo que debería ser lo primero en lo que se centren los
desarrolladores.
2. Desarrollar los microservicios
Desarrollar cada función de la aplicación como un microservicio autónomo que
se ejecuta de forma independiente. Estos suelen ejecutarse en un contenedor
en un servidor en la nube. Cada microservicio responde a una única función:
búsqueda, envío, pago, contabilidad, nómina, etc. Esto permite realizar cambios
menores sin interrumpir los demás procesos.
3. Integrar la aplicación más grande
Integrar de forma flexible los microservicios a través de puertas de enlace de
API, de modo que trabajen en conjunto para formar la aplicación más grande.
Una iPaaS como DreamFactory puede desempeñar un papel esencial en este
paso. Cada microservicio trabajará con los demás para proporcionar las
funciones necesarias. Cada sección se puede ajustar, adaptar o incluso eliminar
sin demasiado impacto en las otras partes de la aplicación.
4. Asignar recursos del sistema
Utilice herramientas de orquestación de contenedores como Kubernetes para
administrar la asignación de recursos del sistema para cada microservicio. Este
paso ayuda a mantener todo organizado y garantiza que todo el sistema
funcione como un todo.
Ejemplos de microservicios:
Las empresas que se muestran a continuación utilizaron microservicios para
resolver desafíos clave de escalabilidad y procesamiento de servidores.
1. Amazon
Amazon es conocido como un gigante del comercio minorista en Internet, pero
no empezó así. A principios de la década de 2000, el sitio web de venta
minorista de Amazon se comportaba como una única aplicación monolítica.
Las estrechas conexiones entre los servicios de múltiples niveles que
componían el monolito de Amazon y dentro de ellos implicaban que los
desarrolladores tenían que desenredar cuidadosamente las dependencias cada
vez que querían actualizar o escalar los sistemas de Amazon. Era un proceso
minucioso que costaba mucho dinero y requería tiempo para adaptarse.
Anteriormente, Amazon había descubierto que la estructura monolítica
funcionaba muy bien. Sin embargo, la base de código se expandió rápidamente
a medida que más desarrolladores se sumaban al equipo. Había demasiadas
actualizaciones y proyectos entrantes, lo que tuvo un impacto negativo en el
desarrollo y el funcionamiento del software. Con caídas tan evidentes en la
productividad, era necesario buscar una mejor manera de hacer las cosas.
En 2001, los retrasos en el desarrollo, los desafíos de codificación y las
interdependencias de los servicios inhibieron la capacidad de Amazon para
satisfacer los requisitos de escalabilidad de su creciente base de clientes. La
empresa y su sitio estaban en pleno auge, pero no había forma de seguir el
ritmo del crecimiento.
Ante la necesidad de refactorizar su sistema desde cero, Amazon dividió sus
aplicaciones monolíticas en pequeñas aplicaciones independientes y específicas
para cada servicio. El uso de microservicios cambió de inmediato el modo de
trabajar de la empresa. Pudo cambiar funciones y recursos individuales, lo que
produjo mejoras masivas e inmediatas en la funcionalidad del sitio.
Así es como lo hizo Amazon:
Los desarrolladores analizaron el código fuente y extrajeron las unidades de
código que cumplían una función única. Como era de esperar, este fue un
proceso que llevó mucho tiempo, ya que todo el código estaba mezclado y las
distintas funciones del sitio estaban entrelazadas. Sin embargo, los
desarrolladores trabajaron arduamente para ordenarlo y determinar qué
secciones se podían convertir en microservicios.
Una vez que tuvieron las secciones de código separadas, los desarrolladores
envolvieron estas unidades en una interfaz de servicio web. Por ejemplo,
desarrollaron un servicio único para el botón Comprar en una página de
producto, un servicio único para la función de calculadora de impuestos, etc.
Cada función tenía su propia sección.
Amazon asignó la propiedad de cada servicio independiente a un equipo de
desarrolladores, lo que les permitió ver los cuellos de botella del desarrollo de
manera más granular. Podían resolver los desafíos de manera más eficiente, ya
que un pequeño número de desarrolladores podía concentrar toda su atención
en un solo servicio. Ese servicio en particular tampoco afectaría a todo lo
demás, por lo que era más fácil trabajar en él.
La “arquitectura orientada a servicios” de Amazon fue en gran medida el
comienzo de lo que ahora llamamos microservicios. Llevó a Amazon a
desarrollar una serie de soluciones para respaldar las arquitecturas de
microservicios , como Amazon AWS y Apollo, que actualmente vende a
empresas de todo el mundo. Sin su transición a los microservicios, Amazon no
podría haber crecido hasta convertirse en la empresa más valiosa del mundo,
valorada por capitalización de mercado en 1,6 billones de dólares al 1 de agosto
de 2022 .
2. Netflix
Amazon no fue la única empresa pionera en el mundo de los microservicios.
Netflix es otra empresa que ha alcanzado el éxito gracias al uso de
microservicios conectados con API.
Al igual que Amazon, este ejemplo de microservicios comenzó su andadura en
2008, antes de que el término "microservicios" se pusiera de moda. Netflix
inició su servicio de transmisión de películas en 2007. En 2008, sufría cortes de
servicio y problemas de escalabilidad; durante tres días, no pudo enviar DVD a
sus miembros.
En ese momento, la empresa todavía trabajaba con DVD físicos, lo que frenaba
su capacidad para atender a sus clientes. El streaming seguía siendo un sueño
y el negocio online, aunque florecía, era difícil. El diseño monolítico todavía no
era muy funcional más allá de cierto punto. La arquitectura de microservicios
era una opción mucho mejor, pero todavía no existía realmente.
Según un vicepresidente de Netflix :
" Nuestro viaje a la nube en Netflix comenzó en agosto de 2008, cuando
sufrimos una importante corrupción en la base de datos y durante tres días no
pudimos enviar DVD a nuestros miembros. Fue entonces cuando nos dimos
cuenta de que teníamos que alejarnos de los puntos de falla únicos escalados
verticalmente, como las bases de datos relacionales en nuestro centro de
datos, y avanzar hacia sistemas distribuidos, escalables horizontalmente y
altamente confiables en la nube. Elegimos a Amazon Web Services (AWS) como
nuestro proveedor de nube porque nos brindaba la mayor escala y el conjunto
más amplio de servicios y funciones".
En 2009, Netflix inició el proceso gradual de refactorización de su arquitectura
monolítica, servicio por servicio, en microservicios. El primer paso fue migrar su
plataforma de codificación de películas, que no estaba orientada al cliente, para
que funcionara en servidores en la nube de Amazon AWS como un microservicio
independiente. Netflix pasó los dos años siguientes convirtiendo sus sistemas
orientados al cliente en microservicios, y finalizó el proceso en 2012.
El primer paso fue migrar su plataforma de codificación de películas, que no
estaba orientada al cliente, para que funcionara en servidores en la nube de
Amazon AWS como un microservicio independiente. Netflix pasó los dos años
siguientes convirtiendo sus sistemas orientados al cliente en microservicios y
finalizó el proceso en 2012.
La refactorización de los microservicios le permitió a Netflix superar sus
desafíos de escalabilidad y las interrupciones del servicio. En 2013, la puerta de
enlace de API de Netflix manejaba dos mil millones de solicitudes de API
diarias , administradas por más de 500 microservicios alojados en la nube. En
2017, su arquitectura consistía en más de 700 microservicios acoplados de
forma flexible. Hoy, Netflix genera alrededor de 8 mil millones de dólares al año
y transmite aproximadamente seis mil millones de horas de contenido
semanalmente a más de 220 millones de suscriptores en 190 países, y continúa
creciendo.
Netflix recibió otro beneficio de los microservicios: reducción de costos. Según
la empresa, sus “ costos en la nube por inicio de transmisión terminaron siendo
una fracción de los del centro de datos, un beneficio adicional bienvenido”. La
empresa también ha sido responsable de las medidas enérgicas contra las VPN
y los servidores proxy en todo el mundo. Impidió que los usuarios vieran
contenido a través de servidores proxy, a pesar de que el servicio de
transmisión estaba disponible en todo el mundo. También es responsable de
cambiar la forma en que la gente ve programas de televisión. En estos días,
tienes que suscribirte a un sitio específico para recibir los programas que
quieres, gracias a que Netflix inició las guerras del streaming. La arquitectura
de microservicios está detrás de todo.
3. Uber
A pesar de haberse presentado al mundo más recientemente que cualquiera de
nuestros ejemplos anteriores, Uber también comenzó con un diseño monolítico.
Este ejemplo de microservicio surgió poco después del lanzamiento de Uber,
cuando el servicio de viajes compartidos se topó con obstáculos de crecimiento
relacionados con su estructura de aplicación monolítica. La plataforma tuvo
dificultades para desarrollar y lanzar nuevas funciones de manera eficiente,
corregir errores e integrar sus operaciones globales en rápido crecimiento.
Además, la complejidad de la arquitectura de aplicación monolítica de Uber
requiere que los desarrolladores tengan una amplia experiencia trabajando con
el sistema existente solo para realizar actualizaciones y cambios menores en el
sistema.
Así funcionaba la estructura monolítica de Uber en aquel momento:
- Pasajeros y conductores conectados al monolito de Uber a través de una
API REST.
- Había tres adaptadores, con API incorporada para funciones como
facturación, pago y mensajes de texto.
- Había una base de datos MySQL.
Todas las características estaban contenidas en el monolito.
Este diseño era complicado y era difícil realizar cambios en él. Para los
desarrolladores, la popularidad de la aplicación de viajes compartidos causó
problemas casi de inmediato. La empresa creció demasiado rápido como para
seguir el ritmo del diseño original de la aplicación.
Para superar los desafíos de la estructura de su aplicación existente, Uber
decidió dividir el monolito en microservicios basados en la nube.
Posteriormente, los desarrolladores crearon microservicios individuales para
funciones como gestión de pasajeros, gestión de viajes y más. De manera
similar al ejemplo de Netflix mencionado anteriormente, Uber conectó sus
microservicios a través de una puerta de enlace API.
En este caso, los cambios fueron más rápidos, ya que se realizaron en una
etapa anterior de la empresa. Se mezclaron menos funciones en el diseño
monolítico, lo que facilitó la modificación de elementos cuando llegó el
momento de hacerlo.
El cambio a este estilo arquitectónico le trajo a Uber innumerables beneficios.
En primer lugar, los desarrolladores se dividieron en equipos específicos que
debían centrarse en un servicio a la vez. Esto garantizó que se convirtieran en
expertos en su servicio en particular. Cuando había un problema, podían
solucionarlo más rápido y sin afectar las otras áreas de servicio. La velocidad, la
calidad y la capacidad de gestión del nuevo desarrollo mejoraron de inmediato.
A medida que Uber comenzó a crecer a una velocidad exponencial, la
escalabilidad rápida se hizo más fácil. Los equipos podían centrarse solo en los
servicios que necesitaban escalar y dejar el resto en paz. Gracias a la
arquitectura de microservicios , todo funcionó de esta manera sin problemas.
Actualizar un servicio no afectó a los demás. La empresa también logró una
tolerancia a fallas más confiable.Sin embargo, había un problema. La simple
refactorización del monolito en microservicios no fue el final del viaje de Uber.
Según la ingeniera de confiabilidad del sitio de Uber, Susan Fowler, la red de
microservicios necesitaba una estrategia de estandarización clara, o correría el
riesgo de " salirse de control ".
Fowler dijo que el primer enfoque de Uber para la estandarización fue crear
estándares locales para cada microservicio. Esto funcionó bien, al principio,
para ayudar a poner en marcha los microservicios, pero Uber descubrió que los
microservicios individuales no siempre podían confiar en la disponibilidad de
otros microservicios en la arquitectura debido a las diferencias en los
estándares. Si los desarrolladores cambiaban un microservicio, generalmente
tenían que cambiar los demás para evitar interrupciones del servicio. Esto
interfería con la escalabilidad porque era imposible coordinar nuevos
estándares para todos los microservicios después de un cambio.
Al final, Uber decidió desarrollar estándares globales para todos los
microservicios, lo que una vez más cambió todo para la empresa.
En primer lugar, analizaron los principios que daban como resultado la
disponibilidad, como la tolerancia a fallos, la documentación, el rendimiento, la
fiabilidad, la estabilidad y la escalabilidad. Una vez que los identificaron,
comenzaron a establecer estándares cuantificables. Estos eran medibles y
estaban diseñados para ser seguidos. Por ejemplo, los desarrolladores podían
observar métricas empresariales, incluidas las visitas a páginas web y las
búsquedas.
Finalmente, convirtieron las métricas en solicitudes por segundo en un
microservicio. Si bien no fue un cambio rápido, fue muy necesario. Uber parecía
estar creciendo por fuera, pero había una verdadera lucha por dentro para
mantenerlo en un estado de crecimiento sin interrupciones ni deficiencias en el
servicio.
7. Fuentes y enlaces de interés
¿Qué es una API REST?
https://blog.hubspot.es/website/que-es-api-rest
¿Qué es una API REST ful?
https://aws.amazon.com/es/what-is/restful-api/
Microservicios Examples: Amazon, Netflix, Uber.
https://blog/dreamfactory.com
API web, servicios web y microservicios: conceptos básicos y diferencias.
https://es.parasoft.com/blog/web-api-vs-web-services-microservices-basics-
differences/
