¿Qué son los microservicios?

Los microservicios son tanto un estilo de arquitectura como un modo de programar software.
Con los microservicios, las aplicaciones se dividen en sus elementos más pequeños e
independientes entre sí. A diferencia del enfoque tradicional y monolítico de las aplicaciones,
en el que todo se compila en una sola pieza, los microservicios son elementos independientes
que funcionan en conjunto para llevar a cabo las mismas tareas. Cada uno de esos elementos o
procesos es un microservicio. Este enfoque de desarrollo de software valora el nivel de detalle,
la sencillez y la capacidad para compartir un proceso similar en varias aplicaciones. Es un
elemento fundamental de la optimización del desarrollo de aplicaciones hacia un modelo
nativo de la nube.
Sin embargo, el mayor interrogante es cuáles son las ventajas de utilizar una infraestructura
de microservicios. En pocas palabras, el objetivo es distribuir software de calidad con mayor
rapidez. Si bien esto se puede lograr con los microservicios, se deben considerar otras
cuestiones. Dividir las aplicaciones en microservicios no es suficiente; es necesario
administrarlos, coordinarlos y gestionar los datos que crean y modifican.

¿Para qué sirven los microservicios?

Es más fácil diseñar, probar, implementar y actualizar microservicios que aplicaciones

monolíticas. Red Hat considera que esto responde a la pregunta "¿cómo logro que mi empresa
reaccione más rápido ante las demandas nuevas, en lugar de tener que esperar la cantidad de
años que supone el desarrollo tradicional de software?". En la actualidad, las distintas partes
del equipo de desarrollo pueden trabajar simultáneamente en los productos de un modo ágil
para ofrecer beneficios a los clientes de inmediato.
Conozca los aspectos fundamentales de los microservicios y las ventajas y desventajas de
utilizarlos, eche un vistazo a nuestras opciones de capacitación por solicitud e infórmese sobre
cómo diseñar una arquitectura basada en microservicios.

¿Cuál es la relación con los contenedores de Linux?

Los contenedores de Linux brindan a las aplicaciones basadas en microservicios una unidad
ideal de implementación de aplicaciones y un entorno de ejecución autónomo. Además, los
microservicios organizados en contenedores permiten aprovechar mejor el sistema de
hardware y facilitan la coordinación de los servicios, entre los cuales se incluyen el
almacenamiento, la conexión de red y la seguridad.
Por eso, la fundación Cloud Native Computing Foundation afirma que los microservicios y los
contenedores conforman, en conjunto, la base para desarrollar aplicaciones originales de la
nube. Este modelo agiliza el desarrollo y facilita la transformación y la optimización de las
aplicaciones actuales, y todo comienza con los microservicios en contenedores.
¿Qué beneficios aportan los microservicios a la integración de las aplicaciones?
Para que el funcionamiento de la arquitectura de microservicios sea similar al de
una aplicación funcional de la nube, los servicios deben solicitar datos a los demás servicios
constantemente a través de la mensajería. Al desarrollar una malla de servicios en una
aplicación, se simplifica la comunicación entre ellos. Sin embargo, es posible que también
deba integrar la arquitectura de microservicios con sus aplicaciones heredadas y demás
fuentes de datos.
Si cuenta con una arquitectura distribuida, pero aún depende de un equipo centralizado que
administra tecnologías de este tipo, como un bus de servicios empresariales (ESB), para
realizar la integración, se podrían anular los objetivos comerciales de los microservicios.
La integración ágil es un enfoque de conexión de los recursos que combina tecnologías de
integración, técnicas de distribución ágil y plataformas originales de la nube para distribuir
sistemas de software con mayor velocidad y seguridad.

¿Por qué elegir Red Hat para los microservicios?

Red Hat no solo le permite dividir sus aplicaciones monolíticas en microservicios, sino que
también lo ayuda a administrarlos y organizarlos, así como a gestionar los datos que ellos
generan y modifican. Respaldamos la implementación y el desarrollo continuos de los
microservicios y lo ayudamos a integrarlos y gestionarlos. El resultado es una solución de
microservicios que admite la implementación del código durante todo el proceso, y fomenta la
comunicación y la colaboración entre los equipos de distribución. No es necesario renovar por
completo los sistemas actuales para obtener beneficios importantes. Gracias a la tecnología
open source, los estándares abiertos y nuestros años de experiencia, podemos ayudarlo a
encontrar una solución adecuada para su empresa.

