4 ms·

> server (k8s), container (docker), RPC protocol (GRPC), user auth/ACLs, etc. ... At that point, you're rewriting the entire system You are not writing any of

> server (k8s), container (docker), RPC protocol (GRPC), user auth/ACLs, etc. ... At that point, you're rewriting the entire system You are not writing any of those systems, you're merely writing the glue code between your application and those systems, none of which is application specific. I explicitly made the point that cross-infra porting is not necessarily trivial, but it is also not cost prohibitive as the OP makes, and certainly there is no secret sauce involved to the extent of justifying a break-up. > except for some of the business logic 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. > three do run divergent platforms simultaneously, today, right now No, they don't. Trying to spin up your custom internal infra (or demanding special internal accommodation from externally available infra) will require justifying to management why you're not using the existing one, and most of the new products coming from these guys are nothing that specialized in terms of infra needs. I'm not saying there is a perfect external/internal service&API parity, but certainly convergence is the normativity here, not divergence. Let me put it this way, majority of {Google, Amazon, Microsoft} services could be ported to run on each others cloud platforms, let alone on the external APIs of their own platforms, which means there is no secret sauce and there is no reason for smaller players to be complaining about it other than not having economies of scale thus pricing levels.

joshuamorton 6y ago
> you're merely writing the glue code between your application and those systems, none of which is application specific. Yes, but if you have to modify every interaction with an external API (you do), or even many interactions between internal APIs (you also do), you have to rewrite the application. Most of an application is moving data, if you have to change how you move data, you have to change the majority of the app. > No, they don't. Trying to spin up your custom internal infra (or demanding special internal accommodation from externally available infra) will require justifying to management why you're not using the existing one, and most of the new products coming from these guys are nothing that specialized in terms of infra needs. Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. > Let me put it this way, majority of {Google, Amazon, Microsoft} services could be ported to run on each others cloud platforms, let alone on the external APIs of their own platforms, which means there is no secret sauce and there is no reason for smaller players to be complaining about it other than not having economies of scale thus pricing levels. This is also wrong (i mean for some value of ported including "completely and entirely rearchitect", yes this is trivially true). But no, hosting AWS on GCP or Google search on AWS would not be, by any stretch of the imagination, a relatively simple process. There are well known examples of systems that one service has, that another can't support. A simple example would be Spanner. But that's a different conversation than the one we were having. The original claim was > Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, etc. Which is true. You seem to be taking "can't" to mean "cannot technically, even given infinite resources" and not the much more likely "cannot reasonably". And this would be true in general, ask anyone who has tried to move an app GCE to AWS, and see if it was pleasant. It's not.
- acituan 6y ago
  We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is not the point of this exercise. The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. (In fact the inverse case happens pretty frequently, whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending). No need to make it more complicated than that. > Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. They are all entitled to their own opinion. I'm open to being proven wrong, but I'm sure you can guess how different opinions can be even in 'those companies' so let's not assume there is a clear, unquestionable truth they have access to. It is hard to attest anyone's credentials on a pseudonymous forum and that is OK.
  - joshuamorton 6y ago
    > The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. > I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. Yes, you claim this, and you were and continue to be incorrect. > whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget. But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions. > They are entitled to their own opinion. But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. To address your other comment: > You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc. Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.
dodobirdlord 6y ago
> 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

joshuamorton 6y ago

> you're merely writing the glue code between your application and those systems, none of which is application specific. Yes, but if you have to modify every interaction with an external API (you do), or even many interactions between internal APIs (you also do), you have to rewrite the application. Most of an application is moving data, if you have to change how you move data, you have to change the majority of the app. > No, they don't. Trying to spin up your custom internal infra (or demanding special internal accommodation from externally available infra) will require justifying to management why you're not using the existing one, and most of the new products coming from these guys are nothing that specialized in terms of infra needs. Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. > Let me put it this way, majority of {Google, Amazon, Microsoft} services could be ported to run on each others cloud platforms, let alone on the external APIs of their own platforms, which means there is no secret sauce and there is no reason for smaller players to be complaining about it other than not having economies of scale thus pricing levels. This is also wrong (i mean for some value of ported including "completely and entirely rearchitect", yes this is trivially true). But no, hosting AWS on GCP or Google search on AWS would not be, by any stretch of the imagination, a relatively simple process. There are well known examples of systems that one service has, that another can't support. A simple example would be Spanner. But that's a different conversation than the one we were having. The original claim was > Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, etc. Which is true. You seem to be taking "can't" to mean "cannot technically, even given infinite resources" and not the much more likely "cannot reasonably". And this would be true in general, ask anyone who has tried to move an app GCE to AWS, and see if it was pleasant. It's not.

acituan 6y ago
We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is not the point of this exercise. The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. (In fact the inverse case happens pretty frequently, whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending). No need to make it more complicated than that. > Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. They are all entitled to their own opinion. I'm open to being proven wrong, but I'm sure you can guess how different opinions can be even in 'those companies' so let's not assume there is a clear, unquestionable truth they have access to. It is hard to attest anyone's credentials on a pseudonymous forum and that is OK.
- joshuamorton 6y ago
  > The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. > I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. Yes, you claim this, and you were and continue to be incorrect. > whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget. But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions. > They are entitled to their own opinion. But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. To address your other comment: > You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc. Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.

dodobirdlord 6y ago

> 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