Build en Español - Serverless.pptx
•Descargar como PPTX, PDF•
0 recomendaciones•184 vistas
Slides of my presentation at Build Community Event in Spanish: Developing event-driven apps with serverless
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (16)
Similar a Build en Español - Serverless.pptx
Similar a Build en Español - Serverless.pptx (20)
Más de Luis Beltran
Más de Luis Beltran (20)
Último
Último (20)
Build en Español - Serverless.pptx
- 1. Serverless: Desarrollo de apps controladas por eventos Luis Beltrán Microsoft MVP
- 2. • Justificación • Informática controlada por eventos con Azure Functions • Apps controladas por eventos con Kubernetes • Kubernetes event-driven Autoscaling (KEDA) • Functions con Azure Arc • Para aprender más
- 3. La informática moderna se trata de eventos
- 4. ¿Qué es “controlado por eventos”?
- 6. Datos archivados Datos “en caliente” Modelo de datos sólido Servicios altamente conectados Patrones predecibles Sistemas distribuidos de hiperescala Bibliotecas de código cerrado Ecosistema e innovación de código abierto Tendencias que motivan a las apps activadas por eventos
- 7. Ecosistema serverless de Azure Ofertas serverless controladas por eventos Desarrollo local Monitoreo enriquecido Integración con IDEs Seguridad incorporada Opciones de implementación flexibles Cumplimiento y gestión
- 8. Funciones en la nube y el perímetro Planes de consumo y premium Escalabilidad Automática controlada por Eventos basada en Kubernetes Azure Arc y K8s autogestionado Apps, herramientas y runtime consistentes
- 9. Apps controladas por eventos con Kubernetes Soluciones híbridas — algunos datos necesitan ser procesados on-premises Requisitos específicos de cómputo (GPU, gran cantidad de memoria) Cumplimiento y consistencia — Directivas de Azure o requisitos de cumplimiento Aprovechando las inversiones existentes de Kubernetes
- 10. KEDA: Escalabilidad Automática controlada por Eventos basada en Kubernetes Kubernetes Event-Driven Autoscaling (KEDA) Componente open source para proporcionar un escalado parecido a funciones en Kubernetes para cualquier contenedor Herramientas nativas de Azure Functions y soporte a triggers Escala a cero o a miles Aprende más | https://github.com/kedacore/keda
- 11. Clúster de Kubernetes Escalador horizontal automático de pods Adaptador de métricas Escalador Controlador
- 12. Durable Functions Una extensión de Azure Functions que te permite escribir funciones con estado en un entorno de computación serverless. Simplifica las transacciones complejas y la coordinación (encadenamiento, etc.) Llama fácilmente a una Function desde otra Function, de forma sincrónica o asincrónica. Durable Functions
- 14. Demo - Durable functions con backend SQL
- 17. Acelera el desarrollo con servicios listos para ser utilizados Escribe una vez, ejecuta en cualquier lugar con Azure Arc Flexibilidad entre la productividad de PaaS y el control de Kubernetes
- 18. Demo – Azure Functions en Kubernetes con Azure Arc
Notas del editor
- Serverless is really a story about event-driven applications. Developing those applications are getting easier every day. I want us to go through this journey together. Let's see what it is, and all that is new in that space at Microsoft. Let's get started.
- Before we move forward, we'll need to define what event-driven even means. Also, we'll need to put it into context, and there's quite a few. There's event-driven with Azure Functions, but there's also the contexts of Kubernetes that we need to talk about. We're going to go through this by explaining what Kubernetes event-driven autoscaling, we always call it KEDA, as well as how we can use functions with Arc. We're going to finish this session with resources and possible next steps for you to learn more.
- Events are records of something that has happened, a change in state. They are immutable, they cannot be changed or deleted, and they are ordered in sequence of their creation. Now, interested parties can be notified of these state changes by subscribing to published events. Then on the information of the chosen on their business logic, they can act on it. The source of an event can be from internal or external inputs. Events can generate from a user or a mouse-click or keystroke, and even such as a sensor output.
- But what is event-driven? The event-driven architecture pattern is really popular way of making distributed asynchronous pattern, and it's used to produce highly scalable applications. This architecture is made up of loosely coupled single-purpose event processing components that asynchronously receive and process events. Event-driven is just that, it's an architecture pattern and it uses events to communicate between the coupled services. Event-driven applications are built with a serverless approach that use event-driven functions, event routing services, and API management.
- We went through the actual definition, but let's get down to what it is and what it really brings to you and your application. First, there's loosely coupled. What does it mean? It removed dependencies on other services. Your single service don't need to know that there are five or 10 other services depending on it, it just must do its job. It's highly scalable and distributed. What does that mean? Well, it means that we can handle massive amount of events. You add more instances of your application on multiple machines and even in different region. It becomes then highly compostable because in this scenario, it means that each event handling stand on its own, and your application can accomplish what it must do by building it block by block which brings us to an increase in efficiency. Because we can react to an event and triggers in the real-time, it means that we can also achieve a faster iterative development by having developers focus on their own blocks. Of course, that kind of application is extremely cost-effective. Since we're not pulling from a "what's new" every time, it means that we can only assign resources when we need them rather than all the time, giving us the ultimate payout, paying only for what you use.
- There are multiple trends that help motivate event-driven applications. Apps are built less to update data, but delivering result-connected applications. Department focus is no longer to keep the data consistent for predictable requested in response for clause, but to connect hyperscale distributed system that can be very unpredictable. Finally, consistent database have a scalability limits. But event stream as datastore can pretty much scale infinitely.
- Many modern applications are rapidly adopting event-driven serverless architectures due to the increasing demand for real-time application integration and data movement. Event-driven applications are built with a serverless approach that use event-driven functions, event routing and services, and API management. There are a few key services that we can highlight that are the components of event-driven applications. Azure Functions is the event-driven code. Logic Apps provides the workflows that can integrate with hundreds of different systems. Event Grid is an event broker that routes invents to interested consumers of the event. API Management is a central management of all your API endpoint. This is just not all-inclusive because there are many other services in the Azure ecosystem that you can use to build your event-driven application. More developers are spending more time writing code that allows them to add huge business impact with serverless. Microsoft offers numerous development tools such as IDE support for VS Code in Visual Studio, whether it is in functions or Logic App, it will also enable local development, visual to button capabilities, all which are tools of choice.
- Now, the good news is that Azure Functions runs everywhere. On Azure, it offers consumption plans and premium plans. Whether you want to scale to zero or want to have a stronger VMs, we got you covered. On Kubernetes, we enable containers autoscaling based on events that are happening all around your ecosystem. Finally, with Arc, we can do it on any Cloud or even in your own datacenter, which are self-managed Kubernetes. There's no better way to leverage a serverless advantages than using a fully managed service in the Cloud, like Azure Functions.
- But some application manage to run on disconnected environments, or require custom hardware and dependencies. Customers usually take a containerized approach for those scenarios in which Kubernetes is the de facto industry standard. Managing event-driven aware application in this environment is nontrivial and usually insufficient as it's only based on the resource usage, such as CPU or memory. When you run out of those, it's often too late, as your application may already be failing. It may also be as simple as wanting to leverage an existing Kubernetes cluster that you already have.
- KEDA is a product out of a partnership between Microsoft and Red Hat. KEDA means Kubernetes event-driven autoscaling. It is an open-source component for Kubernetes that provide an event-driven scale for any container workload. Enabling containers to scale from zero to thousands of instances based on event metric. Things like the land of an Azure queue or a Kafka Stream, and back to zero again when you're done processing. Since Azure Functions can be containerized, you can now deploy a function app to any Kubernetes cluster, keeping the same scaling behavior you would have on Azure Functions services.
- KEDA in a nutshell, will exist within your cluster, and based on your choice of an autoscaler, will monitor the events coming in and adjust your workload accordingly. As more events are coming in or as queue become larger, KEDA will automatically create more containers to handle the workload surge.
- Durable Functions is an advanced feature of Azure Functions. They provide the ability to write long running orchestrations using a single function while still being able to maintain a global state. Among the many used cases are function chaining, so when you want to run multiple functions in a specific sequence, or what we also call a fan out and a fan in. When you want to do multiple events that you want to process all in parallel, and then aggregate the final result and handle that result, or maybe you just want to run something synchronously and just have an HTTP pull on it and be able to notice that as a workload. There's so much more scenarios that we can cover.
- Today, I'm very happy to announce that available right now in public preview, we have two new durable backends. The Netherite provider is powered by Azure Event Hubs and the storage technology from Microsoft Research. It supports high-throughput workloads. Then there is a Microsoft SQL provider, which allows durable functions to run anywhere, including a non-Azure environment.
- Let's get configuring SQL durable backends in an environment right now in this demo. >> Let's open up an existing project and show you how to setup the SQL Server durable backend. Let's open up our project file. Then we need to ensure that we have the proper package referenced. You don't even need a durable functions package since this will be imported along. Let's go into our host.json file. We have to ensure that we select the right storage provider and it is set to MS SQL and that we have a proper connection string configured to our desired server. If we want, we can also configure our logs specifically for this new backend as well. Now that our application is configured, we need to set up our SQL server. Let's start with a blank server and run this quick script to initialize your database. Let's confirm that it exist. As you can see, it's empty. Let's initialize it for Durable Functions. Let's head back to our project and start debugging. Now, Azure Functions is warming up. As you can see, our CLI tool just loaded our project. Now, it's finding all the different functions that are available in our project. Although nothing seems to have happened, let's head back to our database and refresh the tables. We now have all the tables defined, ready to run Durable Functions, as well as some stored procedures that will be required for everything to work properly. Let's start a few orchestrators and let's just say 100. Then we can head back to our local server and see what we got. To do this, we'll need to start a new query. Let's write a select star from all of our instances that are available. We've got 100 instances that have been run successfully. It was fast as well. Let's close our development server for now. That proves that it works on my machine, but we're not shipping my machine. Let's show this in a better environment. Let's switch to Kubernetes. This Docker file is pretty boilerplate with a dotnet publish in a release configuration, as well as enabling the console logging to better capture what's happening inside a container. Finally, let's not forget our secret file that will import all of our connection strings. This time, it's targeting a database existing in our cluster. It is not targeting a local server anymore. Now, let's launch our function using this new command from our CLI to deploy our Azure Functions directly to Kubernetes. The only thing we need is to provide a few options and our secret filename. But before we run it, let's actually apply those secrets if you want to wrap the work successfully. Let's make sure the command is okay, and lets deploy it. As you can see, the application is currently deployed into Kubernetes. That's amazing. Just like any deployments, it takes just a little bit of time for everything to deploy. Let's wait a few more seconds. The deployment has been successful, and we can see right away that there are different functions available to us outside the cluster. If we run a kubectl get deployments, we can see our applications as well as our HTTP endpoint. If we run kubectl get scaled object, we can see our KEDA scalers that are using SQL server as a trigger for scaling behaviors. If you want to actually see the configuration of that scaler, we just need to add -o yaml and we get all the details on that specific trigger. There's connection strings, how we decide if we need to scale more or not, and the type of triggers that we're using as well. Let's invoke again the same orchestrators that we did earlier. For this time, we will do URL from our Kubernetes cluster. Let's make it a 100 again. But before we actually start, let's monitor our pods. We can do that by running kubectl get pods -w. This will create a watcher for us. Then we can start our orchestrator again. Let's head back quickly to our pod watcher before it finishes. As you can see, Kubernetes is now scaling our containers to handle load with 100 orchestrator, all starting at the same time on SQL Server. As much as it's fun watching the containers scale, let's check how well we're scaling. For this, let's run kubectl get hpa. HPA stands for Horizontal Pod Autoscaler. As you can see here, we have our minimum amount of pod, maximum amount of pods, as well as the current replicas. In our scenario, what we can see is how our Autoscaler is reacting to the amount of traffic that we're sending towards SQL Server. Let's run another kubectl get pods now. As you can see, all ten of our pods are currently running and doing well. Just like that, we've gone through how the SQL Server durable backend works, what you'll need to configure it, and how it will run locally, as well as in a Kubernetes environment. Let's now head back to the slides.
- >> All right. That demo was great. Now the question is, when would you want to use KEDA? Well, there are multiple scenarios. Whether you want to run functions on-premises or in intelligent edge, it is one of the good scenarios for this as well. Also, when you already have an existing Kubernetes clusters, it is an ideal scenario to leverage your existing investment. If you have resources in different Cloud or you love Azure Functions but you want to be able to run them everywhere, KEDA helps you out as well. Finally, there's some times where you just want to be able to manage the scale and to compute of your Azure Functions, and you really want full control, well, KEDA handles that for you.
- Let’s talk about some exciting stuff coming to Azure Application Services. Now in preview, customers don't have to choose between the productivity of Platform as a Service and the control of Kubernetes. Because the same application services can run with either model. The application services are now Azure Arc enabled. Which means customers can deploy Web Apps, functions, API gateways, Logic Apps, and the banquet services on pre-provision Kubernetes clusters, taking advantage of features including deployment slots for AB testing, storage cue triggers, and out of the box connectors from the application services regardless of where they run.
- The three key benefits you get from using Azure application services are, enable your development team to accelerate the continuous development and deployment of their applications using purpose-built services. Your organization can now choose between hosting the PaaS services on Azure or on your own Kubernetes if added control is required, or if the application needs to run outside of Azure. Lastly, with Arc, you can now build your applications once and run them anywhere.
- I'm now going to show you running Azure functions on Kubernetes with Azure Arc. Let's have a look at the demo. In this demo, I'm going to create a new function app that will host my application. However, I need to have this running on my own data center. I'll give it a name called contosofarmsnwv3. I'll select Python and then choose the location to create this application. As you can see, there are new custom occasions that are now available to me beyond the standard Azure regions that would normally host my application. I'm not going to walk through all the standard create experiences as if I was deploying this on an Azure region instead of my custom location. I click "Create", and then this new app will get deployed on my Kubernetes environment that is represented by the custom location, contosofarmsnorthwest. I'll go to the resource. You can see here, that has the same management experience as if it was in Azure, so a consistent way of managing applications, no matter where they run. If I click into the URL of the application, you can see that the function app is running on a Kubernetes environment. I'll then switchover to create a function using VSCode and deploy it to this application. If I look at my subscription, you can see that the new function app I just created running on Kubernetes is available within VSCode. I'm not going to create the code and deploy to this application. I'll select Python and a simple HTTP trigger and give it the name ProcessDevice. This will create all of the code required to fully test this locally, as well as make it deployable on the Kubernetes environment. If I set a break point and then debug the application, I can test that it is working correctly locally within VSCode before I publish it. You can see it hit the breakpoint that allows me to inspect the values and confirm that it's working correctly. I'll now publish this up to the function app I just created that is running on the Kubernetes environment. I'll zip up the project and then use the same AZ function app commands that I would use if running on Azure to publish the code. This gives the same development experience, whether developing for Azure or on a Kubernetes cluster. That published successfully. Now we can hit the same HTTP trigger that I tested locally up on the function app in Kubernetes to confirm things look good. I'll now show how all this is made possible. I'm now back in the portal and I'll go down to the contosofarmssouthwest resource group. You can see that I have the Kubernetes cluster that is registered with Arc, so I can manage it from Azure. Arc-enabled clusters have the extensions capability to enable services on Kubernetes to be deployed. I have deployed our application services including Web Apps, Logic Apps and functions in the Microsoft.Web.Appservice extension onto the cluster. Now that the services are deployed, I can create a custom location to map to this little cluster. You can see that southwestfarms is enabled as an Arc-enabled service, and it maps to the cluster that we just registered. If I go back to create a function app, you can see the custom location that we just reviewed is now available. This enables a consistent developer experience, whether building and running your apps on Azure or on Kubernetes.
- If you'd like to learn more about the topics we covered today, please visit the KEDA site or the new site on using Durable Backends, or read the blog announcing our Azure Application Services on Azure Arc. >> Thank you so much, and I hope that you all enjoyed them and as much as I enjoyed them. We hope that you have an amazing Build and we hope to see you soon.