”Comparing containers vs serverless computing is like comparing running an application on-premises in the local data center or running it in the cloud. At the end of the day, someone must manage the infrastructure and pay for it. Containers are best suited to build a serverless computing framework and relieve the end user of infrastructure management-but comes at a cost.”
”Users need to find a balance between the cost and complexity such that serverless computing can justify the extra cost of offloading infrastructure management. Serverless computing and FPaaS (function platform as a service) are best suited for running applications in the public cloud and containers are useful in transforming on-premises hardware resources into a private cloud.”
Serverless Computing vs. Containers
När det blir tal om hur ni ska effektiviserad er infrastruktur och vad och hur man ska köra saker i molnet är jag helt i linje med den första artikeln på den punkten som anser att serverless som Azures App Services i princip är är förstahandsvalet i molnet och containers bara on-prem.
När man deployar saker till Azure så är det enklaste och kostnadseffektivaste sättet att deploya till Azure App Services (Serverless) vare sig det är frågan om vanliga .Net Core appar, Spring boot appar eller Azure Functions, så detta bör vara förstahandsvalet för nyutveckling.
Man slipper då mellanstegen med att först wrappa saker i containrar som måste konfigureras och byggas, och sen deploya dem till ett container repository varifrån man deployar till antingen Container instances, Web app for containers eller det mest avancerade alternativet Azure kubernet services.
Man slipper då lite overhead som containers medför för dessa innehåller ett litet mini os (man kan även se libbarna så) som också måste underhållas förutom appen som körs i dem, och det måste byggas, dimensioneras, konfigureras o.s.v, så det blir extra steg och lite mer overhead jämfört med att deploya direkt till Azures App Service tjänst.
Däremot håller jag med artikelförfattarens slutsats om att containers och kubernets passar utmärk om man vill effektivisera sin on-prem infrastruktur och de legacyappar man kör där, eller för att enkelt kunna deploya dessa till Azure.
Containers och kubernets passar bra till det men bör inte vara förstahandsvalet för nyutveckling i molnet då det finns enklare och smidigare sätt att köra saker på i Azure App Services.
Med tanke på konkurrensen mellan Goggle, Microsoft och Amazon lär Azure knappast bli sämre med åren heller utan snarare tvärtom.
”Deliver more value to the core of your business by minimizing the time and resources you spend on infrastructure-related requirements. Use fully managed, end-to-end Azure serverless solutions to boost developer productivity, optimize resources, and accelerate the pace of innovation.”
När det gäller nyutveckling i Azure kan man använda både .Net Core/C# och Spring boot/Java och diverse andra språk.
Även om Java numera stödjs någorlunda bra för vanliga webbappar (det måste man först försäkra sig om för varje app man vill göra och vilka tjänster i Azure man vill utnyttja i sin app ) tror jag att .Net Core/C# alltid kommer ha bäst stöd i Azures PaaS lager och vara det som ligger i framkant gällande SDK’s.
Dessutom är .Net bäst dokumenterat gällande Azure, har bäst tredjeparts resurser för hur man gör saker i Azure, bäst community support o.s.v.
Många saker kommer man antagligen vara tvungna att göra i .Net Core även i framtiden, även om många saker också kommer kunna göras i Java så måste ni välja så välj det säkra kortet i Azure som är C#/.Net Core.
Serverless jämfört med containers i Azure
”Serverless gives you a lot of productivity gains, at the expense of control over your infrastructure. For a lot of our workflows—web APIs, stream processing, cron jobs, etc.—we don’t need all that control and it’s actually a blessing that someone else can take care of the plumbing for us.”
Sen jämför den andra artikeln här äpplen och päron när den jämför endast functions med docker/containers för egentligen är allt man kan köra i Azures App Services serverless och man kan själv välja plan och få den prestanda man behöver.
Begränsningarna gäller dessutom bara vanliga functions men numera finns även durable functions i Azure som inte har de begränsningarna vanliga functions har, och sen finns även webjobs, så det är mer sällan docker är ett bättre val i Azure.
Sen kan man som sagt deploya vanliga webbappar, webapi appar och spring boot appar till App Services med, så kubernetes är inte det bästa valet i Azure i vanliga fall.
Vill man ha maximal utväxling och nytta av en plattform så måste man acceptera viss vendor lock-in
”For all the attention that it has received, vendor lock-in is a danger that has come to pass for a precious few. Instead, you are far more likely to find over-engineered solutions to prevent vendor lock-in that instead create other forms of lock-in, be it with internal teams or with other private cloud vendors.”
Vendor lock-in blir ofta inte ett problem i verkligheten så det kostar oftast betydligt mer än det smakar att försöka gardera sig mot det, och både Java och .Net Core är open source numera.
Java har dessutom på senare tid blivit mer kommersialiserat så frågan är om inte .Net Core är mer open source än java numera och framtidssäkrare?
Vill man ha maximal utväxling och nytta av en plattform så måste man acceptera viss vendor lock-in och ta smällen någon gång i framtiden om det skulle behöva skrivas om saker, och det gäller oavsett om man kör saker i Azure, AWS eller GC.
Alla ansträngningar att undvika vendor lock-in ger overhead genom att öka komplexiteten och skapar merarbete som t.ex. serverless frameworks, som dessutom innebär att man tappar funktionalitet och inte kan utnyttja en molnleverantörs serverless teknologi fullt ut.
Däremot kan man enkelt undvika de svåraste fallen av vendor lock-in utan att förlora särskilt mycket på det genom att undvika att använda de olika molntjänsternas low-code och no-code plattformar, för det är rätt enkelt att göra något som en C# Funktion i stället för en logic app eller en Asp.Net Core Blazor Server webbapp i stället för en Power App o.s.v.
Exempel på en serverless webbapplikation
”This reference architecture shows a serverless web application. The application serves static content from Azure Blob Storage, and implements an API using Azure Functions. The API reads data from Cosmos DB and returns the results to the web app.”
Serverless web application on Azure
Slutligen ett exempel på hur det är att utveckla mot Azures PaaS lager som är en swizz army knife av serverless tjänster färdiga att använda, och ovanstående exempel är nog avsett för en webbsajt som ska serva filer och dokument till användare.
För en databasdriven webbsajt hade det räckt med en Blazor Server webbapp som bara använder sig av SQLServer via EF Core. Då hade vi bara haft en SQLServer tjänst i den gråa rutan.
Är det dessutom en publik webbsajt och inte en företagsintern som en medlems sajt som sköter inloggningen internt på det klassiska sättet med Identity i stället för via Azure AD och lagrar användarna i sin egen databas, och sen inte använder CI/CD pipelines så slipper vi även de två tjänsterna som sköter det utanför de gråa rutorna.
Då hade det även räckt med ett traditionellt webbhotell för även traditionella webbhotell är molntjänster och utmärkta för att hosta webbsajter på om man bara har det behovet.
Med det vill jag säga att bara för att det finns en massa serverless tjänster att välja på ska man inte göra en krångligare lösning än man behöver, så motstå frestelsen att göra det bara för att det går.
Microservice arkitekturen är inte alltid bästa valet
”Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden. Like any architectural style, microservices bring costs and benefits. To make a sensible choice you have to understand these and apply them to your specific context.”
Även om serverless och containers är bra i många fall för större organisationers behov och Functions och containers gör det lätt att använda microservice arkitekturen så är inte alltid bästa valet att göra en microservice arkitektur, för microservice arkitekturer har inte bara fördelar utan även nackdelar.
Det kan många gånger vara bättre att göra en traditionell monolitiskt webbapplikation i Asp.Net Core MVC eller Blazor Server i stället som som använder SQLServer än en mer komplex micro service arkitektur.
Ett annat exempel kan vara API’er där man rätt enkelt kan göra en microservice arkitektur genom att göra Functions eller Logic Apps som hanterar varsin endpoint, i stället för en Asp.Net Core WebAPI applikation som hanterar alla relaterade endpoints för ett specifikt API.
Trots det kan det ofta vara enklare och kostnadseffektivare att göra API’et som en monolitisk Asp.Net Core WebAPI applikation om det inte finns särskilda skäl till att välja microservice arkitekturen i stället.
Om ni ska välja en microservice eller monolitiskt arkitektur är alltså någon som måste avgöras från fall till fall där man funderar igenom de för och nackdelar som Martin Fowler tar upp i sin artikel.
Robert Forsström's Blogg 