281–290 of 319 posts
Earlier quoted context omitted.
I feel like I agree with this statement, but I can't think of any examples. Google Fiber doesn't seem to fit, or Reader, or Wave, which are the most commonly cited examples of popular products that got killed.
Google Reader?
Earlier quoted context omitted.
> 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…
> 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 p…
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.
Earlier quoted context omitted.
RFCs don't get changed, they get replaced by new ones. Until we find something that is 'good enough'. SMTP and IMAP are now older than quite a few of HN's readers. They could be replaced by something better, all someone would have to do is design it and put out a new RFC. What is true though is that once a protocol is 'good enough and it gains mass adoption that change is hard but this is more to be blamed on human n…
And this is happening. The JMAP working group at the IETF is writing new RFCs to replace SMTP/IMAP, Caldav, and others with a much cleaner protocol built on top of JSON and HTTP. Its already in use at Fastmail and a few other places. (The fastmail web client talks JMAP to get your emails from the fastmail servers.) Specs and more here: https://jmap.io/ Still no sign of adoption by gmail / etc but hopefully we'll see…
I just created a fastmail account and set it up on my devices. Now begins the long process of moving away from gmail.
Earlier quoted context omitted.
That's why we originally had an IETF and RFC's were publicly commented on and why standards are supposed to be company agnostic. The whole proprietary-APIs-over-HTTP was a giant step back. Before we did that interop between internet based applications was far more common and supported. Now every company treats 'their users' as their own private little walled garden when before 'your users' were not so much cows to mi…
Sure, it would be nice to go back to IETF and RFCs. But it seems like the discussion has wandered far afield from a Google breakup (more standard APIs/protocols may not result from a breakup and may not need a breakup). And what I hate about Google/Facebook breakup discussions is how they seem driven by a mob of all those having complaints against these tech giants, where the complaints contradict each other (too muc…
I don't see a complaint that Alphabet has too few services. The complaint seems to be that Alphabet is killing viable businesses or products because it can't spin them off profitably. Alphabet controls some amount of innovative economic capability that is creating products which Alphabet then wastes. Conversations about breaking up companies like this are about reallocating that economic capability to somewhere it can deliver value.
Earlier quoted context omitted.
> 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…
> 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…
> 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.
Earlier quoted context omitted.
> 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 myt…
> None can afford running two divergent platforms simultaneously. Of course they can, all three actually do, right now, at this very moment!
Earlier quoted context omitted.
> What will the price be? If you allow Google/Alphabet to practice price discrimination, it will charge customers in richer countries more. You and I would pay $5/month, much of India would pay $1/month, and people who can only afford $.1/month would pay that. If you insist that the price be uniform over all users, then it has to be $.1/month, or whatever the lowest common denominator is. Of course in that scenario i…
Another subthread here states that ads on search are a majority of Google's revenue. Looking at [1], we see the US being 46% of the revenue. So, assume that search in the US pays for 20% of Google's revenue. Apparently Google's revenue is $160B/year. Do you think the US would have 100M customers willing to pay $320/year for search? Or 10M willing to pay $3200? Or, any mixture of that to reach the balance? Dislaimer:…
Presumably, if Google is servicing paying customers instead of paying advertisers, then google has much less work to do. Their revenue can decrease without their profit decreasing.
They don't need to manage engineering to store cookies and track interests. They don't need infrastructure to store profiles. They don't need cpu cycles to correlate interests. They don't need lawyers to fight off regulators. You can easily imagine other things they would not need for those customers.
How much would paying customers need to pay so that google would make the same amount of money? Revenue isn't even an upper bound on that question.
"Dominance rule" is a common term in the science of combinatorial optimization. It felt a awkward when I first heard it, but the word fits pretty well to its meaning. I don't think it is a good idea to change such common terms because of such trends or even "Excel" (due to Excel's autocorrect, certain gene names are taboo and get renamed https://news.ycombinator.com/item?id=24070385 )
Earlier quoted context omitted.
> 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…
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 prohib…
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.