El camino a las Cloud Native Apps - Introduction
•Als PPTX, PDF herunterladen•
1 gefällt mir•156 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie El camino a las Cloud Native Apps - Introduction
Ähnlich wie El camino a las Cloud Native Apps - Introduction (20)
Mehr von Plain Concepts
Mehr von Plain Concepts (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
El camino a las Cloud Native Apps - Introduction
- 2. WE’RE HERE AND THERE
- 3. “No pienses como tu sistema es capaz de funcionar en la infraestructura de la nube, cuando pienses en la nube, hazlo sobre el valor que esta te va a proporcionar”
- 4. ¿Qué valores queremos ganar? Agility CI / CD Containers Serverless TTM Scalability HA Insights / Analytics TCO Infraestructure Cost Maintenance IT Standarization Simplification
- 6. Lift and Shift ( On-prem 2 Cloud IAAS) • No re-architect / No new code • Quick Migration But • Small cloud value • Manual actions • Limited scaling / high availability
- 7. Lift and Shift ( On-prem 2 Cloud IAAS) • Availability Sets (99.95%) • Protection agains failures within data centers • Avalilability Zones (99.99%) • Protection from entire datacenter failures • 42 Region Pairs • Data Residency compliance
- 9. Cloud Native Apps • Main bullets • App Services • DevOps • Automation infrastructure • CI / CD • Monitoring • Containers
- 14. Platform support
- 15. App Service Core Capabilities All features and capabilities are shared across all of App Service application (Web, Mobile, Functions and API) Enterprise grade Designed for secure mission-critical applications Fully managed Optimized for Availability and Automatic scale Built for DevOps Agility through Continuous Deployment Premium Tier App Service Environments Hybrid Connections / VPN Support Scheduled Backup Azure Active Directory Integration Site Resiliency, HA, and DR Role Base Access Control Audit / Compliance Enterprise Migration Client Certs IP Restrictions/ SSL Dedicated IP address IP / NSG Web Sockets WW Datacenter Coverage Automated Deployment AutoScale Built-in Load Balancing WW Datacenter Coverage End Point Monitoring & Alerts WildCard Support HTTP Compression WebJobs Sticky Sessions OS & Framework Patching Auto-Healing Local Cache Init Module Per Site Scaling Easy Auth Remote Debugging w/ Visual Studio Site Staging Slots /Preview Traffic Routing Continuous Integration/Deployment Git/ Hub, Visual Studio Team Services App & Site Diagnostics Site Extensions/ Gallery NET, PHP, Python, Node, Java, Go Framework Installer Browser-based editing Logging and Auditing Admin-Site Support Portal Web Jobs / SDK 1.1 Recommendation Engine Site Cloning
- 18. • Declarative, model based specification of resources and their configuration / code/ extensions • Idempotent and ‘replayable’ • Source file, checked-in • Parameterized input/output Infrastructure as code SQL - A Website Virtual Machines CRUD Website [SQL CONFIG] VM (2x) DEPENDS ON SQLDEPENDS ON SQL SQL CONFIG
- 20. • PowerShell • Portal • Visual Studio • Azure CLI • REST API New-AzureRmResourceGroupDeployment -Name ExampleDeployment -ResourceGroupName ExampleResourceGroup -TemplateFile <PathToTemplate> -TemplateParameterFile <PathToParameterFile> Infrastructure as code
- 21. Demo Infrastructure as code www.plainconcepts.com info@plainconcepts.com
- 23. What are the benefits?
- 27. Local debugging
- 33. backends
- 34. ? ? ? processing
- 38. applications
- 39. Why do we need “Durable Functions” • Enable “long running” functions while maintaining local state. • Simplify complex Function coordination (chaining, etc.) • Easily call a Function from another Function • All of the above using code-only
- 40. What is Durable Functions? • Advanced feature for writing long-running orchestrations as a single C# function. No JSON schemas. No designer. • New orchestrator functions can synchronously or asynchronously call other functions. • Automatic checkpointing, enabling “long running” functions. • Solves a variety of complex, transactional coding problems in serverless apps. • Built on the open source Durable Task Framework.
- 41. Pattern #1: Function chaining - Today Problems: • No visualization to show relationship between functions and queues. • Middle queues are an implementation detail – conceptual overhead. • Error handling adds a lot more complexity. F1 F2 F3 F4
- 42. Pattern #1: Function chaining - Better // calls functions in sequence public static async Task<object> Run(DurableOrchestrationContext ctx) { try { var x = await ctx.CallFunctionAsync("F1"); var y = await ctx.CallFunctionAsync("F2", x); var z = await ctx.CallFunctionAsync("F3", y); return await ctx.CallFunctionAsync("F4", z); } catch (Exception) { // global error handling/compensation goes here } }
- 43. Pattern #2: Fan-out/Fan-in - Today Problems: • Fanning-out is easy, but fanning-in is significantly more complicated • Functions offers no help with this scenario today • All the same problems of the previous pattern F1 F2 F3
- 44. Pattern #2: Fan-out/Fan-in - Easy public static async Task Run(DurableOrchestrationContext ctx) { var parallelTasks = new List<Task<int>>(); // get a list of N work items to process in parallel object[] workBatch = await ctx.CallFunctionAsync<object[]>("F1"); for (int i = 0; i < workBatch.Length; i++) { Task<int> task = ctx.CallFunctionAsync<int>("F2", workBatch[i]); parallelTasks.Add(task); } await Task.WhenAll(parallelTasks); // aggregate all N outputs and send result to F3 int sum = parallelTasks.Sum(t => t.Result); await ctx.CallFunctionAsync("F3", sum); }
- 45. Pattern #3: HTTP Async Response Problems: • Execution state needs to be explicitly stored and managed. • Execution state and trigger state must be kept in sync manually. • Start and GetStatus is often boilerplate code that is not related to the business problem. Start DoWork GetStatus
- 46. Pattern #3: HTTP Async Response – Built in! > curl -X POST https://myfunc.azurewebsites.net/orchestrators/DoWork -H "Content-Length: 0" -i HTTP/1.1 202 Accepted Location: https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec Server: Microsoft-IIS/8.0 > curl https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec -i HTTP/1.1 202 Accepted Content-Length: 173 Content-Type: application/json Location: https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec Server: Microsoft-IIS/8.0 {"runtimeStatus":"Running","createdTime":"2017-03-16T21:20:36Z","lastUpdatedTime":"2017-03-16T21:20:47Z"} > curl https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec -i HTTP/1.1 200 OK Content-Length: 175 Content-Type: application/json Server: Microsoft-IIS/8.0 {"runtimeStatus":"Completed","createdTime":"2017-03-16T21:20:36Z","lastUpdatedTime":"2017-03-16T21:20:57Z"}
- 47. Pattern #5: Human Interaction w/Timeout RequestApproval Escalate ProcessApproval Problems: • Can’t easily coordinate a timeout with an approval request notification. • Need a mechanism to reliably cancel either the approval handling or the timeout depending on the outcome.
- 48. Pattern #5: Human Interaction w/Timeout public static async Task Run(DurableOrchestrationContext ctx) { await ctx.CallFunctionAsync<object[]>("RequestApproval"); using (var timeoutCts = new CancellationTokenSource()) { DateTime dueTime = ctx.CurrentUtcDateTime.AddHours(72); Task durableTimeout = ctx.CreateTimer(dueTime, 0, cts.Token); Task<bool> approvalEvent = ctx.WaitForExternalEvent<bool>("ApprovalEvent"); if (approvalEvent == await Task.WhenAny(approvalEvent, durableTimeout)) { timeoutCts.Cancel(); await ctx.CallFunctionAsync("HandleApproval", approvalEvent.Result); } else { await ctx.CallFunctionAsync("Escalate"); } } }
- 49. Important Orchestrator Limitations • Orchestrator code is replayed on every rehydration to restore all local state (local variables, etc). • Function calls are never replayed – the outputs are remembered. • This requires the orchestrator code to be deterministic. • Rule #1: Never write logic that depends on random numbers, DateTime.Now, Guid.NewGuid(), etc. • Rule #2: Never do I/O directly in the orchestrator function. • Rule #3: Do not write infinite loops • Rule #4: Use the built-in workarounds for rules #1, #2, and #3
- 50. THANKS FOR YOUR TIME www.plainconcepts.com info@plainconcepts.com
Hinweis der Redaktion
- Explicar los valores que queremos ganarcon la modernización - Agilidad Time To Market TCO IT
- Cloud IAAS -> Lift and Shift Cloud Service -> Cloud Service Ready Cloud Native
- Positioning
- Marketing positioning: Logic apps is also part of App Service but for developers it’s important to understand concepts of App Service Plan and Apps apply to the four above, but not Logic Apps
- .NET CLR: 2.0, 4.0 The default is CLR 4.0. Framework: up to 4.6 The default is .NET Framework 4.6 (currently .NET 4.6.1). ASP.NET Core is also supported either through Kudu or Web Deploy Node.js (and matching npm) To get the full list of supported Node and npm: Go to https://[yoursite].scm.azurewebsites.net/ Click on 'Runtime versions' under API PHP 5.4 5.5 5.6 7.0 The default is PHP 5.4. Python 2.7 3.4 Java [Jetty, Tomcat] 1.7.0_51
- Before we dive into App Service details, let’s talk about APIs – because we are following the API-centric approach in our demo
- Guión
- Building on top of the FaaS programming model, Azure Functions keep all the mentioned features and extend your possibilities with additional capabilities that help to reduce your development time and boost productivity, while using best in class tools.
- Additional information Triggers and bindings – https://docs.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings Monitoring—https://azure.microsoft.com/en-us/services/application-insights/ Local debugging—https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local#run-functions-locally CI/CD—https://docs.microsoft.com/en-us/azure/azure-functions/functions-continuous-deployment Run locally—https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local Proxies—https://docs.microsoft.com/en-us/azure/azure-functions/functions-proxies
- There is a lot of code you can save thanks to the Functions programming model based on triggers and bindings, as this code to connect to different services (either for trigger data and input/output operations) is done by the platform, improving your development time as you don’t lose a minute on connections code that tend to be reused a lot of times. See the full list of services with Triggers and bindings – https://docs.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings
- Additional information Languages—https://docs.microsoft.com/en-us/azure/azure-functions/supported-languages Dev options— Azure Functions portal—https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function Visual Studio—https://docs.microsoft.com/en-us/azure/azure-functions/functions-develop-vs Visual Studio Code—https://code.visualstudio.com/docs CLI—https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function-azure-cli Java/Maven—https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-java-maven Hosting options—https://azure.microsoft.com/en-us/pricing/details/functions/ Durable Functions—https://docs.microsoft.com/en-us/azure/azure-functions/durable-functions-overview
- https://github.com/Azure/durabletask
- CallFunctionAsync uses queues under the covers, thus they can be scaled out to multiple VMs.
- Logic Apps and Microsoft Flow have built-in support for this pattern. Note that specifics URL routes are subject to change (and have already changed since this deck was originally written).
- We will expose a mechanism for sending named events to an orchestrator from outside the orchestration context – e.g. REST API and/or output binding.