Las razones que residen tras la aparición de arquitecturas basadas en microservicios son
diversas. En primer lugar, se puede decir que los microservicios y la arquitectura orientada a
servicios (o SOA) incluso luchan cuando se trata de desacoplar las funciones comerciales de
los sistemas de información ejecutiva (SIE) para una gestión descentralizada.
Por otro lado, la implementación y la práctica de SOA se volvieron demasiado complejas, y se
requería de una nueva forma de hacer las cosas más directas y menos normativas.
Permitiendo así la elección entre diversas técnicas de administración para sacar un mayor
provecho.

¿Qué son los microservicios?

Un microservicio es un servicio (en el sentido de SOA) que nunca comparte su contexto de
ejecución con otros microservicios, sino que puede comunicarse con ellos. La arquitectura en
la que se basan éstos no es SOA, pues los microservicios son un caso especial de servicios: son
servicios pequeños y autónomos que trabajan juntos. A lo largo de los años, las arquitecturas
basadas en los principios de SOA se han vuelto tan complejas como las arquitecturas
monolíticas que se suponía que debían reemplazar y superar. Los microservicios asumen que
un servicio debe hacer una cosa y hacerlo bien. Este principio no es nuevo, ya que es el que
subyace en el desarrollo de UNIX desde el principio: hacer las cosas bien y mantenerlas
simples. La arquitectura de microservicio establece principios arquitectónicos, indicando
soluciones posibles y prácticas para la mayoría de los problemas.
Arquitectura de microservicios
A la mayoría les sorprende que uno de los principios básicos de una arquitectura de
microservicios es la falta de una base de datos compartida. Un microservicio se basa en un
sistema de persistencia que será el único para administrar y usar, en caso de que necesite
hacer un estado persistente o almacenar datos externos. La arquitectura de microservicios
elimina el acoplamiento entre servicios a través de esquemas de base de datos. El único que
debe contener semántica es la API de servicios. No es el esquema de una tabla. Esto también
evita el acoplamiento entre los equipos. Por otro lado, la partición del espacio de datos de la
empresa de esta manera hace que sea necesario confrontar las actualizaciones de datos para
evitar inconsistencias. Una solución es implementar un programa de gestión de datos maestros
(MDM). La ejecución será por naturaleza compartida entre todas las bases de datos, lo que va
en contra de los principios ontológicos de la arquitectura. Además evita tener que realizar una
limpieza y verificación de datos asegurándose de que nunca se produzcan errores de
actualización. Es responsabilidad del equipo a cargo del ciclo de vida del microservicio tomar
la decisión de seleccionar las tecnologías de implementación. Otra consecuencia de la
arquitectura de microservicios es que el equipo es responsable de su servicio durante todo su
ciclo de vida. Esto significa que el equipo especifica, diseña, implementa, prueba, integra,
implementa el servicio, pero lo más importante, proporciona soporte y mantenimiento al
usuario.

¿Qué es una API? (Interfaz de programación de aplicaciones)

API es el acrónimo en inglés de "interfaz de programación de aplicaciones", un software

intermediario que permite que las aplicaciones se comuniquen entre sí. Cada vez que se usa una
aplicación como Facebook, se envía un mensaje instantáneo o se mira el pronóstico del tiempo en el
teléfono, se utiliza una API.

¿Qué sería un ejemplo de una API?

Cuando se utiliza una aplicación en un teléfono móvil, la aplicación se conecta a Internet y

envía datos a un servidor. El servidor, a continuación, recupera los datos, los interpreta,
realiza las acciones necesarias y los envía de vuelta al teléfono móvil. La aplicación interpreta
entonces los datos y presenta la información deseada de manera legible. Todo ello sucede a
través de una API.
Para explicar mejor este proceso, veamos un ejemplo de la vida cotidiana.
Imagina que estás en un restaurante y tienes todo un menú para elegir. La cocina es la parte
del "sistema" que prepara tu pedido. El elemento que falta es el enlace esencial que comunica
tu pedido a la cocina y te lo sirve luego en la mesa. Es aquí donde entra en juego el camarero,
que vendría a ser la API. El camarero es el mensajero (la API) que comunica a la cocina (el
sistema) lo que debe hacer. Después, el camarero te entrega la respuesta; en este caso, la
comida.
Veamos ahora un ejemplo de API en la vida real. Es posible que conozcas el proceso de
búsqueda de vuelos online. Como sucede en el restaurante, dispones de una amplia variedad
de opciones entre las que elegir, como diferentes ciudades, fechas, etc. Imaginemos que estás
reservando un vuelo en el sitio web de una aerolínea. Eliges la ciudad de salida y la fecha, la
ciudad de vuelta y la fecha, la clase y otras variables. Para reservar el vuelo, interactúas con el
sitio web de la aerolínea para acceder a su base de datos y consultar si hay asientos
disponibles en esas fechas y cuál sería el precio.
 Sin embargo, ¿qué pasa si no vamos al sitio web de la aerolínea, que es un canal que tiene
