Categories
54cuatro

Como migrar VMware a IBM Cloud

En 2016, VMware e IBM formaron una asociación estratégica para proporcionar a los clientes acceso a un entorno VMware nativo “llave en mano” en los centros de datos de IBM Cloud. Los clientes de VMware pueden “levantar y cambiar” y, en última instancia, transformar sus entornos locales en IBM Cloud sin necesidad de refactorizar sus aplicaciones y cargas de trabajo.

IBM tiene 10 motivos para migrar #VMware hacia #IBMCloud:

Acceso a hipervisor y administrador completo

VMware Solutions en #IBM Cloud les brinda a los clientes acceso completo e #hipervisor y acceso administrativo completo a vCenter, PSC, NSX y cualquier servicio adicional. Los clientes que implementan su entorno VMware en IBM Cloud poseen el mismo control, seguridad y funcionalidad que tienen con su entorno local.Proporcionamos un entorno VMware completamente nativo, que no requiere cambios en las herramientas o procesos existentes. La única diferencia es que se consume en un modelo de nube.

Múltiples configuraciones de SDDC y opciones de hardware

Entendemos que los clientes tienen diferentes requisitos y hemos incorporado flexibilidad en nuestra solución. Los clientes pueden elegir entre dos configuraciones automatizadas de centros de datos definidos por software (SDDC)- VMware vCenter Server (VCS) y VMware CloudFoundation (VCF), que se aprovisionan automáticamente en horas a Centros de datos en todo el mundo. Dentro de VCS y VCF, los clientes pueden adaptar el entorno a sus cargas de trabajo porque ofrecemos seis opciones de cómputo diferentes, nueve opciones de RAM y dos tipos de almacenamiento (vSAN y NFS), que brindan más de 100 opciones diferentes.

Soporte de traiga su propia licencia (BYOL)

Los clientes han invertido una cantidad significativa de recursos y dinero en sus licencias de VMware. Reconociendo las implicaciones comerciales, permitimos a los clientes BYOL sus licencias de VMware, que se aprovisionan automáticamente con un entorno VCS y VCF. Damos soporte BYOL para vCenter Server, vSphere, NSX y vSAN.

Gestionado por el cliente

Al comprender que los clientes tienen sus propias prácticas, diseñamos VMware Solutions en IBM Cloud para que sean administrados por el cliente, lo que permite a los usuarios utilizar los mismos procesos y la administración que utilizan en sus instalaciones. Estosignifica que los clientes no están obligados a instalar parches y actualizaciones, y como administran su entorno, pueden usar herramientas adicionales como vRealize Automation, vRealize Log Insight y cualquier solución. VMware Solutions en IBM Cloud es una extensión del entorno en las instalaciones de los clientes.

Queres conocer mas?

Categories
54cuatro

Gestionando los legados

No esta mas el que lo desarrolló. Esta hace muchos años y nadie sabe como funciona. No tenemos soporte del proveedor.

Te parecen conocidas estas frases? Son algunas de las muchas que se escuchan dia a dia en las organizaciones ante la imposibilidad de actualizar sus sistemas legados.

¿Qué son los legados?

Podriamos definirlos como esos programas que nadie quiere tocar, nadie sabe quién lo escribió y que absolutamente nadie quiere correr el riesgo de reemplazarlo.

Podemos citar muchos casos de software legado que actualmente es de vital importancia en las organizaciones, por ejemplo los core banking o tasadores de Telcos.

¿Y porque nos encontramos con esta situación? Principalmente estas situaciones se dan cuando un software pierde su ciclo de actualización constante, y ante esa situación se comienza a perder conocimiento, se empiezan a ir los recursos claves que lo mantienen y ante esa situación cada dia se aísla mas del dia a dia. Para evitar que un software quede obsoleto, se requiere mejorarlo gradualmente y llevarlo a estándares de forma continua.

¿Cómo gestionar una aplicaciones legacy?

