ARQUITECTURAS DE SOFTWARE

Partes de un Software

Un software, en su concepción más general y sin depender necesariamente de la Internet sería "un conjunto de pasos o acciones computacionales que se organizan con una lógica entre sí, constituyen operaciones programadas,escritas como instrucciones en un lenguaje de código para un computador, que se encargan de resolver un problema, o de realizar una función concreta a través de un conjunto de características, se crean a partir de una demanda de uso, basada en la necesidad de resolver un problema de la vida real ".
Algunos según su naturaleza, funcionalidad y características pueden ser de uso comercial, profesional o personal, además pueden ser gratuitos: de código abierto ó privados: pagos.

>

Un software se compone en varias partes o capas distintivas. Entre estas tenemos principalmente:

• Capa de Presentación(o interfaz de usuario), que es la parte visible con la que el usuario interactúa y que se encarga de la interacción y la visualización de la información.
• Capa de Lógica de Negociodonde reside la inteligencia de la aplicación, es decir, el conjunto de reglas y el procesamiento de datos que definen sus funcionalidades y comportamientos.
• Capa de Datosresponsable del almacenamiento y la gestión persistente de la información, usualmente mediante bases de datos internas o archivos.

Arquitectura del Software: Las Monolíticas

Ahora que ya sabemos que un software se compone de varias partes, estas además de crearlas de manera independiente, hay que conectarlas para que interactúen con una finalidad determinada, es decir, como un sistema completo, de aquí que se diga "programar el sistema" y esto requiere una construcción.
Como todo proceso constructivo hay que definir una arquitectura, tal y como si habláramos de las partes de un edificio y construirlo completo.
¿Entonces,que sería la Arquitectura del Software?
Se trata de la forma en que se organizan las partes o capas del sistema, buscando una separación de funciones y responsabilidades que es fundamental para un buen diseño.
Debido a la alta demanda del Software, se ha requerido una evolución en su forma de construirlos, evolucionando así las arquitecturas.

Primeras arquitecturas "Las Monolíticas":
Inicialmente, en el caso de un software que no depende necesariamente de Internet, la arquitectura más básica es la monolítica. Esta arquitectura se caracteriza por tener todo el código acoplado y organizado en tres capas principales: la Capa de Presentación (o interfaz de usuario),gestionando la visualización y la interacción; la Capa de Lógica de Negocio, donde reside la inteligencia del negocio y el procesamiento de datos del sistema y la Capa de Datos, encargada del almacenamiento y la gestión de la información, típicamente en bases de datos.

Aunque sencilla, la arquitectura monolítica presenta desafíos en escenarios de alta complejidad, demanda y necesidad de alta disponibilidad, ya que al estar todas las partes acopladas, los cambios o la escalabilidad se vuelven difíciles. Esto significa que si se afecta una de sus partes influye en el funcionamiento del resto debido a su alto nivel de acoplamiento.

Las Arquitecturas del Software: Cliente-Servidor

A inicios del siglo XXI,con la evolución tecnológica de la Internet y la Web, la demanda de mayor satisfacción de los usuarios en el uso de los productos de Software en Internet, aumentaba de manera exponencial, requiriendo programas más complejos capaces de emplearse en las nuevas tecnologías (trasmisión de datos en tiempo real en la red), además de hacer frente a la volatilidad de consumo, por lo que se necesitó crear nuevas alternativas de arquitecturas que permitieran desarrollar Softwares más eficientes.
Como parte de esta evolución y una de las arquitecturas más populares, especialmente para aplicaciones en Internet, surge la arquitectura Cliente-Servidor, en este modelo el Software se divide en dos componentes: el Cliente y el Servidor.

