5. Evolution of the Cloud
Pre-Cloud Number of servers
OS to install
Periodicity to patch the server
Size of the servers to buy Plan to backup the server
Deploy new code
Time to provision a new server
The location of the servers is secure?
What happens if the power goes out?
Right size of the servers to my business
Who has physical access to the servers?
Media to keep backup
Type of storage
Scale the application
Plan to hardware failure
Dynamically configure the application
Who monitors the servers
Application monitoring
6. Evolution of the Cloud
Pre-CloudIaaS Number of servers
OS to install
Periodicity to patch the server
Size of the servers to buy Plan to backup the server
Deploy new code
Time to provision a new server
The location of the servers is secure?
What happens if the power goes out?
Right size of the servers to my business
Who has physical access to the servers?
Media to keep backup
Type of storage
Scale the application
Plan to hardware failure
Dynamically configure the application
Who monitors the servers
Application monitoring
7. Evolution of the Cloud
Pre-CloudPaaS Number of servers
OS to install
Periodicity to patch the server
Plan to backup the server
Deploy new code
Right size of the servers to my business
Scale the application
Dynamically configure the application
Application monitoring
8. Evolution of the Cloud
Pre-CloudServerless Number of servers
Scale the application
Right size of the servers to my business
9. What is Serverless and their Benefits
Pay per excution
• Consumption Billing
• Users are only charged for runtime and resources that the function consumes.
• There is no longer any concept of under or over provisioning
Ease of scale
• If the load on the function grows, the infrastructure will create copies of the function
and scale to meet demand
• It will scale as long as you can pay for it
Do less Manage less
• Servers are fully-abstracted
• No more do you need to set up a server or procure one
• Not require fixed infrastructure to be pre-provisioned in order for it to be used
10. Logic Apps and Serverless
Pay per Action
• e.g. If you set up a Logic App to poll for data once every minute over the course of 10
days, that App would generate 14,400 billable actions
• e.g. If that same Logic App also included 500 workflow steps per day as part of the daily
polling, the Logic App would generate an additional 5,000 billable actions
Don’t worry about resources
• Think about billable actions
Don’t worry Virtual Machines, PaaS VMs, …
• Not require infrastructure to be provisioned
Don’t worry about the platform
• Focus on code, deployment and managing the app
13. Logic Apps and Integration
Implement and orchestrate visually designed integration workflows
• Azure Portal or Visual Studio
• Azure SDK + Azure Logic Apps Visual Studio Tools
Orchestrate distributed microservices
• Rich ways to process and manipulate data than can be obtained or pushed via
different connectors
• Expose your integrations as microservices
B2B Integrations with AS2 and EDI
• Enterprise Integration Pack (EIP)
100+ Connectors
• Protocols, Hybrid, SaaS, …
15. Logic Apps and Integration (Connectors)
Protocols / Native Hybrid Azure Services and Power Apps Connectors
B2B? AS2? EDI? XML?
16.
17. Enterprise Integration Pack - Intro
Microsoft’s cloud-based solution to enable Enterprise Integration Scenarios
• B2B workflows
• Industry standard protocols: AS2, X12, EDIFACT.
• Flat Files and XML
• Secure messages with encryption and digital signatures.
Based on Integration Accounts
• Cloud-based containers that store all our artifacts: schemas, partners, certificates,
maps and agreements.
Different artifacts
• Schemas
• Maps
• Agreements
• Partners
• Certificates
19. Enterprise Integration Pack – Get Started
Create and
Integration
Account in
the Azure
Portal
Add Partners,
Schemas,
Certificates,
Maps and
Agreements
Create a
Logic App
Link the Logic
App to the
Integration
Account
Use the
artifacts
stored in the
Integration
Account in
your Logic
App
What you need
• An Azure subscription
• An Integration Account
• Visual Studio 2015, to create maps and schemas (you can reuse maps and schemas of your BizTalk
Solutions)
• Microsoft Azure Logic Apps Enterprise Integration Tools for Visual Studio 2015 2.0
27. BizTalk to Azure iPaaS
Adapters
• Description: “An adapter is a software component that enables you to easily send
messages out of or receive messages into BizTalk Server with a delivery mechanism that
conforms to a commonly recognized standard, such as SMTP, POP3, FTP, or Microsoft
Message Queuing (MSMQ). As Microsoft BizTalk Server has evolved, the need for
adapters that quickly enable connectivity with commonly used applications and
technologies has increased”
Connectors
• Standard connectors
e.g. IBM DB2, SQL Server, OneDrive, Twitter, …
• Custom API Apps within the Logic App
https://blog.geist.no/custom-connectors-taking-azure-logic-and-api-apps-for-a-spin-
part-2/
28. BizTalk to Azure iPaaS
Pipelines
• Description: “Pipelines are a component of Microsoft BizTalk Server that provides an
implementation of the Pipes and Filters integration pattern. During the receiving and
sending of messages, there are business reasons to perform transformations on
messages to prepare them to enter or leave BizTalk Server.”
Logic Apps
• Building a simple Logic App that implements Pipes and Filters pattern like pipelines
29. BizTalk to Azure iPaaS
Pipeline Components
• Description: “A general pipeline component takes a single message, performs some
processing, and emits zero or more messages. If it does not produce any message
output, it is called a consuming component.”
Connectors
• Standard connectors
• Custom API Apps within the Logic App
• e.g. Parse JSON, XML Validation, Flat File decoding, AS2 encoding, …
30. BizTalk to Azure iPaaS
Orchestration
• Description: “An orchestration is a flexible, powerful tool for representing an executable
business”
Logic Apps
• Building a complex Logic App that implements a business process.
31. BizTalk to Azure iPaaS
Publish / Subscribe
• The model implemented in BizTalk Server is often called content-based publish/subscribe
34. Demo Scenario
Integration Account for schemas and maps
Add Contact Insightly
Receive XML
(CreateOrderRequest)
Azure Service Bus
(queue neworders) Logic App
Azure Service Bus
(queue neworder_json)
Send JSON orders
Invalid XML Request
Buenos días!
Me llamo Félix Mondelo y soy Arquitecto de Soluciones de Integración en Kabel.
Os voy a hablar de las Logic Apps y del Nuevo enfoque de integración empresarial en Azure.
En primer lugar veremos la evolución de las infraestructuras hasta llegar a una infraestructura Serverless.
A continuación veremos la integración en una infraestructura Serverless, mediante Logic Apps.
Después vermos el uso del Enterprise Integration Pack.
Finalmente, mostraré las similitudes entre un desarrollo BizTalk y un desarrollo utilizando la plataforma de integración como servicio de Azure.
Antes de la aparición de las infraestructuras Cloud, teníamos una larga lista de tareas que abordar.
Por ejemplo, desde el mundo de la integración, si queríamos abordar una implantación de BizTalk Server, nos teníamos que plantear:
Dependiendo de como quisiéramos la infraestructura (Activo/Pasivo, NLB, … ) ¿Cuantos servidores necesitamos? No solo servidores para BizTalk, también para SQL Server.
El tamaño de los servidores, con cuanta memoria, con cuanto disco, cuanto CPU, …
El Sistema operativo que debíamos instalar.
El plan para la instalación de parches, cuando instalarlos, …
En caso de que necesitaramos escalar, cuanto tiempo nos costaría añadir nuevos servidores.
Desde el punto de vista de la seguridad:
Verificar si es seguro donde tengo alojados mis servidores.
Quién tiene acceso físico a los servidores.
En la planificación de disaster recovery teníamos que tener un plan,
Con qué frecuencia realizar los backups
¿Qué hacer en caso de un fallo de hardware?
Desde el punto de vista de aplicaciones:
Como escalar la aplicación, por ejemplo
Cuando pasamos a IaaS, ya podemos ir dejando fuera alguna de las tareas:
Por ejemplo, la seguridad de quién tiene acceso físico, a nuestros servidores, ya no tiene sentido o que hacer en caso de un fallo de hardware.
Son tareas de las que nos despreocupamos.
Si vamos un paso más y nos adentramos en el mundo PaaS, ya nos olvidamos completamente del mantenimiento de nuestros servidores. Ya no tenemos que preocuparnos de que version de Sistema Operativo tenemos, de los parches que hay que instalar….
Desplegamos nuestras aplicaciones, pero no pensamos en las máquinas virtuales que hay detrás.
Existen obviamente, pero no debemos preocuparnos de ellas.
Finalmente llegamos a una arquitectura Serverless.
¿Qué implica esto? Que nos olvidamos completamente de los servidores y de como escalar nuestras aplicaciones. Mientras nuestra cuenta corriente esté saludable, nuestra aplicación podrá escalar todo lo que queramos.
¿Serverless que significa y qué beneficios tiene?
Pues que tendremos que gestionar menos cosas.
En esta arquitectura ya no tenemos que preocuparnos por los servidores, será un ente abstracto para nosotros y ya no tenemos que adquirirlos ni provisionarlos.
Ni diseñar una infraestructura fija, con tantos servidores, con X CPUs, con memoria RAM de tantas Gigas y discos de tal tamaño.
Además la facilidad de escalar nuestras soluciones.
Ya no escalamos enfocando la escalabilidad en los recursos, si no en base a eventos.
Nuestras aplicaciones podrán escalar tanto, en función de lo que podamos pagar por ello.
Pagamos por ejecución, por número de eventos, ya no tenemos que pensar en pagar por provisionar equipos, por comprar más espacio en disco, ….
Uno de los elementos Serverless que nos proporciona Azure, son las Logic App.
En las Logic App ya no pensamos en donde desplegar la aplicación, ni que servidor usar, ni que equipos hemos de provisionar … tan solo la creamos, la habilitamos y a partir de ese momento, empezamos a pagar por ejecución.
Por ejemplo, si nuestra Logic App está realizando polling cada minuto durante 10 días, esto implica que nuestra Logic App está generando 14.400 acciones que son facturables.
Además, si esta Logic App incluye 500 pasos por día del workflow, son otras 5000 aciones más.
Entonces, para esta Logic App, durante 10 días hemos generado 19.400 acciones facturables, que a un precio estimado de 0,001€ por acción (el coste real es menor), la ejecución de nuestra Logic App serían 19,4€ durante esos 10 días.
Esto incluye todo y con esto quiero decir, que ya no nos tenemos que preocuparnos de los costes, de los recursos donde se ejecuta nuestra aplicación, ni de la infraestructura …. Simplemente nos tenemos que ocupar de nuestra Logic App.
A continuación os presento la Plataforma de integración como Servicio de Microsoft Azure, con esto Microsoft ofrece una rápida conectividad de aplicaciones híbrida y de calidad empresarial.
Esta plataforma se basa en 4 elementos:
API Management
Que nos proporciona un Front End y nos permite gestionar nuestras APIs de backend.
Service Bus
Proporciona la funcionalidad de mensajería por colas o por publicación suscripción.
Functions
Evolución de los Web Jobs
Permiten crear pequeñas piezas de código
Que pueden ser ejecutadas de forma síncrona o asíncrona
Desarrolladas en diferentes lenguajes
Los procesos de integración suelen requerir validar, enriquecer, transformar, enrutar, …que puede ser lograda implementando una Function
Logic Apps
Que nos proporciona funcionalidades de workflow y orquestación
Junto con un conjunto de conectores que nos permiten de forma rápida, conectar diversos sistemas.
Las Logic App las podemos diseñar a través del portal, pero también podemos desarrollarlas en Visual Stucio gracias al SDK de Azure y las Tools para Logic Apps.
Nos permite:
Orquestar nuestros procesos de integración
Obtener y enviar la información a diferentes fuentes
Manipular los datos de forma sencilla
A través de las Logic Apps podremos exponer nuestros microservicios.
Además, con el Enterprise Integration Pack, podremos desarrollar integraciones B2B, EDI, … además del manejo de ficheros planos y XML.
De serie, incorpora más de 100 conectores, lo que nos permite comunicarnos con diferentes protocolos, con, SaaS, …
Aquí la lista de conectores, empezando por la integración con SaaS, donde encontramos:
Salesforce, Dynamics, Insightly, …
Varios de Redes Sociales (Facebook, Twitter, …)
Además tenemos:
Para diversos protocolos HTTP, SMTP, …
Para conexiones híbridas para conectarnos con nuestros sistemas on-premise: BizTalk, DB2, …
Y luego para integrarnos con varios servicios de Azure (Service Bus, Storage Blob, Azure SQL, …)
Y qué pasa con los conectores para la parte de integración? Dónde están los conectores para EDI? La validación de XML?
Todo eso forma parte del Enterprise Integration Pack.
Qué nos permite este pack?
Integraciones B2B
Usando protocolos estandar como AS2, X12 o EDIFACT.
El uso y manejo de ficheros planos y XML.
Securizar nuestra mensajería con cifrado y firmas digitales.
Además podremos tener nuestro repositorio de Schemas, Mapas, Certificados, Agreements y Partners.
Todo se basa en cuentas de integración, que no dejan de ser contenedores en la nube donde almacenaremos y agruparemos todos nuestros artefactos relacionados.
Con el Enterprise Integration Pack, añadiremos a nuestra lista de conectores todos estos.
Todos conocidos, ya que en BizTalk ya los teníamos:
La validación XML, la decodificación de ficheros planos, la codificación de ficheros EDIFACT, …
Para empezar una integración con el Enterprise Integration Pack, lo que vamos a necesitar es:
Una suscripción Azure
Una cuenta de integración
Visual Studio 2015 con las Tools para Logic Apps – Esto lo necesitamos para crear los schemas y los mapas, donde podremos reaprovechar los que ya tengamos de BizTalk.
Entonces los pasos a seguir serían:
Primero, crear la cuenta de integración en nuestro portal de Azure
Segundo Añadir nuestros artefactos: schemas, mapas, certificados, …
Después simplemente crearemos la Logic App, no empezaremos a desarrollarla.
El cuarto paso será enlazar la cuenta de integración que creamos en el primer paso a la Logic App.
Y por ultimo, ya podemos ponernos con el desarrollo de nuestra Logic App.
A continuación paso a mostrar las similitudes en el desarrollo de integraciones con BizTalk y las nuevas integraciones usando el iPaaS de Azure.
Aquí tenemos la arquitectura de BizTalk.
Donde los elementos principales serían:
Los adaptaores que nos permite comunicarnos mediante diversos protocolos con otros sistemas.
Los pipelines y los componentes de pipeline, que nos permiten realizar diversas acciones sobre los mensajes, antes de entregarsélos a otro Sistema o a una orquestación.
La MessageBox, que nos permite implementar el mecanismo de publicación suscripción.
Las orquestaciones, que nos permiten orquestar nuestros procesos de integración.
Pues bien, vamos a ver las similtudes entre esta arquitectura y el iPaaS.
En primer lugar los adaptadores.
Que nos permiten comunicarnos mediante diferentes protocolos y sistemas.
¿Qué solución tiene esto en la plataforma de integración como servicios?
Mediante los conectores standard.
Tenemos conectores para DB2, para OneDrive, …
¿No es suficiente?
Podemos desarrollar nuestro propio conector mediante una API App.
Vamos con los pipelines,
Que nos permiten implementar el patron de integración Pipes and Filters.
¿Qué solución tiene esto en la plataforma de integración como servicios?
Mediante una Logic App simple, donde incorporemos las transformaciones que queramos realizar.
¿Y como incorporar estas transformaciones o procesos? En BizTalk lo teníamos claro, mediante los components de pipeline.
¿Qué solución tiene esto en la plataforma de integración como servicios?
Mediante los conectores standard.
Pero ahora en lugar de usar los conectores que se comunican con otros sistemas, usamos los conectores para el tratamiento de los mensajes.
¿No es suficiente?
Podemos desarrollar nuestro propio conector mediante una API App.
¿Qué pasa con las orquestaciones?
Quizás este es el punto más claro, ya que encontramos claras similitudes con las Logic Apps.
Lo único, que este caso no sería una simple Logic App como en los Pipelines, si no algo mas complejo.
Por ultimo, el mecanismo de publicación-suscripción.
En BizTalk lo teníamos resuelto con la MsgBox y los filtros para arrancar orquestaciones y puertos.
¿Y ahora en la plataforma de integración?
Pues sencillo, usando los Topics del Service Bus.
Para ver una aproximación real a la nueva arquitectura, pues podríamos tener algo así.
Nuestro service bus con Topics, en medio.
X Logic Apps que mediante publicación / suscripción, cogerían los mensajes que le interesan
Y realizarían la integración para poder comunicarse con protocolos diferentes, sistemas internos, …