Reescribir el código (#rewrite): esta opción es compleja, porque básicamente se basa en rearmar el programa con las mismas funcionalidades, pero con tecnología y practicas apropiadas al momento actual. La mayor complejidad de esto es tener que mantener dos sistemas similares funcionando, y posteriormente ir pasando “carga” del viejo al nuevo o directamente volcar todo el trafico de un sistema a otro en un formato “big bang”.

Refactorizar el código (#refactor): esta opción se basa en reemplazar las funcionalidades del sistema antiguo, gradualmente. Esta estrategia consiste en relevar cada función, interface, clase, modulo, etc del sistema antiguo y construir una nueva pieza de software de ese elemento particular. Durante el refactoring, es posible detectar funcionalidades que ya no son necesarias, y a ellas se las deja “morir por inanición”.


¿Reescribir o Refactorizar?

Lógicamente es necesario analizar cada situación. No es lo mismo Reescribir todo un Core Bancario, que Refactorizar una aplicación para que deje de usar #MySQL para usar #MongoDB.

Se debe tener en claro cual es el aporte de valor de cada estrategia de cara al negocio. Posteriormente es bueno efectuar un assessment que permita situar el nivel de complejidad de la operatoria.

  • Relevamiento del software, interfaces, integraciones, etc.
  • Identificar la complejidad de las tareas
  • Identificar los riesgos
  • Definir con que enfoque se planeará la modernización de aplicaciones, apostando a disminuir el riesgo y los costos.

Planeando la nueva arquitectura

¿Estamos rediseñando una aplicación monolítica? ¿Es SOA? ¿Es Rest? ¿Crearemos #API? ¿Vamos a la nube? ¿Adoptaremos microservicios? ¿Usamos contenedores? ¿#Serverless, eso que es?

No es lo mismo pasar de .NET a .NET Core, que modificar un desarrollo en Cobol.

Es muy importante definir cual será el diseño futuro que “absorberá” a nuestro legado. Y de esa forma planificar cuales serán los pasos apropiados. Si de una app de baja complejidad tipo monolito vamos a ir a un esquema de #microservicios o #serverless es una buena oportunidad para reescribir desde cero. Pero si el sistema heredado en cuestión es el core de su negocios, no puede darse el lujo de correr riesgos innecesarios, y para este caso, es preferible optar por una refactorización progresiva. De igual forma, si las personas que hicieron originalmente al sistema legado ya no están en la compañía, tampoco tiene sentido refactorizar y será más fácil reescribirlo.

What is a Mainframe Computer? - A Guide from IBM Mainframes

Como vemos, no existe una tabla que resuelva las decisiones mágicamente. A veces, en ciertas oportunidades la refactorización de código es la mejor opción, por seguridad o por practicidad. Pero la refactorización de código en otros casos puede brindar una ganancia rápida en términos de capacidad de mantenimiento y rendimiento, construyendo nuevamente desde 0.

Existe un tercer modelo que podemos denominar Rehosting, y consiste en realizar un proceso llamado ‘Lift & Shift‘. Esta actividad tiene como finalidad levantar una aplicación legada y moverla a un nuevo entorno, ya sea #cloud, o #container, o #serverless. Esta opción es muy interesante para mover aplicaciones sin tener que esforzarse mucho en hacer una reescritura sustancial, en líneas generales, este tipo de procesos son de mucha utilidad para reducir la obsolescencia de hardware, pero como contra, es importante destacar que no tiene el valor que se encuentra en reestructurar la aplicación.

Desde 54cuatro estamos apoyando a las organizaciones a disminuir los riesgos que conllevan estas decisiones, a través de nuestros servicios de consultoría en Arquitectura con profesionales especializados en enfoques la modernización de aplicaciones que tienen en cuenta componentes de plataforma, arquitectura aplicativa y el diseño de API. Necesitas apoyo? Escribinos.

[popup_anything id=”2076″]
Categories
54cuatro

Open Banking en Latam

Entrada publicada en Medium.

El dinero es una parte central de la sociedad y de la vida de las personas. Es posiblemente uno de los inventos mas perdurables e innovadores de la historia, junto con la domesticación del perro, y además es la convención social de las mas valoradas. Siempre hemos tenido dinero en diferentes formas, piedras, monedas, billetes, y actualmente bitcoins.

Image for post
Photo by Marcelo Moura – FreeImages

El dinero debe cumplir con 3 funciones:

  • Ser una herramienta de intercambio, para efectuar pagos/transacciones.
  • Tiene que ser una herramienta de resguardo de valor/ahorro manteniendo su valor.
  • Tiene que ser una herramienta de paridad para comparar el valor de productos y servicios.

Gracias a Internet estamos viviendo una época de transformación nunca antes vista, solo comparable con invenciones como la rueda, el papel, la electricidad, el motor a vapor, y la penicilina. Y tenemos que entender como gran invento innovador fue el motor de grandes cambios sociales, de igual manera que lo que esta pasando en la actualidad con la forma de comprar, de consumir contenidos, y también por las finanzas.

Ante la proliferación de monedas como Bitcoin, billeteras electrónicas y otros tantos nuevos productos surge la duda… ¿Qué es Open Banking?

Podemos decir que #OpenBanking es un concepto por el cual las instituciones financieras acuerdan con sus clientes compartir la informacion de estos últimos con otras entidades por medio de mecanismos denominados #API, que permitan a todas las entidades conocer los datos financieros de una personas y de esa manera poder generar productos y ofertas personalizadas.

Open Banking mejorará la capacidad de hacer más actividades financieras desde el smartphone, aumentará la capacidad de manejar mejor los servicios financieros no bancarios puesto que mejorarán la innovación en los servicios y principalmente habrá mayores alternativas de servicios y de mayor calidad dada la competencia entre instituciones.

Pero veamos…. ¿Que es una API?

El término API es dado a una interfaz de programación de aplicaciones. Es una autentica navaja suiza dentro del desarrollo de software. Se trata de un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre dos aplicaciones de software a través de un conjunto de reglas. Podemos hablar de una API como una especificación formal que establece cómo un módulo de un software se comunica o interactúa con otro para cumplir una o muchas funciones. Todo dependiendo de las aplicaciones que las vayan a utilizar, y de los permisos que les dé el propietario de la API a los desarrolladores de terceros.

¿Cómo se benefician los clientes de un banco?

El objetivo principal es que el cliente tenga muchas opciones para elegir, y de esa forma el cliente final gana al obtener mejores ofertas y productos por parte de los bancos.

El desafío mas grande que tienen los bancos (y las #finteches generar confianza en los consumidores. La decisión más importante para los consumidores es probablemente a quién confiarle su dinero.

¿Y en el otro extremo, como se benefician los bancos?

Los bancos están trabajando muy fuerte en la modernización de sus sistemas core hacia esquemas full API descomponiendo sus sistemas monolíticos en componentes reutilizables (#microservicios), principalmente aprovechando esquemas de arquitectura basados en API. Para Open Banking, existen 2 tipos de API principalmente, una para obtener información de las personas y sus movimientos bancarios y otra para mover dinero en torno a pagos.

Por tal motivo, los bancos tienen que adecuar sus sistemas para que terceros puedan utilizarlos, lograr tener un banco programable. Es la colaboración llevada al sector de las finanzas. Ceder datos para que terceros desarrollen funcionalidades que antes los bancos guardaban para si mismos.

Como contrapartida, los los bancos tienen una mayor actividad bancaria.

Es importante aclarar que ser un proveedor de datos vía API no garantiza el éxito, los bancos además de adecuaciones tecnológicas tienen que hacer un cambio de mindset, y abrirse a buscar partners que cubran nichos con servicios especializados por ejemplo en cuanto a scoring.

¿Cuál es la situación de los países latinoamericanos?

Muchos paises están avanzando en la reglamentación de Open Banking. Ya hay una Ley Fintech en México, existen regulaciones en Brasil, en Chile ya se definen algunas reglamentaciones de servicios financieros basados en estándares de Open Banking, en Colombia el gobierno comenzó a trabajar con algunos hitos para un mayor desarrollo del sistema financiero. En Perú y Argentina no existen reglamentaciones aun, pero los expertos creen que pronto habrá avances en este sentido.

Mexico, Brasil, Chile, Colombia, Peru y Argentina son de los paises con mayor crecimiento de fintech, y seguramente la implementación en Open Banking sea recibida con buenos ojos por parte de los clientes. Existen buenas practicas como PSD2 y GDPR que dan marcos de buenas practicas por donde comenzar a delinear el futuro.

Vale destacar el caso de PSD2.

#PSD2 es una directiva europea que busca regular la competencia y fomentar la innovación en los mercados de pagos, aumentando la seguridad de los pagos y el acceso a las cuentas.

La normativa estipula dos tipos de entidades financieras:

  • PISP (Proveedores de Servicios de Iniciación de Pagos): quienes ofrecen la posibilidad de iniciar pagos a través de plataformas propias y conectar estas a los bancos para finalizar el pago.
  • AISP (Proveedores de Servicios de Información de Cuenta): que recogen información financiera del cliente de uno o varios bancos y la presentan de manera conjunta al cliente.

Las entidades no tienen que esperar a tener la reglamentación para comenzar a trabajar, basados en la experiencia europea ya se pueden iniciar actividades que permitan esperar la reglamentación en una posición muy competitiva.

Cada invento que marco un quiebre en su era, catapulto la generación de innovaciones sociales, bienvenidos a la era “Open Banking”.

Les dejo mi participación en el webcast de Open Banking para Jiran Consultores de la Ciudad de México.


[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

DevOps – Los desarrolladores están en el centro de la innovación

No solo sus competidores tradicionales lo reconocen: hay nuevos competidores que comienzan a lanzar #software innovador, trabajando dentro de su sector, pero al revés.

¿Usted elegiría software creado por un puñado de desarrolladores aislados o software creado por miles de personas que trabajan en colaboración para construir algo más sólido? 

Innove a gran escala. Confíe en lo que entrega.

Microsoft #Azure es la nube con servicios de desarrollador integrados y #GitHub construye sobre esta base para convertirse en la Plataforma #DevOps central de #Microsoft.

Aproveche Microsoft DevOps con GitHub para entregar innovación rápida y eficiente. ​

Innovación de producto

Herramientas de administración confiables y escalables en todos los niveles, además de una comunidad diversa detrás de todo

Rapidez de entrega

Para innovar, las empresas deben moverse rápidamente.

Flexibilidad y control

Cualquier desarrollador, cualquier #nube. Use las herramientas que elija, solo traiga el código.

Seguridad

Un líder confiable en seguridad, el mejor.

Acelere la entrega con #DevOps.

Su producto necesita llegar rápidamente a los clientes
y mantenerse disponible.

  • Objetivos y herramientas compartidos
  • Colaboración
  • Automatización de procesos
  • Entrega y mejora continuas

Implementación continua y conforme con la normativa

Servicios integrados de #seguridad, #monitoreo y administración de nivel empresarial

GitHub: El desarrollador de plataformas
nro 1 en el planeta

  • Mayores contribuciones: 1,100 millones en 2018
  • Más desarrolladores: 33 millones
  • Mayor crecimiento: 8 millones de nuevos desarrolladores en 2018
  • Más Repos: 96 millones
  • Mayor actividad: 200 millones de PR, 800 millones de solicitudes diarias de #API 
  • Más estudiantes: 1.1 millones
  • Más organizaciones: 2.2 millones
  • Mayor seguridad: 5 millones de alertas de vulnerabilidad en 2018

Desea crear su plan de desarrollo para implementar DevOps, contactenos

[popup_anything id=”2076″]
Categories
54cuatro

El valor de la Gobernanza

Ya nadie discute que los nuevos negocios dentro de las compañías, nacen aprovechando toda la informacion que guardaron estos años, y son esos datos los que permite crear nuevos productos, nuevos negocios, conocer mas a los clientes.

Pero también es necesario mencionar que se tiende a simplificar el “como” se usan esos datos. Los datos aportan valor si son confiables y de calidad, y para ello es necesario conocer su contenido y estructura.

En esta nota vamos a mencionar el camino recomendado para adoptar soluciones de #InteligenciaArtificial en la analítica partiendo desde una metodología de #gobernanza que asegure la calidad de los datos.

La fase de Recolección de Datos

El primer desafío es Recolectar la informacion que poseen las empresas, y en este sentido el desafío principal pasa por realizar una modernización de los procesos y flujos, para identificar todos aquellas bases de datos, tablas, archivos que tenemos a disposición para consumir esa informacion.

La fase de Organización de Datos

El segundo punto es Organizar esa informacion, generando un lenguaje común, para que todos los usuarios (de negocios y TI) conozcan todos los datos que estamos manejando, que exista una relación entre el lenguaje comercial y el lenguaje técnico; donde podamos generar Dueños de Datos. Estos Dueños de Datos (data stewardship) es lo que nos va a permitir la gestión y supervisión de los activos de datos de nuestra organización para ayudar a proporcionar a los usuarios comerciales datos de alta calidad.

Estos niveles de calidad son fundamentales si queremos tener reportes fidedignos; y por tal motivo vamos a correr procesos de Curación, Gestión de Metadatos, Linaje y Catalogo, entre otros procesos que serán los que dejaran lista una base de datos lista para el negocio.

La fase de Análisis de Datos

La fase de Organización nos va a permitir saltar a la fase de Análisis, donde vamos a poder armar #Dashboards y #Reportes desde informacion confiable, y eso se va a permitir:

  • Encontrar: Acceso mas rápido a la informacion
  • Confiar: Entender de donde provienen los datos y porque se puede confiar en ellos
  • Preparar: Limpiar, estructurar y enriquecer datos crudos para transformarlos en informacion procesada
  • Actuar: Generar nuevos resultados comerciales desde Análisis mas confiables.

Infundir: la capa de análisis inteligente

Luego de haber creado una plataforma de integración robusta, de tener identificado nuestros datos como activos y de generar reportes confiables, vamos a implementar una capa de Analítica Avanzada, donde logremos descubrir tendencias y patrones que mejoren la toma de decisiones mediante técnicas de exploración cognitiva.

En este punto soluciones de #MachineLearning logran destrabar el valor de los datos, permitiendo generar nuevos productos basados en el reconocimiento 360° de los clientes, detectar necesidades de la industria o simplemente lograr identificar cosas que siempre estuvieron invisibles a un análisis tradicional.

Que arquitecturas nos proponen los vendors?

Existe un consenso de la industria en torno al armado de arquitecturas de datos en distintas capas. La gran mayoría son plasmadas en gráficos que se pueden “leer” de izquierda a derecha, conformados por:

  • Capa Fuentes de Datos: donde contamos con los orígenes de datos, estos orígenes pueden ser bases de datos, webs, archivos, eventos, sensores, etc.
  • Capa de Integración: desde donde se efectúa el comportamiento relacionado a la orquestación del movimiento, transformación e ingesta de los datos.
  • Capa de Procesamiento: donde se ejecutan los procesos analíticos, ya sea en cubos.
  • Capa de Visualización: donde finalmente se presentan de forma amigable lo referido a reportes de cara a los usuarios.

A continuación veamos algunos esquemas de alto nivel que proponen #IBM y #Microsoft.

Arquitectura de Data provisto por IBM

Arquitectura de Data provisto por Microsoft en Azure

Conclusiones finales

Las tecnologías de análisis están al alcance de la mano de todos. En los últimos años, el crecimiento de la generación de datos es exponencial y lo seguirá siendo; y en paralelo las tecnologías cloud generaron una disminución en el costo del storage, mayor procesamiento, consumo “por uso” y aplicaciones apilables que nos permiten desarrollar una plataforma en la nube con muy poco esfuerzo.

Pero el mayor valor de una plataforma de datos no esta dado por la tecnología sino por los requerimientos de negocios que resolvemos.

Desde #54cuatro alentamos a nuestros clientes a convertirse en empresas inspiradas por los datos, donde la informacion sea un catalizador de nuevas ideas; y es por eso que no hacemos recomendaciones tecnológicas sin entender los requisitos, porque nosotros ofrecemos practicas y metodologías de gestión de datos (que entre otras cosas incluye el factor tecnológico) donde el mayor valor del análisis se da cuando se gestiona la informacion como un asset y donde la calidad asegura que los reportes mejoren la toma de decisiones, el servicio al cliente y el ROI.


[popup_anything id=”2076″]

Categories
54cuatro

Creando un Pipeline CI/CD DevOps

Creación de un pipeline CI/CD desde Azure DevOps a KongHQ

En este post Silvio Ricagno y Alejandro Orozco nuestros especialistas en Microservicios nos van a explicar cómo ejecutar una integración entre Azure DevOps, Docker hub, ArgoCD, Rancher y KongHQ.

Información útil sobre este ejemplo

  • La idea principal del ejemplo es resolver de una manera muy sencilla la comunicación entre estas herramientas usando varias características que nos facilita .Net sobre Visual Studio y Azure #DevOps.
  • Tanto KongHQ como Argo CD ya se encuentran instalados y configurados sobre Rancher.
  • El Framework del proyecto usado es .Net Core 3.1.
  • Es recomendable tener instalado y actualizado, en la PC donde estés trabajando con el Visual Studio, Docker Desktop.
  • El archivo .sln y .csproj deben estar en carpetas distintas.

Herramienta que usamos

En nuestra demo usamos la siguientes herramientas

Estructura de la solución

  • Para genera la configuración necesaria para contenedores, usamos la opción de “compatibilidad con orquestador de contenedores” disponible haciendo clic derecho en el nombre del proyecto en el submenú “agregar”. Aquí elegimos “Kubernetes/Helm”.
  • Es muy importante que el Dockerfile esté a la altura del .sln, esto nos ahorrará varios dolores de cabeza. Si bien en la siguiente imagen aparece a la altura del .csproj, éste no se usa.

Dockerfile

  • Debemos asegurarnos que la ruta del COPY del .csproj (en este caso en la línea 7) sea correcto, tiene como punto de vista la carpeta donde está el Dockerfile (aclarado en el apartado anterior).
  • En este caso la aplicación correrá sobre #Linux.

Código del Dockerfile

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ["API_Test/API_Test.csproj", "API_Test/"]
RUN dotnet restore "API_Test/API_Test.csproj"
COPY . .
WORKDIR "/src/API_Test"
RUN dotnet build "API_Test.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "API_Test.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "API_Test.dll"]

Edición del Helm Chart

Value.yaml

Una gran facilidad que nos brinda esta herramienta es la posibilidad de establecer determinadas variables, para que en el CD (en esta caso con Argo) se genere dinámicamente el deploy, el service y el ingress.

Entonces cargamos el archivo de la siguiente manera.

fullnameOverride: api-test-k8s
replicaCount: 1

image:
  repository: docker.io/sricagno/test-api10
  tag: 35
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

deployment:
  containerPort: 80

ingress:
  enabled: true
  annotations: {}
  host: api-test-k8s.54cuatrocicd.10.63.32.30.xip.io
  path: /weatherforecast

Ingress.yaml:

Ahora editamos el ingress.yaml en la sección de rules del archivo.

El archivo original:

Finalmente lo dejamos así:

{{- end }}
  rules:
    - host: {{ .Values.ingress.host }}
      http:
        paths:
          - path: {{ $ingressPath }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: http
{{- end }}

Sacamos el “range” de la línea 34 y 42 (“{{- end}}”), ya que no queremos tener más de un host. Por último en host ponemos el nombre de la variable de host que vamos a usar en este caso .Values.ingress.host.

Pipeline CI en Azure DevOps

Creamos un pipeline en Azure DevOps, al crear un nuevo Pipeline en la parte inferior nos permite seleccionar “usar el editor clásico” y así es como continuamos: seleccionamos la rama del repositorio a implementar y elegimos “empty job”.

Nos mostrará una pantalla como las siguientes. Agregamos un por una las 3 tareas.

Tarea 1

Tarea 2

Tarea 3

Como repositorio de #Docker usamos Docker Hub.

Si no tenemos registrado en Azure DevOps el repositorio de Dockers, lo podemos administrar desde “Manage”, debemos dar de alta el repositorio donde almacenaremos la imagen Docker.

CD con ArgoCD

Como mencionamos al principio, teníamos instalado y configurado #ArgoCD sobre #Rancher.

Dentro de Argo, previamente, conectamos el repositorio de Azure.

Creamos una aplicación nueva

Establecemos los siguientes parámetros.

Nota

Si lo ingresado anteriormente está bien, se puede leer el Helm un poco más abajo. Como aparece a continuación.

Finalmente le damos a Create y luego sincronizamos.

Si todo se ejecutó de manera correcta se debería haber desplegado la imagen, creado un servicio y un ingress, en Rancher:

En Rancher

Despliegue

Servicio

Ingress

Probamos la aplicación

Finalmente accedemos a la aplicación, esto se rutea a través de KongHQ.

Respuesta

Video relacionado

[popup_anything id=”2076″]

Categories
54cuatro

¿Tus datos te informan, te guían o te inspiran?

Contexto general

Me da la sensación que muchas organizaciones tienen como objetivo convertirse en ‘Data Driven’, o en español, impulsada por datos. Pero considero que para aspirar a ser #DataDriven debemos primero dominar la etapa de ser una empresa Informada, y a futuro podemos aspirar a ser una empresa Inspirada por los #datos, donde la conjunción de datos y personas sean un catalizador de nuevas ideas.

Si planteamos un escenario donde su compañía busca ser impulsada por los datosrequiere tener los datos exactos que se necesitan para tomar una decisión, ya que será la Información la que le de certeza de la decisión a tomar. A diferencia de estar informado por los datos donde es necesario conocer el rendimiento actual de sus análisis y poder responder ciertas preguntas desde la experiencia, por ejemplo: por qué el producto se está desempeñando de la manera en que lo hace, y con esa respuesta plantear un accionable para optimizar sus estrategias de marketing y/o comerciales.

¿Data Driven es el mejor destino?

Considero que un mejor destino es buscar ser una organización Inspirada por sus Datos, con la capacidad de detectar y generar tendencias, nuevas ideas, nuevos productos, desde una vista de intuición sostenida por información.

¿Como avanzar?

En mi opinión, se debe seguir un journey determinado de esta manera:

Paso 1) Estar informado por datos. Basado en datos significa lograr utilizar la informacion de sus sistemas para generar reportes que le ayuden a comprender el rendimiento de indicadores claves y poder determinar las razones de los resultados, saber qué y por qué. Este tipo de estrategias analizan el pasado, de manera que estar Informado por los Datos debería ayudar a explicar los fracasos y los éxitos del pasado para impulsar estrategias futuras.

Paso 2) Adoptar el Data Driven. Estar orientado por medio de datos significa que tiene los datos que determinarán una decisión futura. Una empresa Data Driven requiere de una rigurosidad en el manejo de la información para garantizar los resultados de las tomas de decisiones y es por tal motivo que se aparece la figura del análisis basado en modelos matemáticos (#DataScience). Nuevamente voy a aportar un punto de vista personal: ser Data Driven, requiere tener buenos modelos de BI previos, creo que primero se está “Informado por los datos” y luego se es “Data Driven”; principalmente porque las hipótesis para las que usamos los datos están destinados a responder preguntas muy específicas.

Paso 3) Inspirado por los Datos. Estar inspirado por los datos, corresponde a toda una mecánica analítica puesto a disposición de la compañía, donde se combinan datos de diferentes fuentes para inspirar nuevas ideas.

La suma del Paso 1 y el Paso 2, generan un modelo Data-Inspired, donde se conjugan las intuiciones de las personas con la rigurosidad de los resultados de algoritmos para dar rienda sueltas a la creatividad.

En que paso se encuentra tu compañía? Te animas a descubrilo juntos?


[popup_anything id=”2076″]