• El Cliente: Es la tecnología que consume los servicios del negocio, generalmente un Navegador Web(, , , , , ,), que en sítesis se trata de una aplicación de software (instalada en el dispositivo del usuario ó residente del SO), que permite a los usuarios acceder, visualizar e interactuar con la información en la Web.
  El Cliente inicia las peticiones (request) de servicios al Software usando protocolos HTTP para interactuar con el servidor. Antes de estas interacciones, lo primero que hace el Cliente es traducir el código de las páginas web (principalmente HTML) en contenido que puede ser visto e interactuado, como texto, imágenes y videos, así es como accede al FrontEnd, del Software web, e interactúa con la UI , así es cómo el usuario puede interactuar con los servicios web, a través del Cliente.
  Un Cliente es toda aquella aplicación que consuma los servicios del Software, por lo general los Navegadores, pero también pueden ser dispositivos móviles, un Backend accediendo a un Servidor de Bases de datos, un Backend accediendo a otro servidor como un Servidor de Aplicaciones, etc.
• El Servidor: Es la parte del Software no visible al usuario, lo que está por detrás de la UI, de aquí que se le llama Backend, "Back" en inglés significa "atrás", contiene la lógica de negocio y la base de datos .
  El Servidor,ofrece los "servicios" al Cliente, de forma remota, de aquí que se le llame "servidor", generalmente un Servidor Web, aunque también puede ser un Servidor de Aplicaciones, u otros tipos de Servidores.
  El Servidor, contiene la programación de la lógica del negocio, o sea el conjunto de instrucciones que definen las funcionalidades y comportamientos del Software para un objetivo especifico.
  Es el componente que recibe y procesa las solicitudes del cliente, devolviendo las respuestas (response). El Servidor se encarga de proporcionar los servicios, gestionando la lógica de negocio y almacenando la información, a menudo en bases de datos.

La comunicación entre cliente y servidor se realiza a través de redes, utilizando el protocolo HTTP a través de sus diferentes métodos :GET-Ver/Obtener,POST -Enviar/ Crear,PUT-Actualizar/Modificar, Path-Modificar un recurso ,DELETE-Eliminar. Los protocolos definen las acciones e interacciones que puede hacer el usuario con la aplicación, los protocolos lo que hacen es establecer las reglas de comunicación y control de acceso a los recursos y datos en la web, estos protocolos permiten que el navegador envíe una petición al servidor, y que este le responda con el FrontEnd del Software (documento HTML, imágenes, videos y estilos necesarios para construir la página completa) y la información requerida.

El objetivo principal de la arquitectura cliente-servidor es la separación de las capas de la arquitectura monolítica, permitiendo la escalabilidad y el mantenimiento individual de cada capa.
Este modelo favorece el trabajo de equipos de desarrollo independientes y el uso de infraestructuras especializadas.
Cabe mencionar que existen otras alternativas de arquitecturas como el software standalone (que ejecuta toda la operativa en un solo sistema) o las redes Peer-to-Peer (donde cada nodo es cliente y servidor). Sin embargo, el modelo cliente-servidor, a pesar de superar los desafíos de la arquitectura monolítica, también tiene sus limitaciones, ya que requiere la existencia de una red y tiene un punto de falla en el servidor, a pesar de esto, sigue siendo la base de la mayoría de los servicios web en la nube y aplicaciones actuales.

Modelos de Arquitectura Cliente-Servidor

La arquitectura cliente-servidor se fue desarrollando en sí misma, ya contenía la lógica de intercambio entre un front y un back, mediante peticiones HTTP en la web a través de un navegador.
Así se desarrollaron los modelos de esta arquitectura:

• Primero Modelo Estándar: 2-Tier, implica que el cliente se comunica directamente con el servidor
• Segundo Modelo: 3-Tier, el cliente se comunica con un intermediario o proxy, que se comunica con el servidor,introducen una capa intermedia de lógica de negocio entre el cliente y el servidor.
• Tercero Modelo: N-Tier, se divide el software en capas, cada una con una función diferente, y se comunican entre ellas.
  Se definen capas adicionales para una separación aún más profunda de las responsabilidades del software, como aislar la capa de datos en su propio nivel, lo que proporciona una mayor separación de responsabilidades y mejora la mantenibilidad y escalabilidad a costa de una mayor complejidad.

Arquitectura Microservicios

A partir de los principios de separación del Software en capas, en 2010 se lanza el modelo de:

