2 ms·

I mostly agree with you, but I'd point out that I think we apply different standards to cloud products than we do desktop products. Cloud lock-in is huge, and

I mostly agree with you, but I'd point out that I think we apply different standards to cloud products than we do desktop products. Cloud lock-in is huge, and we're very OK with it--I think as engineers we respect the complexity of tackling it. Desktop lock-in super irritates us, but it's not really different. Lock-in exists both on the desktop and in the cloud (and all kinds of other places in tech) because that's what the business incentives are. It's a race to the bottom and no company can resist it and still have shareholders. We need regulation to make them knock it off.

kodah 5y ago
Regulation may help, but companies can blame themselves for cloud lock-in, not shareholders, engineers, or complexity. Prior to being a SWE or SRE-SE I worked in Network Engineering. Seeing how most companies ran their DCs and treated the devs that were required to use them was illuminating. Everything was a "service desk" staffed with generally ticket handlers. It took ages for them to get things done, and you were almost always hunting for the person on the desk that just "got things done". I worked nights and my engineering line would get clear day-time-appropriate requests at nights because the most qualified engineers were in school and ended up on the night shift. Compute scheduling was no different. You now have APIs for both of these jobs. My point being that the real innovation that made developers turn to the cloud was APIs. All these "availability zones" didn't exist in most company DCs, usually someone had a lever to throw to switch DCs at best, and even then they really weren't used. Downtime was expected. Those very same APIs could've been made by a coalition of those small and medium companies using the same technique Google used with Kubernetes: open source. By the time such a project started, it was already too late, and public clouds had built what they'd built. Not having open hardware also contributed to the problem, but again, nothing a coalition couldn't overcome.

kodah 5y ago

Regulation may help, but companies can blame themselves for cloud lock-in, not shareholders, engineers, or complexity. Prior to being a SWE or SRE-SE I worked in Network Engineering. Seeing how most companies ran their DCs and treated the devs that were required to use them was illuminating. Everything was a "service desk" staffed with generally ticket handlers. It took ages for them to get things done, and you were almost always hunting for the person on the desk that just "got things done". I worked nights and my engineering line would get clear day-time-appropriate requests at nights because the most qualified engineers were in school and ended up on the night shift. Compute scheduling was no different. You now have APIs for both of these jobs. My point being that the real innovation that made developers turn to the cloud was APIs. All these "availability zones" didn't exist in most company DCs, usually someone had a lever to throw to switch DCs at best, and even then they really weren't used. Downtime was expected. Those very same APIs could've been made by a coalition of those small and medium companies using the same technique Google used with Kubernetes: open source. By the time such a project started, it was already too late, and public clouds had built what they'd built. Not having open hardware also contributed to the problem, but again, nothing a coalition couldn't overcome.