acceso directo a la información? ¿O qué sucede cuando recurrimos a una agencia de viajes
digital, como Kayak o Expedia, que agrega información procedente de diversas bases de datos
de aerolíneas?
La agencia de viajes, en este caso, es quien interactúa con la API de la aerolínea. La API es la
interfaz a la que, como a un servicial camarero, la agencia de viajes puede recurrir para
obtener la información de asientos, opciones de equipaje, etc. almacenada en la base de datos
de la aerolínea. A continuación, la API transmite la respuesta de la aerolínea a la solicitud y
entrega la información a la agencia de viajes digital, que ahora puede facilitar la información
más actualizada y relevante.

Lo que proporciona la API es una capa de seguridad

De esta manera, los datos del usuario nunca se exponen íntegramente al servidor, de la misma
manera que el servidor nunca se expone íntegramente al punto de acceso. Lo que ocurre es
que cada parte implicada se comunica mediante pequeños paquetes de datos, compartiendo
solo lo estrictamente necesario, como sucede al pedir comida. El usuario comunica al
restaurante lo que le gustaría comer, el restaurante indica lo que necesita a cambio y, al final,
se entrega la comida.
Las API son ahora tan valiosas que constituyen una gran parte de los ingresos de las
empresas. Grandes empresas como Google, eBay, Salesforce.com, Amazon y Expedia son tan
solo algunas de las organizaciones que obtienen beneficios de las API. Este mercado se conoce
como la "economía de las API".
La API moderna
Tradicionalmente, las API se han descrito como cualquier interfaz de conectividad genérica a
una aplicación. Más recientemente, no obstante, la API moderna ha desarrollado algunas
características que la hacen extraordinariamente útil y valiosa:
• Las API modernas siguen estándares (normalmente HTTP y REST) que resultan sencillos
para los desarrolladores, fácilmente accesibles y muy bien conocidos.
• Se conciben más como productos que como código. Su diseño está orientado al consumo por
parte de un público concreto (p. ej., desarrolladores para móviles); además, existe mucha
documentación al respecto, así como diferentes versiones que responden a determinadas
expectativas de los usuarios en cuanto a su mantenimiento y ciclo de vida.
• Dado este mayor nivel de estandarización, presentan una disciplina mucho más sólida en lo
que respecta a la seguridad y la gobernanza. Asimismo, la capacidad de supervisión y gestión
mejora el rendimiento y la escala.
• Como cualquier otro producto de software, la API moderna tiene su propio ciclo de vida de
desarrollo de software (SDLC) para el diseño, las pruebas, el desarrollo, la gestión y la
creación de nuevas versiones.  Asimismo, las API modernas están bien documentadas para su
consumo y la creación de nuevas versiones.
Amazon API Gateway es un servicio completamente administrado que facilita a los
desarrolladores la creación, la publicación, el mantenimiento, el monitoreo y la protección de
API a cualquier escala. Las API actúan como la "puerta de entrada" para que las aplicaciones
accedan a los datos, la lógica empresarial o la funcionalidad de sus servicios de backend. Con
API Gateway, puede crear API RESTful y API WebSocket que permiten aplicaciones de
comunicación bidireccional en tiempo real. API Gateway admite cargas de trabajo en
contenedores y sin servidor, así como aplicaciones web.

API Gateway gestiona todas las tareas implicadas en la aceptación y el procesamiento de

hasta cientos de miles de llamadas a API simultáneas, entre ellas, la administración del
tráfico, compatibilidad con CORS, el control de autorizaciones y acceso, la limitación
controlada, el monitoreo y la administración de versiones de API. API Gateway no requiere
pagos mínimos ni costos iniciales. Se paga por las llamadas a las API que se reciben y por la
cantidad de datos salientes transferidos; además, con el modelo de precios por niveles de API
Gateway, puede reducir sus costos a medida que cambie la escala de uso de las API.

