Hyper scalers have a decent margin from a small number of their services and a much more normal if not a loss from many others. Additionally a massive part of their profit is support services and contracts.
They also benefit from the fact that developers do what is convenient for themselves and not what is necessarily computationally efficient (i.e. not pay attention to cross AZ egress/ingress, run an apache spark job when it could be done all within a normal database, build their entire product on irreplaceable/unswappable cloud provider specific databases and storage solutions).
AI will also experience a significant margin collapse, it's just not clear who will eat the brunt of it yet, the AI companies themselves or companies like Nvidia as more chip manufacturers/designers come into the arena and can meaningfully compete.
Regardless of anything else, absolutely no one is calling shin bet the best in the world at what they do. The FBI is much more effective. It's the israeli agencies that focus on transnational threats human and signals intellegence (mossad and 8200 respectively, along with other groups in the laters perview under military intellegence).
If you really think this you simply have no theory of mind for this stuff. There are tons of immensely successful products in the ad space that both of those companies have launched. They don't need to innovate in the product or technology space (doing so certainly makes a big difference in having more placement for ad real estate), but to suggest there have been no real innovations (specifically engineering specific innovations) related to ad tech would be completely ridiculous to suggest. You don't need to change the world to get rich, just look at wall street where major innovations have been made in the pricing models of fixed income securities.
Second to this are countless other areas that have a major impact on the companies bottom line that are entirely engineering driven, especially at google given they are a cloud provider and have meaningfully grown the workspace business and launched waymo in this time.
I'm talking specifically their AWS service for ROS applications, all of my concerns are AWS specific for that matter, not the robotics they build in house.
I'm also an AWS alumni from many years back now, and truthfully, the organizational problems really took off when Jassy moved to being CEO of amazon as a whole and major leaders left the company (Charlie Bell, et al.).
There were always other problems too, pressure on the company in both directions across many different product lines on both cost (any number of cheaper baremetal providers who are much faster at providing customers instances than they were a decade ago), and product quality (any number of startups to now bigger companies, databricks probably being the biggest success) along with a number of expensive bets that were made that didn't work out especially as interest rates began to rise (there were numbers of of different services ranging from IoT, AI, business support, robotics, groundstation, that essentially all failed).
AI infra being their latest bet, along with doubling down on custom hardware is smart, but these roles don't require the same number of SWEs and instead require a different type of high skilled professional.
I think back to my past jobs how there were people who'd work weekends on random (not to technically difficult to implement) efforts that probably got them promoted, but we would never make time for during the regular work week that now would take next to no time to implement with AI.
Anyone with any small amount of creativity for this sort of thing could really make a big difference on improving the productivity of all sorts of team wide investigations as a running background task they have during their regular work.
Except here's the thing, that's the sort of code that was extremely expensive before, in large part because of our day jobs (which still to this day require mindfulness and can't just be vibe-coded).
However, an extra script here or there to make your life easier, adding extra UI features based on some datapoint to your internal dashboard, ect, these were things that could've taken a few days you didn't have before to get exactly right and now they can be done with only a few minutes of attention.
This is in many ways a smart way to understand the problem, but it doesn't mean that microsoft contracts mean you're stuck with bad software. There are several verticals where Microsoft and Azure actually were smart and chose a better software product to sell on their platform than what they had in house.
One example is when they stopped trying to develop a inferior product to EMR and Dataproc, and essentially just outsourced the whole effort to a deal made between them and Databricks. Because of this I assume many enterprise azure customers have better running data solutions in that space than they wouldve had they gone with just AWS or GCP.
On the other hand, having worked for Microsoft on an Azure team, there are plenty of areas that critically need a rewrite (for dozens of different reasons), and such a solution is never found (or they just release some different product and tell those with different needs to migrate to that), where they keep on building what can only really be described as hot-fixes to meet urgent customer demands that make it harder to eventually do said critical rewrite.
If there's a single section of the entire world where daylight savings makes the most, it's above and below the 45th parallel. This means the earliest sunrise is 9am in the winter what a horrible idea just to give people a little bit more sunlight when they'd still be out at work anyways.
I mean, it's objectively true that they can do this, especially when even mildly filtered down by incoming external data.
It's why you no longer need to speak with a person when reentering your home country in a lot of different places (israel being one of them, but also the EU, trusted travelers in the US through global entry, ect).
There's no need to counter it, the whole point is to hit the social aspect of being on these platforms. If even half the kids can't figure out how to make it work, then a massive part of the problem is solved because a much larger percentage are only using it due to network effects.
I can't speak about this being a current law, but there were laws in multiple US states at various times that prevented you from storing facial data on the server. In turn features like snapchat's face filters were doing all the relevant computation locally on the device (which back then was certainly a complicated achievement).
US tech companies are constantly under FTC audit relating to how they use user data. This is certainly not something that needs to be seriously worried about, certainly less so than say the way in which cameras placed all over cities are used to track all sorts of people or storing GPS locations attached to a specific devices UUID.
Isn't this essentially just trying to reinvent ERP (i.e. what SAP has built a 207 billion dollar company at time of writing on and 90% of fortune 500 companies along with endless other large organizations use).
One can argue that ERP as code is higher value than whatever it is right now, but to act like this is a totally new idea is insane.
The iOS version of most social media apps is better. IOS simply has better API integration to it's hardware, where with android, many OEMs (hell this was even the case to a certain extent with older pixel phones), do a number of things that make the hardware not as easily accessible as quickly from the OS API for said feature.
This is especially relevant for the camera, but also various other sensors and hardware modules that exist inside these phones.
That said, in recent years there are just a number of other areas that android is much better at such as deeper AI integration, which goes back to even prior to the current LLM craze.
I'm originally from the US, but where I live now, whatsapp functionally replaced email for a lot of different types of communication (that would be an email in the US). Recruiters text me on whatsapp about jobs, I can ask for a prescription renewal through it, and I get support from everything ranging from a government agency to customer support for things from businesses, ect.
One thing that is repeatedly underdiscussed about open source is that every time you have a major open source project become successful, be that anything from Linux to Apache Spark, you have private companies who come in, build something that can very reasonably still be called Linux or Apache Spark, but underneath has tons and tons of extra stuff that they never feed back into the open source community.
Hell, I think with the later (since all major cloud providers deploy their own version of spark on their respective data processing cluster services), people don't even know that they aren't in fact using open source software. Hell, eventually you get to a point where companies that choose not to use these third party services eventually just open source their own improvements or abstractions as again separate open source projects that never make it into the upstream project (which are often times heavily influenced by profit making entities).
This has been the model for a very long time, going back to at least the likes of redhat. And certainly will be going forward with countless future projects. Maybe there needs to be new models of open source governance, but I have no clue how successful such a thing would even be.
It depends on what you were trying to with the data. Hadoop would never win, but Spark can allow you to hold all that data in memory across multiple machines and perform various operations on it.
If all you wanted to do was filter the dataset for certain fields, you can likely do something faster programmatically on a single machine.
It's not about how much data you have, but also the sorts of things you are running on your data. Joins and group by's scale much faster than any aggregation. Additionally, you have a unified platform where large teams can share code in a structured way for all data processing jobs. It's similar in how companies use k8s as a way to manage the human side of software development in that sense.
I can however say that when I had a job at a major cloud provider optimizing spark core for our customers, one of the key areas where we saw rapid improvement was simply through fewer machines with vertically scaled hardware almost always outperformed any sort of distributed system (abet not always from a price performance perspective).
The real value often comes from the ability to do retries, and leverage left over underutilized hardware (i.e. spot instances, or in your own data center at times when scale is lower), handle hardware failures, ect, all with the ability for the full above suite of tools to work.
What an amazing set of articles, one thing that I think he's missed is the clear multi year trends.
Over the past 5 years there's been significant changes and several clear winners. Databricks and Snowflake have really demonstrated ability to stay resilient despite strong competition from cloud providers themselves, often through the privatization of what previously was open source. This is especially relevant given also the articles mentioning of how cloudera and hortonworks failed to make it.
I also think the quiet execution of databases like clickhouse have shown to be extremely impressive and have filled a niche that wasn't previously filled by an obvious solution.
They also benefit from the fact that developers do what is convenient for themselves and not what is necessarily computationally efficient (i.e. not pay attention to cross AZ egress/ingress, run an apache spark job when it could be done all within a normal database, build their entire product on irreplaceable/unswappable cloud provider specific databases and storage solutions).
AI will also experience a significant margin collapse, it's just not clear who will eat the brunt of it yet, the AI companies themselves or companies like Nvidia as more chip manufacturers/designers come into the arena and can meaningfully compete.