Arquitectura Microservicios.
Si decimos que un cliente hace solicitudes al servidor, entonces está haciendo uso de "un servicio". En esta arquitectura, una aplicación se divide en varios microservicios, que son pequeñas y autónomas "mini-aplicaciones" que cumplen una única función específica del total de servicios de la aplicación, o sea se van a separar y aislar cada servicio.
Esta lógica de modelo hace que la arquitectura sea ideal para Software más complejos.
Cada microservicio es una pieza de software que provee una funcionalidad concreta, y los servicios web, por ejemplo, exponen lógica y datos a través del protocolo HTTP mediante métodos de peticiones específicos.

Cada microservicio se puede comunicar con otros microservicios y con las peticiones del cliente a través de las Interfaces de Programación de Aplicaciones ó APIs, estas van a determinar las reglas de comunicación según las solictudes de los métodos HTTP y los "endpoints" específicos para acceder a cada microservicio, esto es el punto de acceso al Servidor, el endponit contiene es la ruta que se utiliza para acceder al microservicio, desde la petición del cliente hasta la ubicación del recurso en el servidor, en otras palabras la "URL".

La arquitectura de microservicios puede ser muy útil para Softwares web que manejen un gran volumen de peticiones de usuarios, por ejemplo en un Software de Ecommerce, se pueden crear microservicios que respondan a un gran volumen de peticiones como un tienda online, un microservicio contendría la funcionalidad de visualización de productos, otro microservicio se encarga de la logística de entrega, otro se encarga de la gestión de pagos y así, cada microservicio tendría una funcionalidad específica de todo el sistema.
Se puede tratar como "mini-software" a cada microservicio, ya que es independiente, tiene un Frontend o interfaz de usuario único. Esto no significa que un sitio web que tenga varias páginas web, con la misma funcionalidad, cada una con su UI, se va a tratar de un Software con arquitectura de microservicios; como por ejemplo este sitio web donde estas ahora, en el que todas las páginas responden a la misma función "mostrar artículos de contenido", para el uso de lector.
En resumen: Para que un Software cumpla con la arquitectura de microservicios, se deben considerar en principio 3 requisitos:

Como mencionaba antes por la forma en la que se que desarrolla cada microservicio, además de ser las partes de un Software más complejo,también se pueden considerar Softwares independientes, de bajo acoplamiento, focalizados en una sola funcionalidad lo que los dota de atomicidad y aislamiento, con una estructura interna sencilla.
En resumen: preciso que esta arquitectura trae grandes beneficios, permite escalar y mantener las partes del software de forma independiente, facilita que diferentes equipos trabajen en paralelo y mejora la flexibilidad general del sistema.
Como QA comprender la arquitectura del proyecto, permite entender como va a funcionar el Software, como va a majer las necesidades de los usuarios, entendidas como solicitudes cliente-servidor, Además permite focalizar la atención según el miscroservicio aislado y sus requisistos de calidad, de esta forma permite distinguir la complejidad del proyecto en el que se está participando.
El microservicio por dentro, sus características
La organización de un microservicio incluye primero un FrontEnd o UI y en segundo un Backend que incluye varias capas:

• Capa Controller:Es la capa más externa, que valida y gestiona los tipos de peticiones y envía las respuestas, que se realizan a través de un endpoint. Gestiona la seguridad del microservicio, maneja la autenticación para el acceso autorizado según la petición.
• Capa Validator:Es la capa intermedia, que verifica el formato de los datos. Valida que la petición y envío de datos tenga el formato adecuado para evitar conflictos en la comunicación.
• Capa de lógica de negocio: Es la capa más interna del microservicio, contiene la programación y el código de los módulos que organizan las tareas que realiza el sistema con el fin de cumplir con la funcionalidad del microservicio. Accede a su propia base de datos internas

APIs en Arquitectura de Microservicios

