La popularidad de Fabric no para de extenderse y eso hace que cada vez más aparezcan confusiones y dudas sobre licencias. Cada día llegan más dudas sobre el formato de licencias y como encaja lo nuevo en lo viejo. Dentro de esas dudas aparecen muchas alternativas para manejo de licencias.
En este artículo vamos a hablar de puntos medios y grises para optimizar costos de nuestras licencias encontrando el mejor balance con los nuevos planes que nos ofrece Fabric.
Primero vamos con conocimientos básicos de licencias en este antiguo artículo que escribí. En el mismo vamos a conocer detalles de las licencias disponibles en julio 2024.
Si ya conocen las de PowerBi, lo nuevo es Fabric. Una licencia por capacidad que viene a expandir los artefactos o contenidos que podemos crear dentro de un área de trabajo. Sus planes inician con valores más económicos que las capacidades anteriores, lo que permiten que todo tipo de organización pueda acceder al uso de éstos artefactos. Sin embargo, el uso de los tradicionales contenidos de PowerBi siguen bajo el mismo esquema.
La estrategía de optimización se base específicamente en los usuarios. Si tenemos capacidades dedicadas… ¿Por qué pagamos licencias por usuarios? esta es la pregunta que trae el principal contexto y razón del artículo. A las organizaciones les cuesta este concepto, más aún viendo que los contenidos de Fabric no necesitan licencias de usuario. No necesitamos una licencia PRO para desarrollar un notebook, escribir en Onelake o consultar un warehouse con SQL. Para resolver esta paradoja vamos a dividir nuestro enfoque en los dos tipos de usuarios, desarrolladores y visores.
Enfoque de Visores
Algo que suele trae mucho dolor a organizaciones que usan PowerBi es que los visores en entornos de capacidad compartida (pro o ppu), tengan que pagar licencia. Uno puede pensar que pagando una "Capacidad Dedicada" como premium lo soluciona, sin embargo premium va a desaparecer y quedará Fabric. Muchos podrán pensar que esta es la solución definitiva, puesto que Fabric comienza con planes muy económicos, pero no es cierto. La característica de compartir con usuarios gratuitos comienza en un plan F64, cuyo costo ronda entre 5000 y 8000 dolares (dependiendo el tipo de pago). Lo que nos hace pensar que valdría la pena si nuestra operación interna cuenta con más de 500 usuarios visores de PowerBi (puesto que una licencia pro sale 10 dolares). Ciertamente, un número que solo grandes empresas pueden considerar.
Entonces, ¿Qué hacemos cuando no podemos pagar ese monto? Si podemos comprar capacidades dedicadas más chicas, ¿Cómo podríamos compartir a usuarios visores sin pagarles licencias Pro? La respuesta es una característica bastante olvidada en el entorno de analytics. Estoy hablando de la feature de "Embedded". PowerBi cuenta con una compleja pero poderosa posibilidad de embeber informes en aplicaciones web con grandes posibilidades. Una de esas posibilidades es delegar la seguridad y loguear a la aplicación que refleja los informes. De ese modo, podríamos compartir a todos los usuarios visores que querramos sin pagar licencias. Sin embargo, no es tan simple puesto que necesitaríamos un potente equipo de desarrollo que construya esta web app aprendiendo todos los enfoques de power bi con especial atención a la seguridad, dado que ahora es responsabilidad nuestra (nos la delega microsoft al usar embedded).
Si no tenemos equipo de desarrollo y queremos aprovechar esa capacidad. ¿Cómo lo resolvemos?. La opción más viable sería comprando un producto de un tercero. Varias instituciones proveen este tipo de software. Por ejemplo, una que conozco en español es PiBi. PiBi es una plataforma web como servicio (SaaS) que usa la característica de Power Bi Embedded. Una construcción que interactúa con tu entorno de Azure y te permite distribuir informes de PowerBi de manera segura, simple y eficiente.
¿Qué ventajas encontramos si nos embarcamos en este camino?
- Operación de informes en un solo lugar
- Más sencillo de usar que Fabric/PowerBi Service
- Compartir con usuarios externos a la organización
- Logins SSO Google/Microsoft
- Mantener seguridad y privacidad
El requerimiento para usar Embedded es tener una licencia por capacidad. Herramientas como ésts pueden partir de valores como 450 dolares por mes, que junto a una licencia básica de Fabric con pago anual de 150 dolares son 600 dolares. Si nuestra operación de usuarios internos ronda entre 60 y 500 usuarios, encaja perfectamente para optimizar nuestra estrategia de Power Bi. Por supuesto, que habría detalles como si tenemos modelos y mucho volumen de datos, puede que necesitemos un Fabric un poco más elevado, pero deberíamos pensar a ese como costo de almacenamiento y no de distribución de contenido a los usuarios.
Enfoque de desarrolladores
En la mayoría de los casos, lo primero que normalmente tendería a evolucionar, son los visores. Una vez encontrado un punto de madurez en ellos, seguirá esta propuesta. Esto quiere decir que lo más probable es que YA contemos con capacidad dedicada (para usar la feature embedded). Pero no desesperen si no la tienen, esta estretegia es totalmente viable sin capacidad tal como lo explico en este otro artículo. Las estrategias no estan ligadas una a otra, aunque son poderosas juntas.
El eje para liberar a los usuarios desarrolladores de sus licencias es pensar en desarrollo de software convencional. Si pensamos en la industra de software, un desarrollador, sea backend o frontend, tiene como trabajo solamente desarrollar. Su eje y foco esta en construir. Hoy esos roles no hacen integración de soluciones, implementaciones o deploys, puestas en producción, etc. Existen roles como DevOps que ayudan a delegar la construcción final.
Tomando este enfoque como guía, si queremos que los desarrolladores de PowerBi no usen licencias, debemos concentrarnos en lo básico, un repositorio. Hoy Fabric nos da la posibilidad de integrar repositorios de GIT con Áreas de Trabajo. Esto no solo nos ayuda a que el desarrollador ni piense en Fabric o PowerBi Service, sino que también almacena los desarrollos en formato Power Bi Project que nos deja mergear código.
Si queremos ver eso en más profundidad pueden abrir éste artículo.
Así los desarrolladores de Power Bi. Solo desarrollarán. Comienzan el día armando o con un pull a su branch de repositorio, comiteando cambios y al terminar un push. Ni piensa ni escucha quienes ven que informes y donde está. Luego podemos pensar en otro perfil que podemos decirle Admin del Area o DataOps que garantice que los reportes están en el lugar apropiado o sean automáticamente deployados. Veamos un poco más gráfico esto:
Vean como Local Machine nunca ve Fabric. El desarrollador no necesita ingresar al portal web. Solo necesitamos licencias para DataOps o Administradores de areas. Así es como reducimos licencias y ganamos robustez y soluciones tanto versionables como escalables.
Se que fue mucho texto pero espero que haya sido a meno y les traigan nuevas ideas para optimizar efectivamente la operación y licencias de sus entornos.