El nivel de acceso Archive en Azure

En las cuentas de Storage en Azure, disponemos de varios elementos de configuración que influyen directamente en la disponibilidad de la información que vamos a almacenar, el precio de tenerlo guardado, el de acceder a los datos y la latencia que tendremos hasta poder leer el primer byte de información. Entre esos elementos está el propio tipo de cuenta y el nivel de rendimiento, así como el tipo de replicación. Para simplificar todo y no desviarnos del objetivo de este artículo, nos centraremos en las cuentas de tipo propósito general V2 (StorageV2) con nivel de rendimiento estándar y replicación LRS (Locally-redundant storage). De este modo nos podremos centrar en el elemento que nos interesa explicar hoy: el nivel de acceso.

Nivel de acceso Azure

Seguir leyendo en CompartiMOSS.

Montar blobs de Azure en Windows

Tal y como hicimos hace unas semanas con Linux, vamos a montar blobs de Azure en Windows para poder usar un container como una unidad de almacenamiento barato.

La verdad es que con Azure CLI y usando el comando subst sería muy fácil montar algo. Sin embargo, todo buen programador ha de revisar si alguien antes que él ya se ha enfrentado al mismo problema. En este caso, así es.

La empresa Gladinet mantiene (o mantenía, ya que no parece muy actualizado y algunos conectores han dejado de funcionar) un software que te permite montar como una unidad virtual casi cualquier repositorio online que se os podáis imaginar.

La página de descargas es una locura, y sólo uno de los enlaces parece llevar a su última versión (la 4) que es la que incluye un conector a los blobs de Azure que funciona.

Una vez instalado y conectado con vuestro container, ya podréis acceder a su contenido y subir archivos como si de cualquier otra carpata de vuestro sistema se tratase.

Montar blobs de Azure en Linux

Si necesitas más espacio en un sistema, por ejemplo, para almacenar copias de seguridad, puedes montar un almacenamiento en la nube como los blobs de Azure en Linux para dotar a tu sistema de almacenamiento «infinito» a un precio muy competitivo aprovechando el Storage.

Se puede hacer con cualquiera, yo lo voy a hacer con Azure porque es con el que suelo trabajar por defecto, aunque haya trabajado con muchos otros.

Esto lo he hecho en Ubuntu 18.04 aunque debería de poderse hacer con más o menos complicaciones en cualquier versión de Linux.

  1. Actualizar repositorios
    wget https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb
    dpkg -i packages-microsoft-prod.deb
    apt-get update
    
  2. Instalar paquetes
    apt-get install blobfuse fuse -y
    
  3. Crear directorio temporal
    mkdir /mnt/resource/blobfusetmp -p
    
  4. Crear archivo de configuración
    vi ~/fuse_connection.cfg
    #Hay que poner las siguientes líneas sin comentarios y con los valores de tu cuenta, tu key y tu container
    #accountName myaccount
    #accountKey storageaccesskey
    #containerName mycontainer
    chmod 600 fuse_connection.cfg
    
    
  5. Montar en un directorio
    mkdir ~/disks
    blobfuse /root/disks --tmp-path=/mnt/resource/blobfusetmp  --config-file=/root/fuse_connection.cfg -o attr_timeout=240 -o entry_timeout=240 -o negative_timeout=120
    

Si esta última llamada la metes en un script que se llame, por ejemplo, desde rc.local te asegurarás de que la «unidad cloud» que has creado en Azure se monte con cada arranque del sistema.

Con esto habrás conseguido tener una nueva unidad montada aprovechando los blobs de Azure en Linux que, aunque sí tendrá más latencia que las unidades físicas de las que dispongas, su precio será mucho menor.

Proyecto tipo: Chatbot buscador

PROBLEMA

El cliente quiere proporcionarle a una tienda online un chatbot buscador de elementos que ayude a los usuarios.

La web dispone de un buscador que no se puede reutilizar.

La base de datos de los elementos no se encuentra accesible.

