Categories
54cuatro

Diseño y Desarrollo de Aplicaciones aplicando SOLID

Si hablamos de diseño y desarrollo de #aplicaciones, Cuando mencionamos el principios #SOLID nos referimos a un acrónimo con 5 definiciones que nos ayudan a determinar los patrones de la #arquitectura y el #desarrollo de #software.

Los 5 principios SOLID

Los objetivos de estos 5 principios a la hora de escribir código son los de crear un software que cumpla con el objetivo por el cual fue creado y que sea robusto y estable. El código debe ser limpio y fácil de mantener. El código debe ser reutilizable y mantenible, de manera que puedan incorporarse cambios, nuevas funciones y mejoras de manera ágil. Los 5 principios son:

  • S – Single Responsibility Principle (SRP)
  • O – Open/Closed Principle (OCP)
  • L – Liskov Substitution Principle (LSP)
  • I – Interface Segregation Principle (ISP)
  • D – Dependency Inversion Principle (DIP)

Principio de Responsabilidad Única

La primera letra del acrónimo. Es el principio más importante. La responsabilidad única refiere a la definición teórica que indica que “una clase debería tener una, y solo una, razón para cambiar”, es decir que cada clase que definamos debe tener una única responsabilidad. Si nos encontramos que para agregar una nueva funcionalidad debemos modificar más de una clase o que nuestro software tiene muchas relaciones entre sus clases, evidentemente no estamos cumpliendo este principio.

Principio Abierto/Cerrado

En este principio, se entiende que una entidad de software (clase, módulo, función, etc)  deberían estar abiertas para poder extenderse (lo que significa que una entidad de software debe poder adaptarse a los cambios y nuevas necesidades) y cerradas para modificarse (significa que la adaptabilidad de la entidad se da como resultado de un diseño que facilite la extensión sin modificaciones, no por modificaciones realizadas en el core de dicha entidad)

Principio de Sustitución de Liskov

En el punto 3, se da nombre a este principio gracias a Barbara Liskov, la primera ingeniera en lograr el doctorado en Ciencias de la Computación. El principio de Liskov brinda pautas para trabajar con la herencia entre clases. La principal que debe cumplir si estamos realizando la herencia de una manera correcta es que cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. Los objetos deben poder ser reemplazados por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema.

Principio de Segregación de la Interfaz

En este método se hace hincapié, en hacer interfaces específicas, es decir, tener interfaces con pocos métodos para finalidades concretas. Las interfaces nos dan una capa de abstracción que nos ayudan a desacoplar módulos; por lo tanto la interfaz es lo que nos da el comportamiento que nuestro código espera para comunicarse con otros módulos a través de métodos y propiedades.

Principio de inversión de dependencias

Último de los principios de SOLID. En este último punto, se especifica cómo deben ser las relaciones entre componentes para evitar el acoplamiento entre los módulos de un software, lo que busca reducir las dependencias entre los módulos del código para lograr un bajo acoplamiento de las clases.

Conclusión

SOLID tiene muchos detractores que suelen indicar entre sus criticas que solo toma algunos principios muy generales para un buen diseño de software de programación orientada a objetos y luego les coloca etiquetas.

Los principios SOLID son una guía de buenas prácticas, que están relacionados entre sí de forma muy estrecha y que al aplicarlos en nuestros desarrollos facilitan la creación de un código limpio, con menor acoplamiento, más flexible, más estable y más fácil de mantener.


[popup_anything id=”2076″]

Categories
54cuatro

DevOps, DataOps… ¿Y ahora? GitOps

Ya hemos hablado de DevOps, de DataOps, y con el correr del tiempo se incorporan nuevos *Ops.

Mas adelante vamos a escribir de #MLOps, pero ahora vamos a ver de que se trata #GitOps.

¿De donde sale GitOps?

Weaveworks on Twitter: "Great article on #GitOps by @wbiller: "GitOps –  Continuous Deployment für Kubernetes". #CICD #kubernetes #k8s  https://t.co/nUi05zj9DR… https://t.co/PH2fn1qZmc"

