Serverless mest lämpat för att köra applikationer i molnet och containers on-prem

”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.”

När det blir tal om hur man 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.

Sen jämför den andra artikeln ä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” inklusive Spring boots 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 så det är ännu mer sällan docker är ett bättre val…

Sen kan man som sagt deploya vanliga web appar, api appar och spring boot appar till App Services med så containers är inte det bästa valet i molnet.

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 dessutom en massa overhead som containers medför för dessa innehåller ett lite 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 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.

Vendor lock-in blir nästan aldrig 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 framtids säkrare?

Med tanke på konkurrensen mellan Goggle, Microsoft och Amazon lär Azure knappast bli sämre med åren heller utan snarare tvärtom, för är det nåt Microsoft är bra på så är det att komma i kapp och gå om.

När det gäller nyutveckling i Azure kan man till och med tillåta både .Net Core/C# och Spring boot/Java till och med i samma projekt om möjligt, för att dra fullt nytta av alla utvecklares kompetenser och specialområden.

Även om Java numera stödjs tillräcklig bra (det måste man först försäkra sig om för varje app typ man vill göra ) tror jag att .Net Core/C# alltid kommer ha bäst stöd i Azures PaaS lager och vara det som ligger i framkant, och dessutom är bäst dokumenterat gällande Azure o.s.v.

Vissa saker kommer man antagligen vara tvungna att göra i .Net Core även i framtiden, även om mycket också kommer kunna göras i Java.

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 skapa merarbete som t.ex. ORM ramverk som hibernate, dockers i stället för att deploya direkt till App Services, eller serverless frameworks som dessutom innebär att man tappar funktionalitet och inte kan utnyttja en molnleverantörs serverless teknologi fullt ut.

Serverless Computing vs. Containers

Serverless vs. Containers

Serverless in Azure

Slutligen ett bra exempel på hur flexibelt och modernt det är att utveckla mot Azures PaaS lager som är en swizz army knife av serverless tjänster färdiga att använda.

Serverless web application on Azure