APIs en la Comunicación entre Frontend y Backend
Es impotante aclarar que de manera general en la arquitectura base cliente-servidor, donde el cliente se comunica desde el frontend con el backend y viceversa mediante el protocolo HTTP (request/response) a través de un endpoint en el backend mediante las reglas y la implementación de las APIs.
Entonces qué son las APIs de manera más general y por qué se usan, para este caso retomo conceptos explicados antes, donde se hablaba sobre los lenguajes de programación que son, y su diversidad, por lo que se puede entender que los Software se desarrollan con diferentes lenguajes de programación, entonces se entiende que van a existir Backends con diferentes programaciones.
Esto puede suponer un problema pues el Cliente debe poder hacer sus solicitudes al Backend independientemente de que lenguajes de programación fueron usados, entonces es necesario contar con un medio de comunicación para la trasmisión de datos y el intercambio de información entre el Frontend y el Backend. A partir de estas necesidades se desarrollaron aplicaciones que programaran esta comunicación, en otras palabras las APIs.

APIs en la conexión de Microservicios
La autonomía y el aislamiento de cada microservicio son cruciales, permitiendo incluso el uso de diferentes lenguajes de programación o motores de base de datos para cada uno.
Para conectar estos microservicios entre sí, se utilizan varias técnicas basadas en APIs, como puede ser:

- La Arquitectura Hexagonal con la cual se conectan los microservicios con puertos y adaptadores, donde los puertos van a ser interfaces de comunicación (APIs) que definen como se conectarán los servicios y los adaptadores van a ser las implementaciones concretas de esos puertos, que van a permitir la comunicación de los microservicios con los sistemas externos, así la aplicación se comunicacon diferentes tecnologías (por ejemplo, una base de datos SQL o una API REST) sin afectar la lógica de negocio central.
En resumen, digamos que los "puertos" establecen las reglas de comunicación y los "adaptadores" las ejecutan.
Se utiliza la abstracción de "héxagono" como figura geométrica para digramar visualmente la arquitectura, ilustrar la posibilidad de tener múltiples puntos de interacción y la simetría en las relaciones entre la aplicación y el mundo exterior, ya que el hexágono representa el núcleo de la aplicación, donde reside la lógica de negocio y sus lados simbolizan simbolizan las capas de interacción con el exterior, teniendo en una capa los "puertos" y en otra los "adaptadores". La abstracción de "hexágono" por su número de lados no se puede tomar literal, No hay una cantidad fija de "lados" o puertos; la analogía solo se emplea para enfatizar la posibilidad de múltiples interacciones, la cantidad de lados estará determinada por la complejidad del microservicio. Esta arquitectura busca desacoplar la lógica de negocio de las tecnologías externas, permitiendo que la aplicación sea más flexible, fácil de probar y mantener.

- También se utiliza la arquitectura con un API Gateway (puerta de acceso), que gestiona los múltiples endpoints de los microservicios y expone uno solo hacia el exterior, además de encargarse de la seguridad, o sea va a manejar la cantidad de endpoints disponibles por cada microservicio, por eso se utiliza una puerta de enlace o enrutador, que será un administrador centralizado de las peticiones, así cada microservicio no expone directamente sus propios endpoints y el API Gateway se encarga de manejarlos y encaminarlos a los microservicios correspondientes, este modelo simplifica la conectividad y gestiona internamente la comunicación con los microservicios individuales, lo que permite mejor balanceo de la carga de trabajo y optimiza la interacción de las solicitudes de los clientes.

