3 ms·

> You mention this in the passing, but barring mechanical limitations of the new infra, reusing your business logic means retaining your APIs, auth models, data

> You mention this in the passing, but barring mechanical limitations of the new infra, reusing your business logic means retaining your APIs, auth models, data models, even database schemas, replication and deployment design decisions and tons of portable code. That is where the overwhelming majority of engineer hours go in an ordinary product anyway. If you haven't read the Google SRE Handbook, I recommend it. It presents some good background on the topics here. Pretty much every aspect you listed is dependent on a custom Google-internal service, and would have to be rewritten. https://landing.google.com/sre/sre-book/chapters/production-environment/ https://landing.google.com/sre/sre-book/chapters/production-... https://landing.google.com/sre/sre-book/chapters/release-engineering/ https://landing.google.com/sre/sre-book/chapters/release-eng... > No, they don't. They do. No need to come up with a rationalization for why it can't be the case, you can Google it and find out that it is true.

acituan 6y ago
> Pretty much every aspect you listed is dependent on a custom Google-internal service, and would have to be rewritten. Except those as OP states have both open source versions and SaaS versions available and they don't need to be written from scratch. SRE automation software and being able to run a particular application are completely different things. I don't get why there has been a constant confusion between application logic and infrastructure in this thread. You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc.
- joshuamorton 6y ago
  Yes, but you can't run Google's RSS aggregator without depending on Google's particular monitoring or cluster management infrastructure. And migrating away from all of those hundreds of dependencies, many fo which are in extremely central parts of your stack, is a huge amount of effort. See this[0] for an example of the interfaces the infra supports, and now you have to rip basically all of that away and replace it with something different. And that's in addition to all of the application level changes, and that's in addition to any high level design changes due to potential mismatches in capabilities between the internal and external systems. [0]: https://twitter.com/rakyll/status/1293026308524584960 https://twitter.com/rakyll/status/1293026308524584960

acituan 6y ago

> Pretty much every aspect you listed is dependent on a custom Google-internal service, and would have to be rewritten. Except those as OP states have both open source versions and SaaS versions available and they don't need to be written from scratch. SRE automation software and being able to run a particular application are completely different things. I don't get why there has been a constant confusion between application logic and infrastructure in this thread. You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc.

joshuamorton 6y ago
Yes, but you can't run Google's RSS aggregator without depending on Google's particular monitoring or cluster management infrastructure. And migrating away from all of those hundreds of dependencies, many fo which are in extremely central parts of your stack, is a huge amount of effort. See this[0] for an example of the interfaces the infra supports, and now you have to rip basically all of that away and replace it with something different. And that's in addition to all of the application level changes, and that's in addition to any high level design changes due to potential mismatches in capabilities between the internal and external systems. [0]: https://twitter.com/rakyll/status/1293026308524584960 https://twitter.com/rakyll/status/1293026308524584960