4 ms·

> I have been inexorably pushed away from GCP, towards cloud agnosticism. On a side note I think this is what all of us should be aiming for. Every time someon

> I have been inexorably pushed away from GCP, towards cloud agnosticism. On a side note I think this is what all of us should be aiming for. Every time someone on a team I'm working for starts trying to use some very complex tool that a SaaS/cloud has built for us I always urged them to look for a simpler solution. Do you really need AWS Lambda/kinesis/etc or can you write your code and deploy it onto our cluster as a normal service/api/control loop? If you make it really easy to write code, deploy it, and monitor it, you'll often find it's way less devops time to write your software as apis/control loops than it is to use a large amalgamation of cloud services. I also haven't found a good way to unit test cloud services and their interlinking.

Illniyar 6y ago
On the contrary, every time someone comes to me with a suggestion to build something in-house or use an open source solution when a aws service exists I say the hell with that. I don't want to maintain it, build features into it or operate it. I want full in vendor lock-in, it saves an immense amount of time. You just need to pick a vendor that gives a shit about it's customers to be locked in to - and that's simply not google.
RonanTheGrey 6y ago
It's tough to avoid the time savings that vendor lock-in buys you these days. I have had to grudgingly accept that, despite the fact that I absolutely hate giving in to it. Look at what Apple has done with lock-in (or Google for that matter in other areas of the ecosystem) and you can see the reasons why. However you can take steps that even when you give in to lock in, you structure your code/projects so that switching to another standard is straightforward: include non-vendor build scripts that would work on any Docker/VPS/baremetal server, isolate the locked-in config and scripts from the rest of the app as much as possible (even if it means running separate external scripts to execute them), etc. Once you've done it a couple times you build up a suite of small tools and it gets easier. I got bit hard by Zeit/Vercel, and then by GCP, and then by AWS. All of them do one thing or another to manage to find a way to extract more money. My goal is to make it so that if one day I decide we simply need to leave the platform, we can at a minimum of effort. Because this actually does happen 1-2 times a year, thanks to exactly the issues raised by OP, it's paid dividends to put in the small time it takes to keep things mostly agnostic on the code side.

Illniyar 6y ago

On the contrary, every time someone comes to me with a suggestion to build something in-house or use an open source solution when a aws service exists I say the hell with that. I don't want to maintain it, build features into it or operate it. I want full in vendor lock-in, it saves an immense amount of time. You just need to pick a vendor that gives a shit about it's customers to be locked in to - and that's simply not google.

RonanTheGrey 6y ago

It's tough to avoid the time savings that vendor lock-in buys you these days. I have had to grudgingly accept that, despite the fact that I absolutely hate giving in to it. Look at what Apple has done with lock-in (or Google for that matter in other areas of the ecosystem) and you can see the reasons why. However you can take steps that even when you give in to lock in, you structure your code/projects so that switching to another standard is straightforward: include non-vendor build scripts that would work on any Docker/VPS/baremetal server, isolate the locked-in config and scripts from the rest of the app as much as possible (even if it means running separate external scripts to execute them), etc. Once you've done it a couple times you build up a suite of small tools and it gets easier. I got bit hard by Zeit/Vercel, and then by GCP, and then by AWS. All of them do one thing or another to manage to find a way to extract more money. My goal is to make it so that if one day I decide we simply need to leave the platform, we can at a minimum of effort. Because this actually does happen 1-2 times a year, thanks to exactly the issues raised by OP, it's paid dividends to put in the small time it takes to keep things mostly agnostic on the code side.