APIs en las Reglas de Comunicación
En las arquitecturas de microservicios se necesita crear reglas para gestionar las peticiones de los clientes a través de los endpoints, o sea lo que pueden hacee según las reglas de negocio, imaginemos un cliente ejecuta un método HTTP como POST, GET, DELETE, etc, en este caso Delete a través de un endpoint donde no se permite el uso de DELETE, entonces habría un problema, en un ejemplo más concreto imaginemos que un usuario accede a un endpoint medinte una url para crear un perfil y no puede hacerlo con un Post, no recibe confrmación o recibe error y se supone que esa url da acceso a una interfaz que dice "Crear perfil", entonces estamos ante un problema que o puede ser de la comunicación del Navegador con el backend o pudiera ser interno.
Estas condiciones y necesidades en las arquitecturas de microservicios demandaban que además de permitir la comunicación entre programaciones de difrentes lengujes, tambén se incluyeran las reglas de dicho intercambio, así las Interfaces de Programación de Aplicaciones o las APIs, que son un medio de comunicación entre los sistemas, que además se pueden entneder como un protocolo de comunicación de un lado hacia el otro, que va a contener las instrucciones de acceso a través del edpoint y los tipos de solicitudes HTTP que se pueden hacer.
Antes de caer en detalles sobre las APIs, cabe aclara que una interfaz es de manera general un espacio de memoria donde se almacenan las instrucciones del código ejecutable, algunas bonitas con estilo y diseño agradable para ser consumida por los usuarios como la UI, que tiene un código, que aunque como usuarios no lo solemos ver directamente porque usamos un programa que es el que lee este código y lo convierte en gráficos visuales, o sea el Navegador, pero si hicieramos click derecho en una página Web se nos muestra el código fuente; pero en cambio otras interfaces son menos accesibles a los usuarios, son más para ser leídas por las máquinas, para ejecutar toda la lógica del Sofware.
En este caso las Interfaces de programación de aplicaciones o APIs se van a entender, como ese espacio de almacenamiento en memoria con un código ejecutable, como un programa, cuyas instrucciones van a ejecutar tareas de solicitudes del protocolo HTTP y/o de comunicación entre sistemas, entre los microservicios de un Software completo (API Gateway y Hexagonal), entre el Frontend y el Backend, entre el Backend y la Base de Datos, entre un cliente Backend y un Servidor Backend etc.
En resumen: las APIs son parte fundamental en la arquitectura de microservicios, permitiendo que diferentes sistemas se comuniquen e intercambien datos. En este contexto se utilizan para permitir que diferentes partes del Software se comuniquen entre sí.
Sobre las APIs se ampliará en la lección relacionada con Testing de APIs

En resumen:Las APIs comunican al Cliente con el Servidor, conectan las partes del Software (microservicios), permitiendo que diferentes sistemas se comuniquen e intercambien datos y establecen e implementan las reglas de estas comunicaciones

Tecnologías de Contenedores

