Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
steve-yegge.medium.com
Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
1–10 of 126 posts
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#2So great to hear somebody like Yegge voice this.
I'm spending a lot of my weekend hours racing against the clock to keep some old app engine apps online. I wish I had started in 2020 :)
I've learnt my lesson and will be sticking with boring technology I can take anywhere in future. Node and Postgres for me from now on.
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#3Note: Post is from 2020
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#4So great to hear somebody like Yegge voice this. I'm spending a lot of my weekend hours racing against the clock to keep some old app engine apps online. I wish I had started in 2020 :) I've learnt my lesson and will be sticking with boring technology I can take anywhere in future. Node and Postgres for me from now on.
This is why, as a systems designer, I refuse to use "wrapper" services proved by cloud providers. If it doesn't have a shell where individual services can be run using my own choice of stack, I don't like it - for this exact reason.
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#5Just a rant about having to react to things that the author didn't want to react to. But these are facts of life. I find GCP policies pretty reasonable. I was never caught off guard by them.
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#6So great to hear somebody like Yegge voice this. I'm spending a lot of my weekend hours racing against the clock to keep some old app engine apps online. I wish I had started in 2020 :) I've learnt my lesson and will be sticking with boring technology I can take anywhere in future. Node and Postgres for me from now on.
This is why, as a systems designer, I refuse to use "wrapper" services proved by cloud providers. If it doesn't have a shell where individual services can be run using my own choice of stack, I don't like it - for this exact reason.
how do y'all look at systems like AWS Aurora, GCP Spanner, etc which offer big speedups and cost savings, but lock you into the platform in practice?
this isn't academic for me - I've got a service that's on vanilla RDS PostgreSQL but growing fast, and I'll soon need to decide whether to move to something cheaper/faster but proprietary or blow my budget trying to stay generic...
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#7Earlier quoted context omitted.
This is why, as a systems designer, I refuse to use "wrapper" services proved by cloud providers. If it doesn't have a shell where individual services can be run using my own choice of stack, I don't like it - for this exact reason.
how do y'all look at systems like AWS Aurora, GCP Spanner, etc which offer big speedups and cost savings, but lock you into the platform in practice? this isn't academic for me - I've got a service that's on vanilla RDS PostgreSQL but growing fast, and I'll soon need to decide whether to move to something cheaper/faster but proprietary or blow my budget trying to stay generic...
Drive-by response:
I’d ask two questions — how possible is it to isolate the code which is proprietary? …is there a third option which allows not blowing your budget, but remaining generic?
Naively, isolating the proprietary interface in a wrapper in your code minimizes changes should you need to move — and blowing your budget isn’t a long term solution.
So does it come down to the proprietary option or fail?
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#8Earlier quoted context omitted.
This is why, as a systems designer, I refuse to use "wrapper" services proved by cloud providers. If it doesn't have a shell where individual services can be run using my own choice of stack, I don't like it - for this exact reason.
how do y'all look at systems like AWS Aurora, GCP Spanner, etc which offer big speedups and cost savings, but lock you into the platform in practice? this isn't academic for me - I've got a service that's on vanilla RDS PostgreSQL but growing fast, and I'll soon need to decide whether to move to something cheaper/faster but proprietary or blow my budget trying to stay generic...
Please tell how Aurora - which is just MySql and Postgres with a better underlying storage engine - “locks you in”?
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#9Earlier quoted context omitted.
This is why, as a systems designer, I refuse to use "wrapper" services proved by cloud providers. If it doesn't have a shell where individual services can be run using my own choice of stack, I don't like it - for this exact reason.
how do y'all look at systems like AWS Aurora, GCP Spanner, etc which offer big speedups and cost savings, but lock you into the platform in practice? this isn't academic for me - I've got a service that's on vanilla RDS PostgreSQL but growing fast, and I'll soon need to decide whether to move to something cheaper/faster but proprietary or blow my budget trying to stay generic...
You just have to realise that given enough scale everything turns proprietary anyway.
The difference being whether you are internally maintaining your special snowflake, or else paying for a solution maintained for you by a 3rd party.
Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)
#10This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version.
IMHO, the only thing cloud providers are genuinely useful for is a bottomless data storage. But even that aspect is now isolated by Rclone in all my apps since migrating off the cloud. Apps just talk with the file system, which is then abstracted to a cloud storage of choice by Rclone.