El chatbot deberá de funcionar igual para los clientes de cualquier parte del mundo.

PROPUESTA

Dado que hay muchas incertidumbres en cuanto al uso, el flujo de conversación y otros puntos del proyecto, que pretende ser de una embergadura muy amplia, se propone hacer un prototipo de chatbot buscador que cumpla con los siguientes puntos que se han acordado con el cliente:

  • El prototipo trabajará con los datos proporcionados por el CLIENTE al PRESTADOR, sobre los elementos ofertados por su cliente.
  • El idioma que entenderá y con el que contestará el prototipo será el castellano, o español de España.
  • Salvo que durante el SEGUIMIENTO DE LA EJECUCIÓN DEL CONTRATO se
    determinase lo contrario entre ambas partes, para la implementación del prototipo se emplearán los servicios de Azure proporcionados por Microsoft.
  • La entrega del prototipo incluye el asesoramiento y respaldo a la hora de la creación de cuentas y de todo lo que sea necesario para realizar su despliegue.
  • La entrega del prototipo incluye la entrega de una estimación de costes de ejecución en base al número de usos que se dé al servicio.
  • El prototipo a desarrollar, será similar al presentado en el ejemplo RealEstateBot proporcionado por Microsoft.
En concreto se implementarán:
  • Una ETL que convierta los datos originales al formato más adecuado.
  • Una base de datos distribuida sobre Azure Cosmos DB.
  • Un motor de búsqueda que será reutilizable en la web y otros servicios, empleando Azure Search.
  • Un motor para el chatbot basado en Azure Bot Service.
  • Se montarán entornos de preproducción y producción.
  • El código se almacenará en un repositorio Git.
  • Se montará un sistema de integración continua con Azure DevOps.

PRecio

6.400€

Tiempo

Dadas las incertidumbres del proyecto, el tiempo de desarrollo será de entre 3 semanas y 3 meses.

Nota aclaratoria:

Este proyecto tipo, es un ejemplo de proyecto que se ha realizado o se podría realizar. En ningún caso tiene validez como presupuesto real y sólo pretende documentar las distintas posibilidades que existen.

Actualmente, con los cambios que ha habido en cuanto a las posibilidades existentes, la propuesta podría ser diferente en estos momentos.

Se han omitido nombres de empresas y productos.

Por favor, si tuviese necesidad de algo similar, no dude en ponerse en contacto.

Azure Serverless

No, no es una nueva feature de Azure de la que no te hayas enterado. En este artículo vamos a entender que es «serverless» ese concepto tan en boca de todos, y los componentes de Azure que se pueden considerar parte de esta moda.

Seguir leyendo en CompartiMOSS.

Introducción a Azure API Management

Estamos atendiendo a un cambio en el modo de afrontar la incorporación de software externo a un proyecto. Cada día es más habitual el incorporar el uso de APIs externas para suplir funciones en lugar de incorporar el software y los datos necesarios para llevarlas a cabo internamente. Todos hemos oído o leído que el paradigma del futuro cercano son los microservicios y llevamos muchísimo viendo las bondades de las APIs REST. Este cambio, como todos, tiene sus cosas buenas y sus cosas no tan buenas.

Seguir leyendo en CompartiMOSS.

WSO2 vs Azure API Management

Next values are estimations and all of them depend on the final production needs.

  WSO2 Azure API Management
Deployment effort 24-40 hours 1 hour
New API effort 1-2 hours 1-2 hours
Scale effort 4-8 hours 1 hour
Distribute in other location effort 16-24 hours 1 hour
Min dev. environment costs 1 machine = 587 euros yearly 486 euros yearly
Min pro. environment costs 12 machines + 8,500 euros (yearly) for production support = 15,544 28,288 euros yearly + 1,404 euros for VPN connection to private endpoints = 29,692
Pros –          It is more flexible thinking about configuration and deployment options –          Its management is easier and faster.
Cons –          Hard maintenance –          Its more expensive

–          At this moment you can only use this over Azure infrastructure.