JavaScript and Friends Conference Organizer,Dot Net Open Source Days Organizer, Community Meetups Organizer,Auth0 Ambassador, CloudinaryMDE, NativeScript, Vue Enthusiast, Azure Solutions Architect
This is good to see a practical view about Kubernetes. Yes I agree to all your points. In my opinion Kubernetes is not for all applications.
If we want our applications to be running all the time, so that we don't lose revenue to our competitors then Kubernetes will help solve that problem. This purely works for e-commerce ordering systems.
If we want our applications to have the behavior of self healing, I think Kubernetes solves that problem.
With Azure Functions we can develop as many services and have them scale as required, but it comes with a cost. The consumption plan does not have control on the region where the function would be hosted. This would add some concerns to teams where there is strict requirement to maintain services with in their geographic region. But recently Azure Functions came up with Premium plan which is in preview mode and it might solve some geographic region requirements through VNET access. I am not sure about AWS Lambda.
You're 100% correct and pragmatic my friend. However, K8 still feels like a pain to me. Why not looking at "more mature" solutions, like Service Fabric?
JavaScript and Friends Conference Organizer,Dot Net Open Source Days Organizer, Community Meetups Organizer,Auth0 Ambassador, CloudinaryMDE, NativeScript, Vue Enthusiast, Azure Solutions Architect
Service Fabric also does not suit well for small applications. Whether it is K8 or Service Fabric it is not for all. For example if we create an instance of Service Fabric in Azure, you can see the long list of resources which gets created and if not configured properly it adds to more hidden costs which will come as surprise while seeing the bills.
But most of these resources don't cost anything. You are paying for compute and disks on the VMs, those can cost as little as a web app. The resources are created explicitly so you can see what it consists of and customise to your needs if required, otherwise leave it alone ;)
We develop for Service Fabric with an 'on-premise' first mindset, since most of our customers still prefer that. Then when moving to the cloud, service configurations can drive substituting in cloud services (i.e analytics or data persistence) that make more sense for the cloud environment.
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 good to see a practical view about Kubernetes. Yes I agree to all your points. In my opinion Kubernetes is not for all applications.
If we want our applications to be running all the time, so that we don't lose revenue to our competitors then Kubernetes will help solve that problem. This purely works for e-commerce ordering systems.
If we want our applications to have the behavior of self healing, I think Kubernetes solves that problem.
With Azure Functions we can develop as many services and have them scale as required, but it comes with a cost. The consumption plan does not have control on the region where the function would be hosted. This would add some concerns to teams where there is strict requirement to maintain services with in their geographic region. But recently Azure Functions came up with Premium plan which is in preview mode and it might solve some geographic region requirements through VNET access. I am not sure about AWS Lambda.
You're 100% correct and pragmatic my friend. However, K8 still feels like a pain to me. Why not looking at "more mature" solutions, like Service Fabric?
Service Fabric also does not suit well for small applications. Whether it is K8 or Service Fabric it is not for all. For example if we create an instance of Service Fabric in Azure, you can see the long list of resources which gets created and if not configured properly it adds to more hidden costs which will come as surprise while seeing the bills.
But most of these resources don't cost anything. You are paying for compute and disks on the VMs, those can cost as little as a web app. The resources are created explicitly so you can see what it consists of and customise to your needs if required, otherwise leave it alone ;)
We develop for Service Fabric with an 'on-premise' first mindset, since most of our customers still prefer that. Then when moving to the cloud, service configurations can drive substituting in cloud services (i.e analytics or data persistence) that make more sense for the cloud environment.