3 ms·

>If you're just selling CPU cycles That's not the end game. It's to develop services (apis) and sell access to them on a per use basis. Then youre wiring log

by basch 8y ago

>If you're just selling CPU cycles That's not the end game. It's to develop services (apis) and sell access to them on a per use basis. Then youre wiring logic between the services. Neither Azure nor AWS nor Google want your code and containers to be portable between infrastructures. They want to offer the hard compute functions to you in rental form.

bryanlarsen 8y ago
Google does want your code and containers to be portable between infrastructures. Kubernetes is very strong evidence of this intent. They appear to have decided that being the obvious place for Kubernetes hosting is worth more to them than competing against AWS & Azure in a world without Kubernetes.
noir_lord 8y ago
Until there is a genuinely portable way to move from one to another I'll stick either bare metal or running my own KVM instances on bare metal. From a business risk point of view I don't trust the cloud at all and don't feel comfortable suggesting it to my boss. Long term kubernetes or its three successors might fit the bill but for now running my own stuff has worked out fine.
- existencebox 8y ago
  I've taken the middle path: Typically I find I can build my apps using standard OSS tooling and just keep it CI'd into a self-contained container or packaged deployment. If I need to roll it out to GCE? Sure. AWS? Sure. Azure? Sure. All 3 at once? no problem. The need to shim common things like "make image, deploy VM, set up VNET" is a pain and does marginally limit portability, but perhaps by nature of my only needing a small set of their IaaS style offerings (compute, networking, MAYBE blob storage/cache if I'm feeling fancy) I've found it rather straightforward to maintain portability through very minimal abstraction. (Disclaimer since I'm talking about cloud stuff, MSFtie, opinions are my own etc)
  - noir_lord 8y ago
    Pretty much the same for us, the heavy lifting is done on in house servers but some of our external services are running on linode. In either case everything is done via ansible/repeatable deploys (and some python and bash scripts). Even our development instances are done using basically the same ansible setup as production (it catches more than I'd expect in terms of "that would have hurt in production"). For now it's a practical solution that leverages the skills I have and our projected scalability needs from year to year are low enough that I don't worry about it.
    - existencebox 8y ago
      "Even our development instances are done using basically the same ansible setup as production (it catches more than I'd expect in terms of "that would have hurt in production")." At the risk of a glib comment, the essence of your statement would be VERY high up on my "biggest lessons I've learned over the last decade" list, if such a thing existed. The benefits of having your develop look as close as naturally possible to your production (and then abusing it in every way imaginable as one tends to during dev) has caught so much on my end.

by basch 8y ago

bryanlarsen 8y ago

Google does want your code and containers to be portable between infrastructures. Kubernetes is very strong evidence of this intent. They appear to have decided that being the obvious place for Kubernetes hosting is worth more to them than competing against AWS & Azure in a world without Kubernetes.

noir_lord 8y ago

Until there is a genuinely portable way to move from one to another I'll stick either bare metal or running my own KVM instances on bare metal. From a business risk point of view I don't trust the cloud at all and don't feel comfortable suggesting it to my boss. Long term kubernetes or its three successors might fit the bill but for now running my own stuff has worked out fine.

existencebox 8y ago
I've taken the middle path: Typically I find I can build my apps using standard OSS tooling and just keep it CI'd into a self-contained container or packaged deployment. If I need to roll it out to GCE? Sure. AWS? Sure. Azure? Sure. All 3 at once? no problem. The need to shim common things like "make image, deploy VM, set up VNET" is a pain and does marginally limit portability, but perhaps by nature of my only needing a small set of their IaaS style offerings (compute, networking, MAYBE blob storage/cache if I'm feeling fancy) I've found it rather straightforward to maintain portability through very minimal abstraction. (Disclaimer since I'm talking about cloud stuff, MSFtie, opinions are my own etc)
- noir_lord 8y ago
  Pretty much the same for us, the heavy lifting is done on in house servers but some of our external services are running on linode. In either case everything is done via ansible/repeatable deploys (and some python and bash scripts). Even our development instances are done using basically the same ansible setup as production (it catches more than I'd expect in terms of "that would have hurt in production"). For now it's a practical solution that leverages the skills I have and our projected scalability needs from year to year are low enough that I don't worry about it.
  - existencebox 8y ago
    "Even our development instances are done using basically the same ansible setup as production (it catches more than I'd expect in terms of "that would have hurt in production")." At the risk of a glib comment, the essence of your statement would be VERY high up on my "biggest lessons I've learned over the last decade" list, if such a thing existed. The benefits of having your develop look as close as naturally possible to your production (and then abusing it in every way imaginable as one tends to during dev) has caught so much on my end.