backend services on an as-used basis. Servers are still used, but a company that gets backend services from a serverless vendor is charged based on usage, not a fi xed amount of bandwidth or number of servers.
Microsoft Azure. • I have used Azure and AWS in production. Worked on entire serverless platforms in both Azure and AWS. • My big bias: delivery > perfection.
of my experience • De fi nitely developer-centric, with lots of architect-y opinions • Discussion on the two major serverless options: • “Turnkey” functions • Container hosting models
about “the right way” • A recommendation on any particular cloud provider for .NET • Dogmatic • You may disagree with some things I say • I also cannot know everything
Tooling - Visual Studio, Rider, .NET CLI, AWS CLI, GCloud CLI • Deployment • Monitoring • Maturing past “basic” functions • Nuance! (Or as much as I could add in)
Azure Functions that execute inside of the Functions host process • Isolated - runs inside a worker process https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-in-process-di ff erences
.NET versions Long Term Support (LTS) versions All supported versions + .NET Framework Core packages Microsoft.NET.Sdk.Functions Microsoft.Azure.Functions.Worker Microsoft.Azure.Functions.Worker.Sdk Durable Functions Supported Supported (public preview) HTTP trigger model types HttpRequest / ObjectResult HttpRequestData / HttpResponseData Dependency injection Supported Supported Middleware Not supported Supported Logging ILogger passed to the function ILogger<T> via dependency injection ILogger/ILogger<T> obtained from FunctionContext or via dependency injection Cancellation tokens Supported Supported Cold start times (Baseline) Additionally includes process launch https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-in-process-di ff erences
have the option for your containers to scale down to zero if needed. Obviously this wouldn't help with the cold start issues we've covered above, but it's also possible to set a minimum number of replicas for your container, which would have much the same effect as the Premium Functions plan mentioned above. However, there's a potential advantage over the Premium Functions Plan; the notion of containers becoming inactive - meaning they are still provisioned but idle - in which state the cost is significantly lower. Azure Container Apps
of code to respond to events and/or starting out. HTTP APIs as well… if you don’t mind the cold start. • Azure Functions Premium - great “next level” destination for Azure Functions if you need to help eliminate cold starts, but more expensive (obv) • This article describes spinning this up temporarily when anticipating tra ffi c spikes, then spinning it back down to normal Consumption after the work is done. (Example: https:// www.davepaquette.com/archive/2020/05/23/scaling-azure-functions-from-consumption- plan-to-premium-hosting-plan.aspx) • Azure Container Apps - gives more fl exibility for building scalable apps • Azure App Service - I use these for more general purpose web app hosting, especially if I need predictable pricing and easy, fl exible scale up, easy web con fi guration, etc. https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
pretty much every way • AWS Serverless Application using Lambdas - almost certainly the direction I would go • AWS App Runner - akin to Container Apps • AWS Fargate - lower level than App Runner • Great article about nuanced di ff erences btwn Fargate and App Runner: https://cloudonaut.io/fargate-vs-apprunner/ • AWS Elastic Beanstalk… kind of like App Service but apparently it’s way worse?
and Lambdas in pretty much every way • Cloud Run - managed container system akin to Azure Container Apps/AWS App Runner • App Engine - generalized app hosting akin to App Service • Detailed cost comparison of Functions vs Run • https://medium.com/google-cloud/cloud-run-vs-cloud-functions-whats- the-lowest-cost-728d59345a2e
to have been chosen already • Your architecture should only be as complicated as it needs to be • Bias getting stu ff done > overthinking what scale you think you MIGHT need • Cloud costs are easy to lose control of - ensure you’re monitoring well. • https://www.troyhunt.com/how-i-got-pwned-by-my-cloud-costs/
of functionality, especially when cold starts aren’t super critical. • LOVE it for event-driven stu ff . • All cloud providers have a way of “promoting” functions, mainly to eliminate cold starts and manage costs/resources better. You will probably know when you feel you need to do this. • Spencer’s case study
Lambda Serverless Cloud Functions "Premium" Functions Azure Functions Premium Provisioned Concurrency* Cloud Run Minimum instances* Container abstractions Azure Container Apps AWS AppRunner Cloud Run Lower-level container abstractions Azure Container Instances AWS Fargate Cloud Run I guess? K8S aka The Big Time Azure Kubernetes Service Amazon EKS (Elastic K8S Service) Google Kubernetes Engine General App Host App Service Elastic Beanstalk App Engine * mainly good for eliminating cold starts and is pricey for what it is
schneidenbach
manfredsteyer
yug1224
matsuo_atsushi
yusukebe
pocke
masuda220
skrb
tatsuhiro
chiroruxx
hyshu
takter00
danielsogl
techseoconnect
signer
jakevdp
maggiecrowley
chriscoyier
gurzu
erikaheidi
marktimemedia
jeffersonlam
soudai
yeseniaperezcruz
ipullrank
![@schneidenbach [email protected]](https://files.speakerdeck.com/presentations/dc600cace7b94333bf842e3c8e97f723/slide_1.jpg){kind=link}
![Thank you! schneids.net @schneidenbach [email protected]](https://files.speakerdeck.com/presentations/dc600cace7b94333bf842e3c8e97f723/slide_122.jpg){kind=link}