Introducción a Microservicios
¿Qué es una empresa?
- Una sola organización
- Partes de una gran organización (como una unidad de negocios)
- Una colección de organizaciones que colaboran en una cadena de valor.
- La palabra "Empresa" cubre un amplio espectro de entidades organizacionales
Realidad actual
- La realidad empresarial actual es significativamente diferente de la de los años sesenta y setenta. La naturaleza de los problemas, las oportunidades y el entorno empresarial que enfrentan las empresas hoy en día son significativamente diferentes a las décadas anteriores.
- Las empresas se ha vuelto cada vez más dinámicas y complejas. El papel de la TI dentro de las empresas tomó muchos giros inesperados en el camino. La mayoría de las empresas ven la TI como una competencia básica fundamental. El ritmo del cambio solo se está acelerando.
Arquitectura Empresarial
- Desde el punto de vista etimológico, la arquitectura es el oficio de los maestros constructores.
- La arquitectura empresarial es una disciplina que permite diseñar la empresa de manera consciente y deliberada, en lugar de dejar que ocurra al azar.
- El diseño se basa en la visión empresarial, la intención estratégica y los conocimientos sobre el funcionamiento de la empresa.
- La arquitectura empresarial se puede interpretar como "el arte de crear un plan de ejecución para la empresa".
- La arquitectura empresarial adopta vistas tanto atómicas como holísticas de la organización. Tener una visión de todo los activos tecnológicos (procesos de negocio, información, infraestructura, etc) y ver como se relacionan.
- TOGAF (The Open Group Architecture Framework) es un marco de referencia para planificar, diseñar e implementar la arquitectura empresarial de una organización.
¿Por qué necesiamos arquitectura empresarial?
- Históricamente, surgió como un mecanismo para manejar la complejidad de la implementación de sistemas de TI.
- En el camino, el papel de EA se transformó para abordar la arquitectura de toda la empresa en lugar de solo los componentes de TI.
Interesados (Stakeholders)
- Desarrollador, Administrador del sistema, Analista de sistemas / negocios
- Gerentes/jefes de proyecto
- Técnico/arquitecto de soluciones
- Arquitecto empresarial
- Altos ejecutivos y gerentes
Contenido de la arquitectura empresarial
Dominios de la arquitctura empresarial
- La arquitectura de negocio define los procesos de negocio.
- La arquitectura de tecnología define la infraestructura necesaria para soportar los procesos de negocio.
- La arquitectura de sistemas de información se subdividen en dos tipos:
- Arquitectura de información: Bases de datos, explotación de la información, BI, Big Data, etc.
- Arquitectura de aplicaciones: Aplicaciones que dan soporte a los procesos de negocio.
Arquitectura de aplicaciones
- En las últimas décadas, las empresas han invertido mucho en aplicaciones comerciales en todos los sectores industriales.
- El arquitecto de aplicaciones empresariales crea una hoja de ruta de cartera de aplicaciones de estado obetivo, teniendo en cuenta:
- Costo total de cambio
- Rendimiento de las inversiones
- Riesgos y camino de menor resistencia
- El estado objetivo podría incluir:
- Brechas identificadas en las capacidades de la aplicación
- Decisión de retirar el envejecimiento y las aplicaciones de bajo valor
- Modernización de aplicaciones heredadas pero de valor alto
- Eliminar la redundancia
- Estandarización en plataforma tecnológica común.
- Consolidando aplicaciones.
¿Qué es arquitectura de software?
- Nos metenemos en una aplicación en concreto y vamos a ver como está diseñado internamente. A este diseño nos referimos con arquitectura de software.
- Cuando las personas en la industria del software hablan de "arquitectura" se refieren a una noción definida de los aspectos más importantes del diseño interno de un sistema de software.
- Una buena arquitectura es importante, de lo contrario se vuelve más lento y más caro agregar nuevas capacidades.
- El objetivo de una arquitectura es darle valor al cliente. Esto implica que el arquitecto tenga conocimientos de negocios, gestión y técnicos (infraestructura, lenguajes, frameworks, patrones, etc.)
- Las arquitecturas no son buenas y malas, sino que van a depender del contexto donde las hayas aplicado.
- Microservicios es un estilo arquitectónico para realizar una aplicación.
- Cuando realizamos la arquitectura de un software tenemos que tener en consideración lo siguiente:
- Codificación de una interfaz
- Servicios
- Pruebas automatizadas
- Domain Driven Design
- Acceso a datos
- Arquitectura en capas
- Estructura a alto nivel de capas, componentes y la relación entre estas.
- Niveles de abstracción arquitectónica
Arquitectura desordenada vs limpia
- ¿Cuándo una arquitectura es mala?
- Compleja. Cuanto más simple, más perfecto.
- Incoherente. Se espera que haga algo, pero hace otra cosa.
- Rígido. No es fácil modificar.
- Frágil.
- Inestable.
- Insostenible.
- ¿Cuándo una arquitectura es buena?
- Sencilla
- Comprensible
- Flexible
- Emergente
- Testeable
- Mantenible
Aplicaciones monolíticas
- Una aplicación de software de un solo nivel en el que la interfaz de usuario y el código de acceso a datos se combinan en un solo programa desde una sola plataforma.
- Acoplamiento vertical (capas). Separación lógica.
- Acoplamiento horizontal (niveles). Separación física.
- Manejos de solicitudes dentro de un monolito. En en el siguiente ejemplo, tenemos varios componentes lógicas que están en único componente físico. Hay una dependencia entre componentes.
- En un monolito, solo hay un único repositorio de datos. Por otro lado, un "monolito modular", cada componente tiene su propia base de datos.
- Si hay dependencias entre componentes (a pesar que cada componente tenga su propia infraestructura) sigue siendo un monolito. Monolito distribuido.
- Beneficios de las aplicaciones monolíticas:
- Fácil de desplegar
- Bien conocidas
- Sin dependencias externas
- Amiable con los IDE's. Los monolitos están orientados a una única tecnología.
- Posibles problemas de los monolitos:
- Síncrono. No puedo hacer un procesamiento en paralelo
- Gestión de errores entre componentes. Si un componente falla, entonces toda la aplicación muere.
- Sobrecarga. Embotellamiento.
- Múltiples equipos modificando los mismos componentes.
- Desventajas de las aplicaciones monolíticas:
- Complejo y difícil de mantener
- Tiende a complicarse con el tiempo
- Despliegue trabajoso (mucha labor de coordinación)
- Problemas de rendimiento
- Baja confiabilidad (degradación)
- One Stack (una sola tecnología)
- Ejemplo de monolito: Todo los componentes en un único compilado
- Con el transcurrir del tiempo el monolito fueron un problema para soportar procesos grandes.Es así como nace SOA para resolver esta problemática.
Computación Distribuida
- Con el pasar del tiempo la computación fue evolucionando hacia una comunicación distribuida.
- Un sistema distribuido es una aplicación de software en la que los componentes están ubicados en computadoras en red y se comunican y coordinan sus acciones emitiendo llamadas o pasando mensajes.
- Es aquí donde surge el concepto de Servicios. Al tener una composión de servicios debemos tener una forma de gobernar/gestinar estos servicios. Quien dio la pauta en este asunto fue SOA
- SOA monta los cimientos para los microservicios. Si quiero aprender como gobernar los servicios entonces entonces tengo que estudiar sobre SOA. Se puede aprovechar la fusión de microservicios y SOA.
- Cuando hacemos aplicaciones distribuidas tenemos que tener en consideración las "falacias de la computación distribuida". Cuando diseñamos una arquitectura distribuida debemos tener en cuena estos aspectos.
- La red es confiable
- La latencia es cero
- El ancho de banda es infinito
- La red es segura
- La topología no cambiará
- Hay un administrador
- El costo de transporte es cero
- La red es homogénea
- Una arquitectura distribuida puede generar 3 tipos de acoplamiento:
- Por Plataforma: Para que todos mis servicios funcionen tienen que estar en una misma tecnología.
- Comportamiento: Tengo que conocer de antemano la firma, la interfaz.
- Temporal: Dependencia entre servicios. Para que un componente pueda cumplir un objetivo necesita invocar otro componente y este a otro, etc.
- Tecnologías de comunicación antiguas (COM+, RMI, CORBA, SOAP).
- WCF fue un framework que agrupa varias tecnologías de comunicación. Luego, la industria se dio cuenta que lo mejor era estandarizar los mecanismos de comunicación. El primer estándar fue SOAP utilizando XML. Luego apareció REST.
- La comunicación entre los componentes distribuidos usualmente se hacía a través de "Remote Procedure Call".
¿Qué es Arquitectura SOA?
- Es un estilo de arquitectura que permite el diseño una aplicación orientación a servicios.
- SOA es el resultado de contribuciones colectivas de la industria de la informática y no puede ser atribuida a un solo individuo o empresa.
- Muchas de las cosas de Microservicios nacen con SOA. Tanto Microservicios como SOA manejan arquitectura de sistemas distribuidos, pero no son lo mismo.
- SOA nace debido a la computación de sistemas distribuidos.
- Se maneja 3 elementos fundamentales:
- Servicios
- Contratos
- Mensajes
- Objetivos y beneficios estratégicos
- Incrementar la interoperabilidad intrínsica. Posibilita el consumo de servicios.
- Incrementar la alineación de TI con el negocio. Ahora que los componentes estan elevados a servicios implica tener una forma de catalogarlos y organizarlos en función de las capacidades de negocio.
- Agilidad orgnizacional.
- Incrementar el ROI.
- SOA me va a dar un planteamiento sobre cómodo estructurar tu aplicación y cómo gobernar los componentes distribuidos.
- Elementos - Servicio
- Unidad fundamental de SOA
- Un contenedor de una o muchas capacidades
- Deiseñado con capacidades reutilizables
- Servicios como: Web Services, Components, REST Services.
- Elementos - Contratos
- El contrato expresa información acerca del servicio, sus capacidades y tipos de datos.
- Un servicio consumidor debe cumplir con los requerimientos expuestos en el contrato.
- La parte fundamental del contrato del servicio es su interface técnica.
- El contrato del servicio se puede complementar con un documento de SLA que describa información adicional de características y limitaciones.
- El como se diseñen y existan físicamente los servicios dependen sobre la tecnología que se utiliza para crear el servicio.
- El principio de estandarización del contrato es dedicado a la definición del contrato, aspecto muy importante para lograr beneficios estratégicos.
- Principalmente un sistema con arquitectura SOA utilizaba SOAP. En SOAP el contrato estaba definido en un lenguaje llamado WSDL que estaba hecho en XML y contenía políticas de seguridad.
- Elementos - Mensajes
- Unidad de comunicación de los servicios
- La estandarización de los mensajes permite:
- La interoperabilidad intrínseca
- Reducir costos de mantenimiento
- Eliminar el uso de transformaciones que impactan el rendimiento
- Composición
- Agregación coordinada de servicios
- Reutilización de capacidades para diferentes procesos de negocio
- Principios de diseño recomendados por SOA
- Estandarización del contrato
- Bajo acoplamiento del servicio
- Abstracción del servicio
- Capacidad del servicio de ser reutilizado
- Autonomía del servicio
- Servicio sin estado
- Capacidad del servicio de ser descubierto e interpretado
- Capacidad del servicio de ser compuesto
- Problemas del EBS (Enterprise Service Bus) - Motivos por el cual los sistemas basados en SOA empezaron a tener problemas. Las empresas no siguen los principios propuestos por SOA.
- Te obligaba que tus servicios estén en una única tecnología
- Servicios muy pequeños
- Permitía meter lógica en el componente de comunicación.
- Con el pasar del tiempo la industria ha ido estandarizando los mecanismos de comunicación. Es aquí donde entra a tallar RPC y REST.
- ¿Qué es RPC?
- Llamar a un método de manera remota.
- Del lado del cliente se tiene que implementar el contrato que está definido en el servidor.
- En el cliente tenemos los proxies que envían información a través de la red y hace un request al servidor.
- Tecnologías que implementan el algoritmo RPC: .NET Remoting, Java RMI. Presentaron los siguientes problemas:
- Alto acoplamiento a nivel de plataforma (o utiliza .NET o Java)
- Alto acoplamiento a nivel de comportamiento. Se tiene que conocer la interfaz para construir un proxy de consumo.
- Alto acoplamiento temporal. Era síncrono.
- Luego la industria creo un estándar de comunicación de mensajes llamado SOAP (Simple Object Access Protocol).
- Bajo acoplamiento a nivel de plataforma
- Alto acoplamiento a nivel de comportamiento
- Alto acoplamiento a nivel temporal
- Sigue la evolución y llegamos a lo que es REST.
- ¿Qué es REST?
- Según el patrón de madurez de Richardson, REST maneja 4 niveles:
- Con REST tenemos los siguientes tipos de acoplamiento:
- Bajo acoplamiento a nivel de plataforma.
- Bajo acoplamiento a nivel de comportamiento. No hay necesidad de construir un proxy, pero si se debe conocer el contrato.
- Alto acoplamiento a nivel temporal.
- La industria definió usar JSON porque es más ligero.
- ¿Porqué REST desplazó a SOAP? Por la explosión de los dispositivos móviles. Las aplicaciones móviles que consumen servios SOAP implica la deserialización de los mensajes lo cual hacía que el procesador del dispositivo trabajara más, lo cual implicaba el consumo rápido de la batería.
- La interfaz de SOAP es WSDL minetras que REST no lo tiene. Sin embargo, existe el estándar OPEN API que permite documentar un servicio (La herramienta conocida para esto es Swagger).
- GraphQL
- No es una tecnología, sino una lenguaje de consulta paras API
- Para usar GraphQL como mecanismo de comunicación hacemos un símil de como lo haríamos con REST:
- Diferencias entre GraphQL y REST
- Ejemplo de código de GraphQL
- gRPC
- Actualmente lo que se busca en la comunicación de componentes distribuidos es mejorar la performance.
- gRPC es una implementación de algoritmo RPC por parte de Google. En lugar de transmitir texto se transmite binario.
- Se utiliza mucho para la comunicación entre servicios.
- Ejemplo de código de gRPC:
- ¿Qué son los microservicios?
- Ciclo de vida de desarollo de Software
- Tenemos que tener la mentalidad del desarrollo de producto no de un proyecto.
- Los microservicios ayudan a tener una visión de desarrollo diferente.
- Para construir un producto hay que considerar las siguientes etapas: requerimientos, planificación y diseño, desarrollo, pruebas, despliegue, monitoreo y mantenimiento.
- Los que participan en el ciclo de vida son: analistas, equipo de desarrollo, equipo de coordinación, equipo de operaciones.
- ¿Cómo entra a tallar microservicios dentro del ciclo de vida de una aplicación?
- Nos provee de un conjunto de prácticas que nos permite aumentar la velocidad del ciclo del desarrollo de software.
- Nos ofrece una estructura escalable dentro de nuestra aplicación.
- Tecnología agnóstica.
- Siempre tenemos que estar apalancados en principios y patrones arquitectónicos.
- Etimología de microservicio. En lugar de microservicio, debió llamarse microaplicación.
- Micro
- De una aplicación grande tenemos que ir hacia algo más pequeño
- ¿Cuál es el tamaño de un microservicio? No existe. No hay ninguna medida universal. Sin embargo, podemos poner parámetros para delimitar que tanto puede hacer un microservicio, por ejemplo, que haga una sola función de negocio (clientes, pagos, facturación, reportería, etc.).
- Un microservicio va a estar abocado a una capacidad de negocio. Un mononolito puede ocupar más de una capacidad de negocio.
- Se aboca a un contexto limitado.
- Servicio
- Debe ser un componente desplegable independientemente. Si un servicio se cae y otro depende de este, entonces no cumple con este requisito.
- Comunicación basada en mensajes.
- Arquitectura orientada a servicios (SOA)
- El estilo arquitectónico de microservicios es un enfoque para desarrollar una sola aplicación como un conjunto de pequeño servicios, cada uno de los cuales se ejecuta en su propio proceso y se comunica con mecanismos ligeros (James Lewis and Martin Fowler, Thoughtworks).
- Microservicios es un estilo de arquitectura de software, en el que las aplicaciones complejas se componen de pequeños procesos autónomos que se comunican entre sí mediante API independientes del lenguaje (cualquier tecnología).
- ¿Cuál es la diferencia entre microservicio y servicio? Microservicio es un apelativo que se le da a un servicio que forma parte de una aplicación distribuida.
- Microservicios implica romper un monolito en múltiples componentes que son independientes.
- Elementos de un microservicio
- Cuando creamos una aplicación con una arquitectura de microservicios no solo hay que tener en cuenta la descomposición de componentes de la aplicación, sino también como será el despliegue, como se va a comunicar, la seguridad, que equipo se hará cargo de un determinado microservicio, que arquitectura de datos será la mejor para tal o cual proceso, que infraestructura usar para toda la aplicación, como segurizar la aplicación de manera interta/externa, la observabilidad/monitorización, etc.
- ¿Son los microservicios adecuados para mi organización?
- Beneficios de los microservicios
- Pequeños servicios: Puede ser propiedad de un equipo. Más fácil de entender. Puede ser reescrito.
- Elección de tecnología: Adopta nueva tecnología. Usa la herramienta adecuada. Estandarizar donde tiene sentido.
- Despliegue individual: Menor riesgo. Minimiza el tiempo de inactividad. Actualizaciones frecuentes.
- Escalabilidad: Escalar servicios individualmente. Económico.
- Agilidad: Adaptarse rápidamente. Reutilización más fácil.
- Desafíos de los microservicios
- Productividad del desarrollador: ¿Cómo podemos facilitar que los desarrolladores sean productivos trabajando en el sistema? Mayor esfuerzo de desarrollo. Tengo que levantar múltiples componentes en mi entorno de desarrollo.
- Interacciones complejas: Tenga cuidado realizando comunicaciones ineficientes e innecesarias entre microservicios. Puedo comunicar dos servicios de forma directa o través de un bus de mensajes. Mantener la consistencia de la información es mucho más complejo.
- Despliegue: Necesitas automatizar el proceso. Las aplicaciones grandes corporativas si tienen sentido de utilizar microservicios, y poría haber un caso de tener más de 150 servicios. El despliegue manual es este caso no sería recomendable. Es por esto que la automatización va ligado a microservicios.
- Monitoreo: Necesitamos un lugar centralizado para verificar los registros y monitorear los problemas.
Comments
Post a Comment