API RESTful

Cree API RESTful optimizadas para cargas de trabajo sin servidor y backends HTTP
mediante API HTTP. Las API HTTP son la mejor opción para crear API que solo requieran
funcionalidad de proxy de API. Si sus API requieren las características de administración de
API y la funcionalidad de proxy de API en una única solución, API Gateway también ofrece
API REST.
API DE WEBSOCKET

Cree aplicaciones de comunicación bidireccional en tiempo real, como aplicaciones de chat y

paneles de streaming, con API WebSocket. API Gateway mantiene una conexión persistente
para manejar la transferencia de mensajes entre su servicio de backend y sus clientes.

API REST: qué es y cuáles son sus ventajas en el desarrollo de proyectos

REST cambió por completo la ingeniería de software a partir del 2000. Este nuevo enfoque de
desarrollo de proyectos y servicios web fue definido por Roy Fielding, el padre de la
especificación HTTP y uno los referentes internacionales en todo lo relacionado con la
Arquitectura de Redes, en su disertación ‘Architectural Styles and the Design of
Network-based Software Architectures’. En el campo de las APIs, REST
(Representational State Transfer- Transferencia de Estado Representacional) es, a día de hoy,
el alfa y omega del desarrollo de servicios de aplicaciones.
En la actualidad no existe proyecto o aplicación que no disponga de una API REST para la
creación de servicios profesionales a partir de ese software. Twitter, YouTube, los sistemas de
identificación con Facebook… hay cientos de empresas que generan negocio gracias a REST y
las APIs REST. Sin ellas, todo el crecimiento en horizontal sería prácticamente imposible.
Esto es así porque REST es el estándar más lógico, eficiente y habitual en la creación de APIs para
servicios de Internet.
Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para
obtener datosCaracterísticas de REST
Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la información
necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún
estado previo para satisfacerla. Aunque esto es así, algunas aplicaciones HTTP incorporan
memoria caché. Se configura lo que se conoce como protocolo cliente-caché-servidor sin
estado: existe la posibilidad de definir algunas respuestas a peticiones HTTP concretas como
cacheables, con el objetivo de que el cliente pueda ejecutar en un futuro la misma respuesta
para peticiones idénticas. De todas formas, que exista la posibilidad no significa que sea lo
más recomendable.

Las operaciones más importantes relacionadas con los datos en cualquier sistema REST y la
especificación HTTP son cuatro: POST (crear), GET (leer y consultar), PUT (editar) y
DELETE (eliminar).

Los objetos en REST siempre se manipulan a partir de la URI. Es la URI y ningún otro
elemento el identificador único de cada recurso de ese sistema REST. La URI nos facilita
acceder a la información para su modificación o borrado, o, por ejemplo, para compartir su
ubicación exacta con terceros.
Interfaz uniforme: para la transferencia de datos en un sistema REST, este aplica acciones
concretas (POST, GET, PUT y DELETE) sobre los recursos, siempre y cuando estén
identificados con una URI. Esto facilita la existencia de una interfaz uniforme que sistematiza
el proceso con la información.

Sistema de capas: arquitectura jerárquica entre los componentes. Cada una de estas capas
lleva a cabo una funcionalidad dentro del sistema REST.

Uso de hipermedios: hipermedia es un término acuñado por Ted Nelson en 1965 y que es una
extensión del concepto de hipertexto. Ese concepto llevado al desarrollo de páginas web es lo
que permite que el usuario puede navegar por el conjunto de objetos a través de enlaces
HTML. En el caso de una API REST, el concepto de hipermedia explica la capacidad de una
interfaz de desarrollo de aplicaciones de proporcionar al cliente y al usuario los enlaces
adecuados para ejecutar acciones concretas sobre los datos.

Para cualquier API REST es obligatorio disponer del principio HATEOAS (Hypermedia As
The Engine Of Application State – Hipermedia Como Motor del Estado de la Aplicación) para
ser una verdadera API REST. Este principio es el que define que cada vez que se hace una
petición al servidor y éste devuelve una respuesta, parte de la información que contendrá
serán los hipervínculos de navegación asociada a otros recursos del cliente.

Devolución de una petición a una API REST según el principio HATEOAS (enlaza a un
tutorial explicativo del concepto de hipermedia en API REST con un ejemplo práctico de una
petición a una base de datos de automóviles): o generar operaciones sobre esos datos en todos
los formatos posibles, como XML y JSON. Es una alternativa en auge a otros protocolos
estándar de intercambio de datos como SOAP (Simple Object Access Protocol), que disponen
de una gran capacidad pero también mucha complejidad. A veces es preferible una solución
más sencilla de manipulación de datos como REST.

