You write that there is no K8s cloud portability if:
"Your application doesn't store any data" - This is not correct. It is no problem moving a service which stores data between cloud vendors (= uses physical volumes).
It doesn't do anything with a network, at least it doesn't accept any incoming traffic - This is not correct. All K8s clould vendors allow you to use K8s ingresses (there are also other options).
It doesn't require any monitoring - This is not correct. All K8s cloud providers support liveness/readiness probes (it's a part of the standard). All cloud providers allow you to install Promethes + AlertManager for monitoring. And I'd guess that all cloud provider give you integration with their monitoring system "out of the box" (at least the provider we use, but I'd be extremely surprised if that isn't the case also with other providers)
It doesn't use any other PaaS services - That's actually a point. Using Paas services sometimes means vendor lock in.
Fully stateless, has no interaction with anything outside of itself - This is not correct. As stated above those service can store state in physical volumes and/or they can store state in external data stores - like an external database. And I see no problems in a K8s service using an external database as a service. That's simply a good design and it's portable between cloud vendors.
I've probably misunderstood your arguments completely, but one of the things I like with K8s is that you can move (close to) exactly the same deployment between on-prem and different cloud providers.
I do agree that K8s isn't even close to solving all problems, but it's a really nice platform for it's use cases - and they are many. I don't doubt that Service Fabric also is a good platform for it's use cases - and possibly a more mature platform. But currently it is extremely limited in that it is:
(for all practical purposes) completely in the hands of Microsoft.
an uninteresting platform for the most of the opensource community
And yes.. I think one should utilize functions as a service, database as a service, containers as a service, etc. But this does not rule out also running cloud portable applications in a K8s cluster.
Btw: On of our use cases is running small Redis clusters in K8s. For our needs this is a lot cheaper than buying Redis as a service.
"(for all practical purposes) completely in the hands of Microsoft.
an uninteresting platform for the most of the opensource community"
These are legitimate concerns for many people, however for many paying customers they are irrelevant. We must be sure to separate our personal views from what is in the best interests of our clients. There is absolutely nothing wrong with being a 100% "Microsoft shop" in 2019, just as there is nothing wrong with being an AWS or IBM shop. In the real enterprise world moving between major clouds is extremely rare.
This was not meant as an argument against being a 100% Microsoft, AWS or whatever shop. The problem when Azure Service Fabric is an "uninteresting platform for most of the opensource community" is lack of access to competent resources, lack of solutions built to run on Azure Service Fabric and lack of a vibrant community around the platform. And this is relevant for paying customers, even though your personal views might favor a particular technology.
I'm pretty sure Azure Service Fabric is a good platform which Microsoft will develop further. I'm also pretty sure Azure Service Fabric might be the way to go for many solutions, but......
Microsoft just announced Microsoft Arc (ref forbes.com/sites/janakirammsv/2019...), and here even Microsoft uses Kubernetes in ways that would have been impossible, or at least extremely unwise, if the picture this article tries to paint of Kubernetes is correct.
Or to cite from the article: "Microsoft is also one of the first to bring managed data services to the hybrid cloud. Since these database services are packaged as containers and run on top of Kubernetes, managing them from the centralized Azure control plane becomes efficient."
So Microsoft has decided to deploy these databases on top of Kubernetes and not on top of Azure Service Fabric (directly).
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.
You write that there is no K8s cloud portability if:
"Your application doesn't store any data" - This is not correct. It is no problem moving a service which stores data between cloud vendors (= uses physical volumes).
It doesn't do anything with a network, at least it doesn't accept any incoming traffic - This is not correct. All K8s clould vendors allow you to use K8s ingresses (there are also other options).
It doesn't require any monitoring - This is not correct. All K8s cloud providers support liveness/readiness probes (it's a part of the standard). All cloud providers allow you to install Promethes + AlertManager for monitoring. And I'd guess that all cloud provider give you integration with their monitoring system "out of the box" (at least the provider we use, but I'd be extremely surprised if that isn't the case also with other providers)
It doesn't use any other PaaS services - That's actually a point. Using Paas services sometimes means vendor lock in.
Fully stateless, has no interaction with anything outside of itself - This is not correct. As stated above those service can store state in physical volumes and/or they can store state in external data stores - like an external database. And I see no problems in a K8s service using an external database as a service. That's simply a good design and it's portable between cloud vendors.
I've probably misunderstood your arguments completely, but one of the things I like with K8s is that you can move (close to) exactly the same deployment between on-prem and different cloud providers.
I do agree that K8s isn't even close to solving all problems, but it's a really nice platform for it's use cases - and they are many. I don't doubt that Service Fabric also is a good platform for it's use cases - and possibly a more mature platform. But currently it is extremely limited in that it is:
And yes.. I think one should utilize functions as a service, database as a service, containers as a service, etc. But this does not rule out also running cloud portable applications in a K8s cluster.
Btw: On of our use cases is running small Redis clusters in K8s. For our needs this is a lot cheaper than buying Redis as a service.
"(for all practical purposes) completely in the hands of Microsoft.
an uninteresting platform for the most of the opensource community"
These are legitimate concerns for many people, however for many paying customers they are irrelevant. We must be sure to separate our personal views from what is in the best interests of our clients. There is absolutely nothing wrong with being a 100% "Microsoft shop" in 2019, just as there is nothing wrong with being an AWS or IBM shop. In the real enterprise world moving between major clouds is extremely rare.
This was not meant as an argument against being a 100% Microsoft, AWS or whatever shop. The problem when Azure Service Fabric is an "uninteresting platform for most of the opensource community" is lack of access to competent resources, lack of solutions built to run on Azure Service Fabric and lack of a vibrant community around the platform. And this is relevant for paying customers, even though your personal views might favor a particular technology.
I'm pretty sure Azure Service Fabric is a good platform which Microsoft will develop further. I'm also pretty sure Azure Service Fabric might be the way to go for many solutions, but......
Microsoft just announced Microsoft Arc (ref forbes.com/sites/janakirammsv/2019...), and here even Microsoft uses Kubernetes in ways that would have been impossible, or at least extremely unwise, if the picture this article tries to paint of Kubernetes is correct.
Or to cite from the article: "Microsoft is also one of the first to bring managed data services to the hybrid cloud. Since these database services are packaged as containers and run on top of Kubernetes, managing them from the centralized Azure control plane becomes efficient."
So Microsoft has decided to deploy these databases on top of Kubernetes and not on top of Azure Service Fabric (directly).