21 ms·

When you’ve got Kubernetes on top, it literally makes zero difference who the underlying cloud provider is. And thank god Kubernetes exists. Not about to waste

When you’ve got Kubernetes on top, it literally makes zero difference who the underlying cloud provider is. And thank god Kubernetes exists. Not about to waste my time relearning the API of every new cloud offering a company wants me to try.

paulddraper 8y ago
Sort of. It depends if you want to use Kubernetes to operate your own S3, your own RDS, your own SQS, your own Kinesis, your own Cloudfront, your own DynamoDB, etc. If you have the dev resources to do that, great. But lots of other players will prefer to use off-the-shelf stuff from cloud providers.
- partingshots 8y ago
  I think that’s a different question you’re answering though. For sure, continued automation is 100% the modus operandi. I wouldn’t be surprised if in the future IT departments don’t really exist anymore. But even with “off-the-shelf stuff”, your site reliability engineers would still be using Kubernetes as the primary language to communicate. Or I guess you could go all cutting edge and go one layer up with Istio instead. In that case then, Kubernetes is still there hiding underneath.
  - bilbo0s 8y ago
    Until Amazon, Microsoft, or Google move up the stack. (Or maybe all three. They really are eating the industry, but they add value so, yeah, I guess they deserve their rent. Just sucks for anyone else in that space.)
    - partingshots 8y ago
      Ever upwards abstraction my friend. Seriously, I thought Kubernetes would be it, but now all my coworkers are trying to get me to use Istio, which at first glance seems to be ... a managed containerization for different Kubernetes managed containers? Turtles all the way down I guess, which now I’ll have to spend all weekend on researching unfortunately.
    - ham_sandwich 8y ago
      I think it’s inevitable. Cloud providers will continue to move up the stack so other firms can focus more resources on their unique and differentiated offerings. It just seems like in the future most companies shouldn’t have any notion of servers/containers etc, they will only focus on their core business logic. We’ll just keep going upupupupup.
chrisseaton 8y ago
If I’m using a cloud provider product like text-to-speech then which part of Kubernetes abstracts those APIs so I can move from Polly to Bing with no work? I didn’t think Kubernetes covered things like that?
- spatley 8y ago
  In short, Kubernetes does not abstract any APIs. There are some ways to use things like Terraform to deploy and run in different cloud environments, but those API have different features that are inherrent and not transferrable.
  - scarface74 8y ago
    Terraform doesn’t abstract creating resources on different cloud providers. Each provisioner is tied to specific resources for the specific cloud provider.
scarface74 8y ago
Kubernetes doesn’t help with storage integration with S3, ETL processes involving Redshift, using queues and notifications setting up security, etc. Kubernetes is no more the be all end all of maintaining cloud agnosticism than using the repository pattern means that you can tell your CTO to get rid of your company’s multi million dollar Oracle installation.

paulddraper 8y ago

Sort of. It depends if you want to use Kubernetes to operate your own S3, your own RDS, your own SQS, your own Kinesis, your own Cloudfront, your own DynamoDB, etc. If you have the dev resources to do that, great. But lots of other players will prefer to use off-the-shelf stuff from cloud providers.

partingshots 8y ago
I think that’s a different question you’re answering though. For sure, continued automation is 100% the modus operandi. I wouldn’t be surprised if in the future IT departments don’t really exist anymore. But even with “off-the-shelf stuff”, your site reliability engineers would still be using Kubernetes as the primary language to communicate. Or I guess you could go all cutting edge and go one layer up with Istio instead. In that case then, Kubernetes is still there hiding underneath.
- bilbo0s 8y ago
  Until Amazon, Microsoft, or Google move up the stack. (Or maybe all three. They really are eating the industry, but they add value so, yeah, I guess they deserve their rent. Just sucks for anyone else in that space.)
  - partingshots 8y ago
    Ever upwards abstraction my friend. Seriously, I thought Kubernetes would be it, but now all my coworkers are trying to get me to use Istio, which at first glance seems to be ... a managed containerization for different Kubernetes managed containers? Turtles all the way down I guess, which now I’ll have to spend all weekend on researching unfortunately.
  - ham_sandwich 8y ago
    I think it’s inevitable. Cloud providers will continue to move up the stack so other firms can focus more resources on their unique and differentiated offerings. It just seems like in the future most companies shouldn’t have any notion of servers/containers etc, they will only focus on their core business logic. We’ll just keep going upupupupup.

chrisseaton 8y ago

If I’m using a cloud provider product like text-to-speech then which part of Kubernetes abstracts those APIs so I can move from Polly to Bing with no work? I didn’t think Kubernetes covered things like that?

spatley 8y ago
In short, Kubernetes does not abstract any APIs. There are some ways to use things like Terraform to deploy and run in different cloud environments, but those API have different features that are inherrent and not transferrable.
- scarface74 8y ago
  Terraform doesn’t abstract creating resources on different cloud providers. Each provisioner is tied to specific resources for the specific cloud provider.

scarface74 8y ago

Kubernetes doesn’t help with storage integration with S3, ETL processes involving Redshift, using queues and notifications setting up security, etc. Kubernetes is no more the be all end all of maintaining cloud agnosticism than using the repository pattern means that you can tell your CTO to get rid of your company’s multi million dollar Oracle installation.