El código fuente de los microservicios se va desarrollando, integrando y desplegando en serviores remotos de manera independiente, a forma de "máquinas virtuales" que contendrán toda la lógica cada microservicio, sus recursos, dependencias (librerías) y bases de datos.
Los desarrolladores para programar sus sistemas , desde las instrucciones de codigo hasta los recursos que usen y luego ejecutarlos ("correrlos") para probar su funcionamiento, necesitan crear un entorno de desarrollo en sus máquinas locales a modo de máquinas virtuales . Se trata de crear una máquina a parte de la principal , sería como una mini-computadora, para esto se utilizan herramientas de virtualización como VirtualBox y VMWare, las que permiten crear entornos virtuales en diferentes sistemas operativos como Windows, Linux, etc.
Se puede tener un computador con un sistema operativo (SO) principal el Linux y la máquina virtual se configura por ejemplo con una distribución de Linux (otro SO), una versión de un lenguaje de programación, una base de datos, etc., en fin con los recursos y dependencias que van a necesitar y emplear en el dedsarrollo y ejecución del software. Esta práctica permite que se pueda realizar el desarrollo sin tocar nada del SO principal del equipo, lo cual es muy eficiente y útil sobretodo para proyectos pequeños y hasta personales, luego estos programas se van a desplegar en servidores remotos, lo que implica que los desarrolladores tengan que crear un entorno de desarrollo en un servidor remoto, con los mismos recursos y dependencias.
Esta ultima parte de crear el mismo entorno en remoto, puede traer consigo posibles problemas de compatibilidad, ya que a veces el entorno de desarrollo em local puede estar sobre un sistema operativo diferente al que tenga el servidor remoto, ó se puede tener una versión de un lenguaje de programación diferente en local y en remoto, ó un desarrollador puede estar trabajando con una versión de algún recurso o una librería por ejemplo no compatibles con las de otro desarrollador.
El desarrollo de Software de arquitectura de microservicios al ser más complejos e implicar un trabajo colaborativo, demanda de soluciones más avanzadas, es aquí donde entra la "virtualización", se trata de una concepción más avanzada para la configuración de entornos de desarrollo, se trata de crear un "entorno virtual" en local que sirva de plataforma de ejecución similar al entorno en remoto, así se puede desarrollar el código en local, en lugar de correr el código directamente en la máquina host (servidor remoto) contando con la misma configuración.
Lo ideal es que la virtualización sea una copia exacta del servidor que se va a disponer en producción, de este modo se puede asegurar, que lo que funciona en local, funcionará también en remoto. Esto favorece el trabajo de equipo, ya que todos los desarrolladores que trabajan conjunto, comparten una misma virtualización como plataforma de ejecución del proyecto que están desarrollando en local. De este modo, lo que funciona para un integrante del equipo debería funcionar también para el resto de los compañeros, ya que en el fondo todos están ejecutando el proyecto bajo el mismo sistema operativo, las mismas versiones de lenguajes y librerías, etc., además de tener en local exactamente los mismos recursos que se tienen en el servidor en remoto, allí donde el código va a desplegarse en producción.
En resumen, la virtualización es una herramienta que permite crear entornos virtuales a modo de contenedor, que para el desarrollo de microservicios es muy eficiente, así se puede desarrollar cada uno en paralelo sin que las dependencias de uno afecten a los demás o al sistema operativo principal.
Como alternativa más avanzada para el desarrollo de microservicios empleando la virtualización, han surgido nuevas tecnologías, con muchas funcionalidades, en constante crecimiento, que permiten gestionar la configuración de diversos entornos de desarrollo virtual y en paralelo contando con servicios de servidores.
Entre estas tecnologías se encuentran:
Los Contenedores:
Se trata de tecnologías que permiten el desarrollo de microservicios de forma paralela, creando entornos virtuales a modo de contenedor donde se va a trabajar cada microservicio separadamente, contendrán sus recursos y dependencias, por lo que no se va a necesitar instalar y configurar un entorno de desarrollo completo, solo para esa pequeña parte del Software. Además es una forma de arquitectura de conexión de microservicios y de su desarrollo aislado y gestión independiente . Es como tener diferentes escritorios, cada uno con sus propias herramientas y configuraciones, para diferentes proyectos, evitando conflictos y manteniendo todo organizado.
Con los contendores se puede tener un microservicio por ejemplo creado con una versión de un lenguaje de programación y en otro contenedor se puede estar usando otra versión de ese mismo lenguaje, esto favorece mucho a los grandes Softwares que se ven obligados a migrar todo su código de un entorno a otro de desarrollo y por cambios de versión de alguno de sus recursos como el lenguaje de programación, ó un Sistema de Gestión de BD.

• Docker Entre las tecnologias que ofrecen servicios de creación de Contendores se encuentra Docker, que se ha popularizado mucho en la comunidad de desarrolladores debido a su facilidad de uso y eficiencia, es de código abierto, por lo que es libre de uso e instación, permitiendo el desarrollo de microservicios de forma sencilla y eficiente, permite aislar al microservicio y sus dependencias en diferentes entornos, facilitando su configuración, aislamiento y escalado, todo dentro de un contenedor virtual, sin necesidad de instalar y configurar un entorno de desarrollo completo.
  Para utilizar Docker, primero se debe instalar el Software desde la web oficial, la que ofrece bastante documentación y guías de usuario intuitivas, además de una comunidad que va acelerando el uso y crecimiento de las capacidades de este sistema.
  Después instalado el programa de getión Docker Engine, se empieza a configurar el entorno de desarrollo, con tres pasos básicos principales:
  1-Crear un Dockerfile ó Archivo de Docker:
  Es un archivo de texto que contiene instrucciones para construir y configurar un contenedor Docker. Contiene todos los comandos e instrucciones para instalar todas las dependencias que se necesitan para la aplicación. Es un manual.
  2-Crear un Docker Image Imagen de Docker:
  Es un archivo ejecutable para correr los contenedores. Contiene los elementos comunes de los contendores. Sería como una clase para instanciar los contenedores, digamos que es como una plantilla de contenedores, define los elementos principales que van a tener todos. Es un paquete de software que se puede distribuir y ejecutar en cualquier entorno.
  3-Crear un Docker Container o Contenedor de Docker:
  Es un contenedor de software que se ejecuta en un entorno virtual de Linux, que se construye con el Dockerfile y se ejecuta con Docker Engine.
  Sería como la instancia de un microservicio que sigue la definición de la plantilla de contenedores, o sea del Docker Image.
  4-Crear un Docker Compose o Composición de Docker:
  Es una herramienta que permite crear y gestionar múltiples contenedores de Docker de manera sencilla y eficiente. Permite definir un conjunto de servicios y sus dependencias y luego construir y ejecutar todos los contenedores en un solo comando.
  Para aprender más sobre Docker y funcionalidades de contenedores, recomiendo acceder a la web oficial: https://www.docker.com/
  Su logo representa una ballena en el mar que contiene varias cajas, digamos que simula un gran contenedor, ya que las ballenas son animales muy grandes y que además viajan en grupos.
