5 ms·

> This is a not a likely speculation. Did reader really require anything special that doesn’t already exist as a Google Cloud API? Or majority of their killed p

• acituan 6y ago
  > The Google software stack is custom end-to-end, down to a customized Linux kernel and a customized C++ compiler. Are you really suggesting that the existence of an RSS aggregator hinges on custom linux kernels and C++ compilers? > all three still have an internal platform that is widely used. And your point is? None can afford running two divergent platforms simultaneously. > No, the "excess capacity" part is a myth. It's a pervasive myth, especially about AWS, but it's not actually true. Citation needed. (Also I didn’t say only excess capacity, also economies of scale.)
  • joshuamorton 6y ago
    Pick a piece of infrastructure: server (k8s), container (docker), RPC protocol (GRPC), user auth/ACLs, etc. and now understand that the internal version is different, and you need to replace it. At that point, you're rewriting the entire system, except for some of the business logic (and even a lot of the business logic will need to be rewritten). > And your point is? None can afford running two divergent platforms simultaneously. I think what they're saying is that all three do run divergent platforms simultaneously, today, right now. So clearly they can afford it.
    • acituan 6y ago
      > 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.
  • dodobirdlord 6y ago
    > None can afford running two divergent platforms simultaneously. Of course they can, all three actually do, right now, at this very moment!
    • deleted 6y ago
      [deleted]