CoE Starter Kit — BYODL Integration
En Junio de 2021 se publicaba una Public Preview muy esperada (en mi opinión) por los admins de la Power Platform como era la posibilidad de exportar la telemetría de nuestro tenant a un Datalake y ahí poder explotar los datos para implementar o mejorar nuestros procesos de monitorización, auditoría, etc
Otro de los beneficiados por esta nueva funcionalidad será el CoE Starter Kit, ya que podrá prescindir de sus más de 40 flows actuales usados para extraer toda la información de inventario desde los M365 Audit Logs, para consultar directamente este datalake, que de por sí ya se actualizada diariamente.
Aquí es donde nace el proyecto CoE Starter Kit BYODL Integration, cuyo objetivo es refactorizar este conjunto de soluciones tal como lo veníamos conociendo hasta ahora para alimentarse directamente de este datalake.
En su github podremos ver todos los avances de los hitos del proyecto:
Diferencias entre el CoE Starter Kit y CoE Starter Kit BYODL
La actual arquitectura del Coe Starter Kit está compuesta por aproximádamente unos 40 flows, de ejecución diaria o semanal, lo que conlleva a multitud de puntos de error o degradación de rendimiento.
Problemas de la arquitectura actual:
- Rendimiento: La recopilación de inventario y telemetría puede llevar días.
- Throttling: Los tenants de gran volumen de datos podrían tener pérdidas de rendimiento en la ejecución de sus CoE Starter Kits flows.
- Coste: Necesaria licencia de pago para la cuenta que ejecuta los CoE Starter Kit flows.
- Mantenimiento: El disponer de un número tan elevado de flows (40) implica mayor riesgo de errores ante cambios.
Beneficiones del arquitectura BYODL:
- Coste: La cuenta de almacenamiento del Datalake puede costar unos 0,50$/mes, comparado con los 15$/mes de una licencia Power Automate Per user plan o 100$/mes de una licencia Power Automate Per flow plan.
Nota: precios estimados sobre el PVP del día de la publicación del artículo. - Rendimiento: El uso de dataflows facilita toda la capa de lógica y transformación del dato además de ser mas eficientes que los cloud flows.
- Dato real: El dato proviene directamente de la telemetría central de Microsoft.
- Datos sobre cloud flows: se dispone de más información sobre los cloud flows que en el arquitectura actual como por ejemplo, la última ejecución.
- Datos de uso sobre Power Apps Model-driven: se dispone también de información sobre este tipo de Power Apps, algo que los Audit logs de M365 no recogían.
Estructura del Self-Serve Analytics Datalake
El esquema de datos del datalake puede consultarse en esta documentación:
https://learn.microsoft.com/en-us/power-platform/admin/self-service-analytics-schema-definition
Diariamente se recupera toda la información en estos ficheros:
- 1 fichero con información de todos los entornos
- 2 ficheros por entorno con información de Power Apps (1 para tipo canvas y otro para tipo Model-driven) Cuando se crea un nuevo entorno, se crean 2 nuevos ficheros.
- 1 fichero por entorno con información de Flows.
- 1 fichero por día con el uso de Power Apps
- 1 fichero por día con el uso de Flows
- 1 fichero por Power App con sus conexiones
- 1 fichero por Flow con sus conexiones.
- 1 fichero por entorno con las conexiones de usuario.
Power BI Dataflow
Los datos recuperados deberán ser transformados para convertirse en información bien formada de manera que el CoE Power BI Dashboard pueda usarla como origen de datos.
Aquí entran en juego el Power BI Dataflow que se usará para transformar los datos del datalake en conjuntos de datos de Power BI que luego se usan en el dashboard.
Se aprovechará también la funcionalidad de refresco incremental del Dataflow para mejorar el rendimiento y transformar sólo los datos nuevos.
Algunas transformaciones que hará el dataflow:
- Convertir ficheros JSON en tablas
- Renombra columnas o datos para una mejor identificación
- Excluir apps/flows cuyo entorno ya no exista.
- Actualizar datos de uso mediante refresco incremental.
Las tablas que creará el Dataflow serían las siguientes:
- AppConfRef
- Connections
- Environments
- FlowConnRef
- Flows
- Apps
- FlowUsage
- AppsUsage
Power Platform Dataflows
Los datos necesarios para las Power Apps y Flows del CoE Starter Kit se llevarán desde el Datalake al Dataverse que ya venía usando las soluciones del CoE Starter Kit a través de Power Platform Dataflows.
Dichos Dataflows moverán sólo los últimos cambios en refrescos diarios.
La idea de mantener la misma estructura del dataverse es poder habilitar tres escenarios:
1. Usuarios que vienen de usar CoE Starter Kit y van a migrar a la nueva arquitectura BYODL.
2. Usuarios nuevos del CoE Starter Kit que empiezan ya con la arquitectura BYODL.
3. Usuarios del CoE Starter Kit que no van a migrar a la nueva arquitectura.
Datos no incluidos en el Datalake
Los siguientes datos no están incluidos en el Datalake, a fecha de publicación de este artículo, y se seguirán recopilando mediante Cloud flows y los M365 Audit Logs.
- Desktop flows
- Chatbots
- Power Pages
- Inventario de soluciones
- Detalle de las acciones en flows
- Detalle de flujos suspendidos
- Detalle de Power Apps que incumplen una política DLP
- Detalle de los usaurios/grupos compartidos por una Power App
- Detalle de capacidad de los entornos
Requisitos del nuevo CoE Starter Kit BYODL
- Un workspace Premium en Power BI Service, para poder usar la funcionalidad de refresco incremental.
- Una cuenta de almacenamiento en Azure y acceso como Owner.
- Una licencia Power Automate per User, para la ejecución de los sync flows que aún se necesitan para recuperar el dato faltante del Datalake.
- Licencia Power Apps per User (o per app pass or pay-as-you-go) para ejecutar las aplicaciones del CoE Starter Kit.
Conclusiones
En resumen, la llegada del Self-Service Analytics a la Power Platform, cambiará el CoE Starter Kit tal cuál lo veníamos conociendo hasta ahora, simplificando toda su arquitectura, ganando más fiabilidad, mejor rendimiento, mejor dato, etc.
Por ahora se encuentra en Private Preview, en proceso de validación de toda la refactoriazación de las soluciones y sujeta también a la GA del Self-Service Analytics.