• Kubernetes o K8:
  Viene del griego y significa: "timón de barco" (así su Logo), es un Software de automatización para gestionar los contenedores de microservicios.
  Kubernetes es como un orquestador de contenedores, se usa para las aplicaciones grandes que usan la arquitectura de microservicios, por lo que necesitan una forma de gestionar y automatizar los procesos desarrollo con los contenedores, la asignación de recursos y el despliegue. Esta gestión Kubernetes lo hace de forma declarativa con un conjunto de instrucciones en un plano de control, como lo hace Docker con el Dockerfile, lo que en este caso cada implementación de kubernetes para las máquinas virtuales, se llama "Cluster", se refiere a un conjunto, dicho conjunto para su funcionamiento se compone con una estructura que permiten gestionar un grupo de microservicios que ya están aislados en contenedores, controlando y organizando las operaciones. De manera general, para poder entender la lógica de la arquitectura de Kubernetes, cada Cluster, incluye:
  Primero: Una máquina virtual identificada como "Master Node", esta contiene la infraestructura de Kubernetes organizada en 4 componentes:
  "ETDC"- el motor de datos
  "Apiserver" - el controlador de API que va a comunicar el Nodo master con los demás nodos de la infraestructura
  "Scheduler"- va a gestionar la asignación y programación de las tareas dentro de las máquinas virtuales que vana correr los contnedores
  "Controller-Manager"- gestiona el control de los contenedores, la asignación de recursos y la implementación de la infraestructura del cluster .
  Segundo: Va a utilizar un conjunto de máquinas virtuales identificadas como "Workers Nodes", estas van a contar con un componente principal identificado como "Kubelet" y los Podsd, el primero es el encargado de implementar las instrucciones del Nodo master y el segundo es la instancia del Software en desarrollo que está organizado en un conjunto de contenedores por cada microservicio.
  Si aumenta la cantidad de proyectos se puede ampliar la arquitectura de Kubernetes, ampliando el Cluster con la cantidad de nodos que se requieran, y con la cantidad de microservicios que se requieran; o se podría reducir la arquitectura de Kubernetes con la cantidad de proyectos que se requieran, o se pueden ampliar y reducir la arquitectura de Kubernetes con la cantidad de microservicios que se requieran.
  De forma general, esta es una herramienta muy útil para grandes empresas que desean automatizar los procesos de despliegue de aplicaciones con microservicios y utilizan contenedores, ya que permite la escalabilidad y la optimización de sus despligues, se trataría entonces de empresas que desarrollan varios y grandes, y complejos productos de Software.
  Este Software, fue creado por la empresa Google, con la intención de optimizar el uso de recursos de hardware, pues como sabemos se trata de una empresa que maneja un gran Software de Navegación de la web como Google Chrome y otros grandes productos, por lo que se requieren tecnologías que permitan gestionar los recursos de sus aplicaciones. Kubernetes, es luego liberado por la fundación Linux y se vuelve de código abierto ó open source.
  Para saber más sobre Kubernetes, recomiendo acceder a la web oficial: https://kubernetes.io/ y revisar la documentación oficial.