3 ms·

Yeah I was there. It was great because it was, apparently, impossibly cheap. Then they decided to take it out of beta and jack the prices. People who were spend

Yeah I was there. It was great because it was, apparently, impossibly cheap. Then they decided to take it out of beta and jack the prices. People who were spending $10/mo suddenly had $1000/mo bill. Never trust google.

klabb3 4y ago
Yeah I don't think PaaS should ever be proprietary in terms of API surface. It's just perverse incentives, you get subsidized until market saturation, and then they jack up the prices. The cloud providers should, imo, compete on uptime, resilience, performance, etc. Kinda like the VPS or VPN providers of today.
- asciimike 4y ago
  Let's take a quick example of S3: GCS was able to take the same API and they both compete on uptime, performance, etc. Price/GB has remained stable or decreased with new tiering options over time. Managed K8s clusters, SQL databases, etc. are all competing in similar ways. If folks want to build proprietary APIs, and people choose to use them because they are faster/better/cheaper/more suited to a particular use case, I'm not sure why that's a bad thing. Engineering is tradeoffs, proprietary API surface is one of many things people consider.
  - klabb3 4y ago
    True, I didn't mean to come off as a purist. I think it depends on the service provided and it's maturity level. If you need basics like auth, persistence etc i think those parts should be open, at the very least have a stable API that has >1 provider. (The SRE analogy would be a SPOF). For things like push- and email notifications, it makes more sense that a provider is involved (although APIs should probably still be open). New innovations can always start out proprietary, and the inventors can always offer support and managed infra for OSS projects. Why? I believe the health and future innovations within the tech sector relies on healthy competition, and imo, that means that the majority of standard services have multiple providers to choose from. The only way to migrate from one provider to another is through standardized, or open, APIs. VPCs is a pretty good example of this: I can get the premium option from GCP or AWS, and have uptime, bandwidth, and choose a DC from all over the world. OTOH, I can get a cheaper, local one, depending on my needs.
  - thayne 4y ago
    Let's continue that s3 example. There are many products branded as "s3 compatible", but they all have slightly different definitions of what that compatibility means. Not to mention that the s3 api itself is a moving target, and doesn't even have a version number you can reference, so the best you can do is list which features you do or don't support. Some of these products actually have native APIs which IMO are better than S3, partly because they can learn from mistakes in s3s API.

klabb3 4y ago

Yeah I don't think PaaS should ever be proprietary in terms of API surface. It's just perverse incentives, you get subsidized until market saturation, and then they jack up the prices. The cloud providers should, imo, compete on uptime, resilience, performance, etc. Kinda like the VPS or VPN providers of today.

asciimike 4y ago
Let's take a quick example of S3: GCS was able to take the same API and they both compete on uptime, performance, etc. Price/GB has remained stable or decreased with new tiering options over time. Managed K8s clusters, SQL databases, etc. are all competing in similar ways. If folks want to build proprietary APIs, and people choose to use them because they are faster/better/cheaper/more suited to a particular use case, I'm not sure why that's a bad thing. Engineering is tradeoffs, proprietary API surface is one of many things people consider.
- klabb3 4y ago
  True, I didn't mean to come off as a purist. I think it depends on the service provided and it's maturity level. If you need basics like auth, persistence etc i think those parts should be open, at the very least have a stable API that has >1 provider. (The SRE analogy would be a SPOF). For things like push- and email notifications, it makes more sense that a provider is involved (although APIs should probably still be open). New innovations can always start out proprietary, and the inventors can always offer support and managed infra for OSS projects. Why? I believe the health and future innovations within the tech sector relies on healthy competition, and imo, that means that the majority of standard services have multiple providers to choose from. The only way to migrate from one provider to another is through standardized, or open, APIs. VPCs is a pretty good example of this: I can get the premium option from GCP or AWS, and have uptime, bandwidth, and choose a DC from all over the world. OTOH, I can get a cheaper, local one, depending on my needs.
- thayne 4y ago
  Let's continue that s3 example. There are many products branded as "s3 compatible", but they all have slightly different definitions of what that compatibility means. Not to mention that the s3 api itself is a moving target, and doesn't even have a version number you can reference, so the best you can do is list which features you do or don't support. Some of these products actually have native APIs which IMO are better than S3, partly because they can learn from mistakes in s3s API.