GitOps surge principalmente de la necesidad de administración de clústeres de Kubernetes y la entrega de aplicaciones. Para esto es necesario usar #Git, la herramienta numero 1 de #desarrollo. GitOps, se basada en usar Git como única fuente de verdad para aplicaciones e infraestructura declarativa, de esta manera, las herramientas de #GitOps como #ArgoCD (la cual pueden ver como funciona en este post) puede alertar sobre cualquier diferencia existente entre Git y lo que está configurado en K8s, y si hay una diferencia, los reconciliadores de Kubernetes actualizan o revierten automáticamente la configuración. El objetivo por cierto es acelerar y simplificar las implementaciones de aplicaciones como las tareas de operaciones en Kubernetes.

¿GitOps es un reemplazo de DevOps?

Nos suelen hacer esta pregunta cuando hablamos de DevOps. Y la respuesta es: NO!

DevOps es una practica que tiene en cuenta factores culturales, de procesos y de tecnología. En DevOps, la cultura es parte fundamental para asegurarse de que las personas se alineen y trabajen de forma fluida. Pero GitOps incluye aquellas mejores prácticas que unifican la implementación, la gestión y la supervisión de aplicaciones, y la administración de clústeres de #containers.

GitOps por tanto, es un complemento de DevOps, con mayor orientación al desarrollo Cloud Native, Container First, o Serverless.

Además del repositorio de codigo, GitOps hace uso de herramientas de IaC (infrastructure as code) con el fin de administrar los despliegues de infraestructura con un control de versionado de la misma. Herramientas como #Puppet, #Ansible o #Terraform, permiten desplegar servidores y orquestar su implementación, pero el crecimiento exponencial del uso de contenedores junto al despliegue de las aplicaciones que corren sobre ellos potenció la necesidad de contar con herramientas que además de la infra puedan orquestar el despliegue aplicativo.

De esta manera, “recetas” de despliegue de infraestructura pueden ser respaldadas en Git para que sus archivos de configuración puedan ser “mergeados” con flujos de trabajo GitOps. Esto genera una super receta que al ejecutarse permitirá desplegar un servidor junto con su aplicación, con un control exacto de versiones.

¿Cuál son sus beneficios?

  • El principal es el de simplificar las administraciones de las implementaciones. La configuración de las aplicaciones y sus entornos de implementación son realizadas de manera declarativas (yaml/json).
  • Existe un control de versiones tanto de la infra como de las apps. Cualquier desviación de la configuración de versión es detectada y corregida de inmediato.
  • Todos los despliegues permiten una rápida vuelta atrás, además de dejar un registro de auditoria de sus ejecuciones.
  • Las implementaciones de aplicaciones son rápidas y confiables.

[popup_anything id=”2076″]
Categories
54cuatro

Mejorando el desarrollo de software con CMMI

Que es CMMI?