Características de REST
• Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la
información necesaria para ejecutarla, lo que permite que ni cliente ni servidor
necesiten recordar ningún estado previo para satisfacerla. Aunque esto es así,
algunas aplicaciones HTTP incorporan memoria caché. Se configura lo que se
conoce como protocolo cliente-caché-servidor sin estado: existe la posibilidad de
definir algunas respuestas a peticiones HTTP concretas como cacheables, con el
objetivo de que el cliente pueda ejecutar en un futuro la misma respuesta para
peticiones idénticas. De todas formas, que exista la posibilidad no significa que
sea lo más recomendable.
 • Las operaciones más importantes relacionadas con los datos en cualquier
sistema REST y la especificación HTTP son cuatro: POST (crear), GET (leer y
consultar), PUT (editar) y DELETE (eliminar).
• Los objetos en REST siempre se manipulan a partir de la URI. Es la URI y
ningún otro elemento el identificador único de cada recurso de ese sistema
REST. La URI nos facilita acceder a la información para su modificación o
borrado, o, por ejemplo, para compartir su ubicación exacta con terceros. 
• Interfaz uniforme: para la transferencia de datos en un sistema REST, este
aplica acciones concretas (POST, GET, PUT y DELETE) sobre los recursos,
siempre y cuando estén identificados con una URI. Esto facilita la existencia de
una interfaz uniforme que sistematiza el proceso con la información.
• Sistema de capas: arquitectura jerárquica entre los componentes. Cada una de
estas capas lleva a cabo una funcionalidad dentro del sistema REST.
• Uso de hipermedios: hipermedia es un término acuñado por Ted Nelson en 1965
y que es una extensión del concepto de hipertexto. Ese concepto llevado al
desarrollo de páginas web es lo que permite que el usuario puede navegar por el
conjunto de objetos a través de enlaces HTML. En el caso de una API REST, el
concepto de hipermedia explica la capacidad de una interfaz de desarrollo de
aplicaciones de proporcionar al cliente y al usuario los enlaces adecuados para
ejecutar acciones concretas sobre los datos.
Para cualquier API REST es obligatorio disponer del principio HATEOAS (Hypermedia As
The Engine Of Application State – Hipermedia Como Motor del Estado de la Aplicación) para
ser una verdadera API REST. Este principio es el que define que cada vez que se hace una
petición al servidor y éste devuelve una respuesta, parte de la información que contendrá
serán los hipervínculos de navegación asociada a otros recursos del cliente.
Devolución de una petición a una API REST según el principio HATEOAS (enlaza a un
tutorial explicativo del concepto de hipermedia en API REST con un ejemplo práctico de una
petición a una base de datos de automóviles):

Ventajas que ofrece REST para el desarrollo

1. Separación entre el cliente y el servidor: el protocolo REST separa totalmente la
interfaz de usuario del servidor y el almacenamiento de datos. Eso tiene algunas
ventajas cuando se hacen desarrollos. Por ejemplo, mejora la portabilidad de la
interfaz a otro tipo de plataformas, aumenta la escalabilidad de los proyectos y
permite que los distintos componentes de los desarrollos se puedan evolucionar
de forma independiente.
2. Visibilidad, fiabilidad y escalabilidad. La separación entre cliente y servidor
tiene una ventaja evidente y es que cualquier equipo de desarrollo puede escalar
el producto sin excesivos problemas. Se puede migrar a otros servidores o
realizar todo tipo de cambios en la base de datos, siempre y cuando los datos de
 cada una de las peticiones se envíen de forma correcta. Esta separación facilita
tener en servidores distintos el front y el back y eso convierte a las aplicaciones
en productos más flexibles a la hora de trabajar.
3. La API REST siempre es independiente del tipo de plataformas o lenguajes: la
API REST siempre se adapta al tipo de sintaxis o plataformas con las que se
estén trabajando, lo que ofrece una gran libertad a la hora de cambiar o probar
nuevos entornos dentro del desarrollo. Con una API REST se pueden tener
servidores PHP, Java, Python o Node.js. Lo único que es indispensable es que
las respuestas a las peticiones se hagan siempre en el lenguaje de intercambio de
información usado, normalmente XML o JSON.