This is just the kind of article I have been looking for to provide some scientific reasoning behind choosing serverless versus Kubernetes and certainly it has made it clear to me that serverless is not a good fit for most use cases and for my use cases in general. The only reason to using Functions is the low cost in most situations, however this is a fallacy when comparing the downsides, mostly that a simple hello world api call takes at least 300-400 ms and inter service communication is slow.
Adding to that it is very cumbersome to develop and debug all the services on a single development machine because there is no orchestration of running the functions apps locally, so ideally you would need to use kubelet to run it in and you might as well then just Kubernetes.
That being said I have used Functions for some time, however I can also confirm that is sometimes unstable and slow at least in consumption mode and the fact that VNET is not mandatory is also concerning and cold start is a problem.
I have the same experience with API Management consumption tier, it is very difficult to debug since the servers running the service is masqueraded in a shared environment. I have yet to send enough trafic through it to test the performance properly, but I have implemented a production system with low trafic with this service and Logic Apps, which is working very nicely.
Thanks for posting a follow up article with your implementation of the .Net 5 app. I would also like to see how you would setup Kubernetes for production purposes and also how the whole infrastructure would look in a diagram. As well as the reasoning behind using F# instead of C#. Also does Azure provide enough benefit for example service/feature wise whilst using Kubernetes that it makes sense to still Azure or would a cheaper provider like Digitalocean suffice?
Why F# and not C# is a huge topic with a lot of googleable links on it already, I will simply say that after countless years with C# and early experience with a bunch of other low-level and OOP languages I am fully sold on the simplicity and elegance of F# and the functional paradigm ..
I will try to find time for another post on setting up AKS with Traefik etc.
Missed the question about AKS alternatives - I guess there are viable ones for sure, hoping to find time in the future to test GKE for example ... The context of the above article was an already built Azure-Functions-based microservice system, which was easier to migrate to AKS (and stay inside Azure for the other integrated services like AppInsights, KeyVault, Event Hubs, Storage etc) rather than migrate to another cloud ...
So not sure if an additional post of mine is actually needed ...
Maybe what is not covered is the automatic renewal of Letsencrypt certificates for which we have created a custom .net app/pod to do that, based on someones F# code, need to dig it out ...
I have just read the article you mentioned for configuring Traefik and it is great, however I would like to know how an AKS cluster might look like in a real world production app.
There is a lot to learn from it such as service mesh, health checks, monitoring, interservice communication, shared or non shared databases, etc..
So if you get the time I would look forward to reading an article on how such an AKS cluster would look like, ideally based on your own real world production microservices app.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is just the kind of article I have been looking for to provide some scientific reasoning behind choosing serverless versus Kubernetes and certainly it has made it clear to me that serverless is not a good fit for most use cases and for my use cases in general. The only reason to using Functions is the low cost in most situations, however this is a fallacy when comparing the downsides, mostly that a simple hello world api call takes at least 300-400 ms and inter service communication is slow.
Adding to that it is very cumbersome to develop and debug all the services on a single development machine because there is no orchestration of running the functions apps locally, so ideally you would need to use kubelet to run it in and you might as well then just Kubernetes.
That being said I have used Functions for some time, however I can also confirm that is sometimes unstable and slow at least in consumption mode and the fact that VNET is not mandatory is also concerning and cold start is a problem.
I have the same experience with API Management consumption tier, it is very difficult to debug since the servers running the service is masqueraded in a shared environment. I have yet to send enough trafic through it to test the performance properly, but I have implemented a production system with low trafic with this service and Logic Apps, which is working very nicely.
Thanks for posting a follow up article with your implementation of the .Net 5 app. I would also like to see how you would setup Kubernetes for production purposes and also how the whole infrastructure would look in a diagram. As well as the reasoning behind using F# instead of C#. Also does Azure provide enough benefit for example service/feature wise whilst using Kubernetes that it makes sense to still Azure or would a cheaper provider like Digitalocean suffice?
Hi @casperrubaekm ,
Why F# and not C# is a huge topic with a lot of googleable links on it already, I will simply say that after countless years with C# and early experience with a bunch of other low-level and OOP languages I am fully sold on the simplicity and elegance of F# and the functional paradigm ..
I will try to find time for another post on setting up AKS with Traefik etc.
Missed the question about AKS alternatives - I guess there are viable ones for sure, hoping to find time in the future to test GKE for example ... The context of the above article was an already built Azure-Functions-based microservice system, which was easier to migrate to AKS (and stay inside Azure for the other integrated services like AppInsights, KeyVault, Event Hubs, Storage etc) rather than migrate to another cloud ...
Br,
Deyan
Sounds like I should take F# for a spin sometime.
Yes it makes sense to stick with Azure since you are heavily invested in supporting services like AppInsights and KeyVault.
For hosting pure .NET 5 apps you need:
I see there some excellent articles on setting up AKS with Traefik - e.g. [this one from Kumar Allamraju](kumar-allamraju.medium.com/using-t...
Also Aad Pod Identity is quite well-documented, even MS is building it into AKS ...
So not sure if an additional post of mine is actually needed ...
Maybe what is not covered is the automatic renewal of Letsencrypt certificates for which we have created a custom .net app/pod to do that, based on someones F# code, need to dig it out ...
Thanks.
I have just read the article you mentioned for configuring Traefik and it is great, however I would like to know how an AKS cluster might look like in a real world production app.
There is a lot to learn from it such as service mesh, health checks, monitoring, interservice communication, shared or non shared databases, etc..
So if you get the time I would look forward to reading an article on how such an AKS cluster would look like, ideally based on your own real world production microservices app.