Capability Maturity Model Integration (#CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Administrado por el Instituto CMMI, una subsidiaria de ISACA, se desarrolló en la Universidad Carnegie Mellon (CMU). Es una metodologia requerida por muchos contratos del Departamento de Defensa de los Estados Unidos (DoD) y del Gobierno de los Estados Unidos.

Pero no es únicamente un requisito para ser proveedor del estado de #EEUU, también es una metodología que permite a las empresas que lo implementan a obtener mucha mas productividad y calidad en sus códigos, ademas de una mejor duración del ciclo de vida y presupuestos controlados, siendo más precisos y predecibles.

CMMI persigue estos objetivos:

  • Brindar un marco que ayude a la organización a mejorar sus procesos de #desarrollo.
  • Brindar una guía para mejorar la capacidad de #desarrollar, #adquirir y #mantener productos o servicios proporcionados por una organización.
  • Describir un conjunto de buenas prácticas, tanto en #gestión como en #ingeniería.

Para ello, CMMI abarca tres disciplinas: el desarrollo de procesos y servicios, la gestión de servicios y la adquisición de productos y servicios, que siguen estas practicas:

  • Modelo de Madurez de Capacidad Integrado para el Desarrollo (#CMMI-DEV). Centrado en prácticas para desarrollar productos o servicios con una calidad estandarizada con el objetivo de satisfacer las necesidades de los consumidores.
  • Modelo de Madurez de Capacidad Integrado para Servicios (#CMMI-SVC). Modelo en el que se apoyan las empresas proveedoras de servicios. Las prácticas que emplea abarcan desde decidir qué servicios ofrecer, los sistemas para implementarlos, los acuerdos con los clientes, los cambios en la logística, entre otras.
  • Modelo de Madurez de Capacidad Integrado para Adquisición (#CMMI-ACQ). Ofrece las mejores prácticas enfocadas en actividades de iniciación y manejo de adquisiciones de productos, servicios, herramientas o equipos. Todas ellas brindan beneficios para la compañía y la ayuden a satisfacer a los usuarios finales.

El Modelo CMMI considera 5 niveles de madurez, medibles para la organización:

  1. Inicial
  2. Gestionado
  3. Definido
  4. Gestionado cuantitativamente
  5. Optimización

En el nivel de madurez 1 (Inicial), la organización se caracteriza por la naturaleza ad hoc de sus procesos. La organización no proporciona un entorno estable para la creación de sus productos, por lo que el éxito de sus proyectos depende exclusivamente de las habilidades de las personas dedicadas a cada uno de ellos.

En el nivel de madurez 2 (Gestionado), los proyectos de la organización realizan los procesos de acuerdo a lo planificado y definido en las políticas de la organización, empleando a personas capacitadas que poseen el conocimiento requerido, involucrando a todos los actores relevantes, y monitoreando, controlando y revisando todos los procesos.

En el nivel de madurez 3 (Definido), todos los procesos son entendidos y descritos a través de estándares, procedimientos, herramientas y métodos.

En el nivel de madurez 4 (Quantitatively Managed), la organización y los proyectos establecen objetivos cuantitativos para medir la calidad de los procesos así como su uso, y los criterios necesarios para su gestión. Se utilizan métodos estadísticos para controlar los procesos.

En el nivel de madurez 5 (Optimización), la organización aplica la mejora continua de sus procesos a través de la comprensión cuantitativa de las causas de variación comunes al proceso, utilizando métodos estadísticos que avalan la mejora continua.

Conclusión

Los niveles de madurez son acumulativos, es decir, para alcanzar cada uno de ellos es necesario implementar todas las áreas específicas del proceso en ese nivel, así como todos los niveles inferiores. CMMI es una buena forma de demostrar la madurez de sus procesos a clientes, y a su vez, conocer la de sus proveedores, pero aún sin pasar por la evaluación formal, adoptar las buenas prácticas sugeridas por CMMI puede aportar una mejora significativa a los procesos de desarrollo de software.

[popup_anything id=”2076″]

Categories
54cuatro

DevOps y SRE tienen coincidencias y diferencias.

Post para compartir con tu amigo Recruiter: #DevOps y #SRE tienen coincidencias y diferencias.

La génesis de ambos movimientos tienen características similares: El choque entre #Equipos de #Desarrollo que empujan sus esfuerzos hacia la creación de nuevas características, y el Equipo de #Operaciones que empuja sus esfuerzos en mantener la producción estable.

SRE fue pensado por Google como responsable de la estabilidad del entorno de producción, pero al mismo tiempo comprometidos con los nuevos desarrollos y la mejora continua. Y los equipos de SRE se componen en partes iguales por perfiles de Desarrollo y Sysadmins.

DevOps, es mas reciente, pero comparte el objetivo de construir un lazo laboral entre los sectores de Desarrollo y Operaciones siguiendo principios #Ágiles y fomentando la colaboración. Ambos enfoques buscan objetivos comunes como la mejora del #Time2Market, la colaboración, la automatización, y mejorar de forma constante. Pero mientras que DevOps busca cerrar una brecha colaborativa, SRE es un sistema donde el desarrollo controla la operación, incluyendo el monitoreo. Se puede implementar tanto DevOps como SRE ya que ambos enfoques no entran en conflicto.

DevOps generalmente se centra en el “qué”, mientras que SRE se centra en el “cómo”. #CreciendoConProposito

[popup_anything id=”2076″]