The Impending Cloud Reshuffle
erikbern.com
erikbern.com
I'm at AWS re:Invent this week and I can tell you this absolutely not what Amazon is doing. Two themes really stand out in the keynotes and associated presentations:
1.) Becoming a home for data and ML services backed by hardware technologies like Graviton, Trainium, and stupid fast network connectivity. Amazon has dozens of value-added services from S3 to analytic databases. By my count they have at least 16 managed data services.
2.) Extend Amazon cloud wherever possible into non-cloud environments. Specifically: push to on-prem through technologies like AWS Outposts and Container Marketplace Anywhere as well as integrate with IoT.
#2 looks like a pump fake to defuse customer lock-in concerns. The real play is #1, which is to become the preferred home for data, taking the maximum possible share of revenue in the market. Taken as a whole, Amazon has the best data story of any company I know of.
Take Elasticsearch for example, AWS is offering a clone service, but if you want the best Elasticsearch experience on the latest code base maybe you're better off using Elastic's own Elastic Cloud service that's also within AWS. If things play out as Erik predicts (and Elastic doesn't screw up) they should do just fine. We'll see if that's how it plays out.
I got sucked into GCP because GKE is (still) much more advanced than EKS or AKS and that alone was a pull factor for me, let alone the other services which I mentioned.
Does anyone who’s less ignorant than me want to give me a run down of why AWS holds so much appeal? Is it purely non technical reasons? Are they doing a much better job than GCP in areas I just am not aware about?
I ask as a genuine question to learn more despite how it may read…
We have started to use CosmosDb and it scales enough for us.
If you can get the same value from another ecosystem, you might leave for a better price. If you can't get the same value from another ecosystem, you won't leave. If you're locked into proprietary AWS systems, it might require a lot of work to migrate.
I do get where the author is coming from with RedShift and Snowflake. I think it's reasonable to look at AWS's data warehouse position and Snowflake's success and see a bit of a failure on AWS's part. However, I think that Snowflake represents a threat to AWS. If all services above the infrastructure became like Snowflake, I could more easily move from AWS to GCP or Azure.
I'd note that it isn't just about companies who will switch cloud providers. It's about whether a company can credibly threaten that they might switch cloud providers. If I'm negotiating with AWS and they see that I'm using SQS, Lambda, RedShift, Timestream, Kenesis, and other proprietary AWS stuff, they know that my threat to leave AWS is hollow. I'd have to rewrite too much infrastructure. Sure, maybe I could replace SQS with Kafka, but it isn't a drop-in replacement. Sure, there are other time-series databases than Timestream, but it's going to require engineering time to migrate.
Yes, even in a world where all the software is the same on top of the infrastructure, it would take time and money to migrate to a different cloud, but it would be less time and money. That "less time and money" means that AWS needs to be more price competitive and it gives me more negotiating power. The harder it is to leave AWS, the more leverage that Amazon has in negotiations. Companies like Spotify and Snap spend hundreds of millions on their cloud services each year. They ink major deals that they negotiate. If they rely on lots of proprietary AWS or GCP systems, it makes it a lot harder to leave - which leave the cloud provider with the leverage when the contract comes up for renewal.
If it were an open and widely supported standard it would be a different story.
1. Knative: open source standards based serverless platform that’s in the process of making its way into the CNCF. I assume this is what Fargate is on AWS? 2. Cloud functions which is also something that you can drop into AWS, Azure, open shift etc..
This is exactly the Microsoft playbook.
> There's some sort of folk wisdom that the lowest layer of cloud services is a pure commodity service.
> Cloud vendors might be pretty happy making money just in the lowest layer. Margins aren't so bad and vendor lock-in is still pretty high.
It may be folk wisdom, but big customers look at stuff like storage and CPU pricing when picking a vendor, because they need lots of storage and CPU. These services, in turn, are priced close to the actual cost of the underlying storage and CPU because of the high volume of storage and CPU involved.
I have worked at cloud vendors. Margins aren't great. Cloud vendors are always asking questions like, "How does vendor X sell this for so cheap? We can't make a profit at that price! How can we make our costs for X lower?" The lock-in is seen as a way to sell the higher-level services.
However, the high-level services, the stuff that start-ups compete with, also face competition with open-source projects. Things that used to be SaaS are now DIY with open-source projects running on IaaS. Ten years ago you had no Kubernetes, and you didn't have columnar storage out of the box on PostgreSQL. Cassandra was immature. Nowadays, open-source software running on IaaS has killed the need for bigger segments of the SaaS market, assuming you have enough expertise in-house to run it.
Most small to mid-sized companies would almost always opt to pay a bit more for a managed offering and not have to bring in expertise in-house for things that are not their core competency.
There's a big difference between the experience of opening a support ticket to fix a problem with your database and paging one of your salaried engineers to fix it--someone who actually runs the service to begin with.
Or, to put it another way, mid-sized company X can never pay as much as hyperscale company Y for Z expertise. Because utilization at mid will always be less than at hyper.
I'm all for retaining inhouse expertise, but it's fundamentally a return-on-capital optimization problem, albeit one where your capital asset has the ability to walk out the door. So inhousing core, using managed everything else is a more reasonable bargain.
Will it?
Economies of scale have diminishing returns. If you have one engineer who is 20% busy, your engineer cost per unit will be five times higher than a company five times your size who keeps that one person 100% busy.
If you have four engineers who are all 100% busy, compared to a company 250 times your size with 1000 engineers, your cost per unit is equivalent.
I'd target 60-70% utilization of engineer time. The remaining 30-40% is for stuff which can be dropped when needed (refactoring, non-critical/experimental projects, personal learning, ...). And if you have good engineers, they probably have a really good idea of how to prioritize for filling that 30-40% so as to move the company forward.
There is an inverse relationship between resource utilization and queue length, under reasonable assumptions. If you think of low CPU utilization as "wasted" CPU and try to fill it up, you can completely kill your service's ability to quickly respond to requests.
I like to make this analogy when talking to people who feel like they are not working hard enough. If you fill up an engineer's time with high-priority work, you get the same problem as if you fill up a machine's CPU with high-priority tasks... you get a system that cannot respond quickly, a system that spends a lot of time overloaded.
It's a fun exercise to try and calculate the relationship between utilization and expected queue length.
Plus, those batch jobs are still important, they're just not as time-sensitive.
> Or, to put it another way, mid-sized company X can never pay as much as hyperscale company Y for Z expertise. Because utilization at mid will always be less than at hyper.
Being able to run a PostgreSQL cluster is a handy skill but won’t get you hired at Google.
Google can afford to pay an engineer to make cool stuff like a faster malloc implementation or analyze the best possible way to encode data to be stored on disk. That’s because making Google’s malloc 1% faster will pay someone’s salary many times over, or likewise for saving 1% CPU in your disk servers.
But running your own database cluster and container orchestration ain’t exactly rocket science these days, and running your own stack means you have an expert in-house when the shit hits the fan—and that’s when your expert earns their salary, many times over.
Hyperscale companies usually invent the wheel internally and maybe release it as OS a few years later.
If a component is high cost, tightly integrated with the rest of the system, and difficult to design, then you need to be an expert on it in order to evaluate suppliers and make a good purchasing decision.
To become an expert, you have to build it for a while yourself. And once you have built it for a while and become an expert, you might as well keep that up, unless there's a strong economic incentive not to.
I agree with you that if we assume all our engineers are strictly competent, then that gives us a major advantage over our vendors, and tilts the scales to build over buy.
[1] Proxmox hosting a virtual server running Ubuntu, providing Kimai, WeKan, Mattermost, Jitsi, Mediawiki, OpenVPN access, some Samba shares, source control, and comprehensive backups.
Most likely you'll end up spending less in ops. The only problem may be finding talent, as everyone goes the AWS way so they can charge more.
- The term 'containerization' implies in theory (and somewhat in practice) that you package your software in such a way, that it can run on commodity hardware with enough resources.
- The huge success of open source means that for any given problem domain (KV stores, SQL, Web Server,LB, caches etc.). There exists a best-in-class solution that's free as in speech. In fact, cloud providers' solutions use these libraries as well.
- The development of languages that combine productivity and performance (Go/Java etc.) and with Moore's law enabling ridiculous core counts/RAM sizes etc. means that there's less of an incentive to run a server farm when you can easily fit 128 peak-performance cores under your desk. Stackoverflow did this/has been doing this model with quite some success.
> It is much different than having to sit in the car in the middle of the night to change a hard drive in the server that just failed because of a power surge.
Never ever had to go at night in a data center to replace a single disk failure, even in my DC days. Always the 1st working day after the disk failure, since they were redundant. Now, network gear upgrades during the nights, those I made a few and I'm happy they are history for me now. But even in a cloud world you have to do from time to time low-traffic time interventions.
For example: I use Elasticsearch and have used it for the past 10 years, I have deployed ES clusters myself, I have been a team lead for infrastructure teams that had to support a ES cluster, etc. I would never, ever, choose to do it myself again if I can find a managed solution. It's a lot cheaper when you factor in that you will require at least 1 engineer with expertise (or being trained for it) to properly support a running ES cluster in production.
The same applies for databases (I've managed shards/clusters of Postgres and MySQL in my life), and Kubernetes clusters, and any other piece of infrastructure that becomes critical to your business, you have to manage it and therein lies the majority of the cost of any solution: supporting it. The cloud provisions, manages, backs up, fails over, etc., without intervention from my side. Yeah, I can set up all of that myself but that is another cost to take into consideration, and something also to be maintained over the years.
Yes, I can find open-source tools for a lot of issues in software engineering, I can't find anyone to run those tools for free, so the trade-off analysis is based on this when looking into solutions, and a lot of the solutions from cloud vendors is exactly managing resources for me and my teams.
Ditto. I've seen ES / Cassandra cluster management casually dropped on a team who just happen to use an frontend that relies on them. Those are usually the most brittle, unloved databases in the world, and everyone on the team ends up walking away with the false impression that "X is a tire fire, never use it".
That said, telcos used to mint money from overseas calls, SMS, ringtones etc, until the Internet came along and everything went "over the top" (over data and thus outside operator billing). They didn't take that lying down, either (IIRC Skype was still banned in the UAE until COVID finally whacked some sense into them), but in the end telcos were still reduced to dumb pipes they are today.
They are failing badly IMO. Most developers I know hate the whole experience of using AWS.
I can't complain much as I make good money by understanding their shit so others don't have to.
That said, I always find amazing how one of the largest companies in the world does not a have a UI with happy paths for simple common cases.
Most services are a hot mess of IAM, weird APIs, undocumented limitations and gotchas.
It doesn't have to be great, only better than the alternatives. I would argue most devs prefer the rocky experience of AWS to working with their own operations people on aging hardware.
Maybe the major cloud players believe they can buy up new & unhated competitors before they can establish a loyal user base. That strategy has worked pretty well so far for the vendors of mobile computing -- which just happens to be the primary consumer of low end cloud services.
So if mobile can be commodified some day (the way unix workstations were by Linux), maybe basic cloud services can be too?
I need a managed PostgreSQL database; my needs would have to be relatively exotic for e.g. RDS to not be a good solve. AWS has deployment options for the big stacks. Tools like Vercel do not yet address the solid majority of Web developers who primarily write code for .NET or Java, and thus are not even in the conversation at most organizations (and nobody really wants 2+ PaaS vendors).
This is not to say the point solution vendors will not be able to build solid businesses. MongoDB is doing well alongside platform solutions like DynamoDB. But the gravity is clearly with the platforms, and nothing Mongo can do (short of becoming a hyperscaler cloud provider with lots of offerings) will change that.
Snowflake is a special snowflake; it's entirely possible that the lessons of Snowflake apply only to Snowflake.
I believe having 1 or 2 max vendors, providing most of your services, is immensely beneficial in the long run, for many reasons.
It’s inevitable that things like Vercel, Netlify, Fly, and Render are copied by Amazon. It’s what they do, they want the full stack top to bottom fully integrated.
The thing they will never compete in though is developer UX, that’s where the smaller vendors (like those mentioned above) will always shine. AWS is now about 100x to big to have a good developer UX, there is just to much there.
The company that is really shaking things up is CloudFlare, they don’t seem to be afraid of playing with the business model to undercut AWS.
In terms of strategy, AWS is completely and totally unapologetic about copying companies built on top of their platform if it helps them in the future. The author suggest that there haven't been this many companies aimed at the vendors before but that's a lack of insight into the history of how they came about in the first place. When AWS was first launched there were dozens and dozens of vendors competing with, building on top of, and partnering with cloud vendors. Almost none of them exist today.
Snowflake is an incredible exception but not a rule. The reason they succeeded (and the reason I personally believe fly will succeed) is because they're building hard to implement underlying technology and focusing on DX. That's basically it. If you're going to compete on economics you're absolutely hooped.
Note the (current) top post on this article:
> hodgesrm 4 hours ago | next [–]
> I'm at AWS re:Invent this week and ... Two themes really stand out in the keynotes and associated presentations:
> 1.) Becoming a home for data and ML services backed by hardware technologies like Graviton, Trainium, and stupid fast network connectivity. Amazon has dozens of value-added services from S3 to analytic databases.
So if Snowflake is helping AWS succeed in AWS goal 1 ("home for data"), I think AWS is smart enough to help Snowflake grow and prosper.
At the moment it really seems that AWS is most successful here since all of the new and more advanced SF features are coming to AWS-based SF first. Then again, SF started on AWS so probably has most of their roots settled there.
While data replication across clouds in SF is expensive, I'm sure SF could/might absorb this one-time cost for you if you needed to migrate, esp if there was any sort of threaten from a particular cloud provider (assuming we're talking about internal stages and tables, not external stages/tables).
It's really in SF interest to lower this cost (or liability as you might see it) since they're really pushing for a multi-cloud data ecosystem. Just look at their data exchange product and how they're trying to make the underlying cloud platform irrelevant. The only thing really stopping this from taking off is the cost of setting up replicas in an of the regions or clouds that you want to share to or consume from.
I agree. This is how I think about successful software. Not entirely sure there is enough supporting data, or at least it's not easy to collect/access.
I am sure that even if independent services are more loved by programmers, there will still be substantial amount of companies using AWS versions. And since the bigger companies would prefer them, I would not be surprised to know that AWS earns more money from them than startups do.
> [Redshift] was a brilliant move by AWS, because it immediately lowered the bar for a small company to start doing analytics.
Every sales organization I've ever seen collected too much data. What the kids today call "analytics".
And these orgs don't know what to do with it all. So much so that they delude themselves. Convincing themselves they're divining wisdom from noise. I have no idea what this phenomenon is called.
In fact, most recently, my last gig had decades of data hosted on Teradata, was migrating to Redshift. I worked on the Recommendations team, which was trying to evolve into Personalization.
Teams of data scientists. So much data. A cultural legacy of batch processing hidden behind ML pipelines. So much effort.
It took me a while to figure out most of the "work" my team did was completely fictional. Our most effective recommender algorithm was just showing people what they'd already looked at in the last 6 months. But this simple truth was hidden behind a massive rube goldberg machine.
So. What was true of CRM and ERP systems in the 90s remains true today. Collecting data without purpose, without a working hypothesis, without experiments validating the effort, is just wasted effort.
In my time, I've worked with two very smart marketing people. Knew how to design a survey, how to crunch the numbers, validated their own work. Once you see how a pro does it, you realize most everyone is just faking it, fooling themselves along with every one else.
Pretty much just like every other discipline.
--
Oh. How does my cynicism relate to the OC's prediction about a cloud shuffle?
For the users of cloud stuff, making data collection, aggregation, and analysis easier and more accessible is a net negative.
Which I suppose is great for cloud providers.
That's called projection.
It's called either pereidolia or apophenia
You are technically correct, the best kind of correct!
1) Cloud provider core competency is basically IaaS
2) Some level of SaaS was baked in to attract or lock-in customers, but isn't really a core competency
3) This leaves room for faster more agile startups to come in and build best of breed SaaS solutions on top of the IaaS, including those areas where cloud providers already have their own solutions.
I don't see a tipping point on the horizon to warrant language like "impending reshuffle", but I think it's an interesting trend to keep tabs on.
I cannot say I have enough data to agree or disagree with the prediction. Mostly, the Cloud is still very early in its development.
The Cloud today only changes how the underlying business model works in provisioning computing. I.e., people now by default goes to Cloud for machines. That's a generational transition from the old DC/on-prem model.
But on top of this new model, the software only start to gain some properties that are distant from the old model fundamentally. Lambda is one such example. Docker/Kubernetes, as the article points out, is actually very incremental development over the old models (thinking about Vsphere puppet scripts etc.).
My sentiment is that fundamental shift like Cloud, only manifest itself after it gives birth to fundamental shift in how applications are developed and run. There are a lot of relatively new trends in this area, but none of them give me the impression of a killer paradigm. I am looking for something like PC + windows, Internet + Google, Cloud + ? type of thing.
Let's see in 10 years.
All vendors are moving up the stack, with the eventual endpoint being even business productivity apps aligned with Azure, GCP, AWS.
They all see IAAS as the commodity end with less value add and lock-in.
This is undeniable through actions and PR statements and has been the observed direction of travel for a decade at least.
I could do all that for a fraction of the cost with dedicated servers outside of EC2.
I don't know where this guy worked but I've seen at least 10 cloud migrations in my career, across different clients. It's not that uncommon and not too expensive unless you're relying on weird services on top of your cloud.
Not sure why the '/s'. Options exist, and not just "AWS or GCP".
In practical terms, the hassle of managing the hardware is far greater than having to manage software, especially now that everyone is on the container boat. Not that it was necessarily different for people on bsd + jails in the past, but that wasn't widespread.
I think dedicated server are a sweet spot of complexity / cost.
AWS $16,000M revenue Q3 Azure $9,000M est revenue Q3 GCP $4,500M revenue Q3 OVH $181M revenue Q3 (~46M "cloud") Cloudflare $172M Q3 Hetzner $277M est revenue (2019 year)
A lot of customers find smaller providers very valuable. But the reason you see so many mentions of AWS/Azure/GCP is simply a reflection that yes, the bulk of hosted services in the world are based on those three. Yes the HN crowd might like the approach or thought of the smaller service providers, but they are much much smaller.
AWS solves mostly an accounting, not a tech problem.
Seems like AWS is still making their money on the underlying layer in our case.
On one side you have Cloudflare. Cloudflare is the Apple of cloud. They're gunning for the big 3 by vertical integration and proprietary products and hence changing the way the market operates.
On the other side you have up-and-coming IAAS and MAAS providers chipping away at the margins. These are either commodity providers that cut the fat, or owners of DC and/or connectivity so has the synergy to undercut the cloud platforms. This plays into the open platform push such as cloud native / kubernetes.
It's almost certain that the cloud providers will lose marketshare in the IAAS space as they simply can't compete on cost. Regulation is also going to catch up to prevent cloud lock-in. So the only play these platforms have is to fight on scale and features which means continuous expansion on all fronts, including higher-level services.
As regulations catch up, national borders continue to impact how businesses operate across networks, etc., I doubt the cloud model will still look good in ten years. Half the benefit of the cloud is just being... newer. Interfaces are often more modern simply because, well, the Windows Server team all started working on Azure instead. A decade from now, people will look at the pains and problems of working with AWS and Azure the way people look at dealing with Windows Server and hardware maintenance today: Looking a little rough.
Marketing. Everyone has heard of Snowflake. And not just IT people. Finance, marketing, I’m sure even the cleaners have heard how wonderful it is.
Redshift on the other hand is something that a lot of IT people and even some data warehousing people seem unaware of.
There are many people who seem to think that Snowflake is the only option.
Last week AWS uncovered Redshift Serverless, but still on technical preview.
Another point, Snowflake is just easier to use. I've seen young developers who knew a bit of database stuff setup and play with it with little help.
Redshift on the other hand is much more entrenched in the whole AWS mess and requires one to understand shit like VPCs, security groups, IAM, cloud watch, etc....
Seriously?
I hate the fact that most of my projects live on AWS right now. But I don't feel locked in; I can jump off if I want. I don't buy into the entire ecosystem (read: the parts that are difficult to migrate away from), but AWS is just an amazing way to manage lots of resources and patch them together in any way you can imagine. And therein lies the creativity and control -- and cost savings. Because no two projects scale in the same way. The fantastic thing about self-managed cloud environments is that you can find the right size and scalability for each thing, and everything is where you put it. Zero-downtime is up to you. The biggest drag on downtime is people in between you and access to restarting or working directly on those services. In the 2000's, I used to have to put in a fucking ticket with tech support to reboot a server in a datacenter six timezones away, and it wouldn't happen until someone had breakfast.
Do you think people who write code and handle the optimization of it across databases and servers around the world, want to pay a middleman to "magically" do everything - and see why it doesn't scale, and find out who to call when it breaks? No, of course they want control over how their organization runs.
I mean, part of my job is just identifying services we're currently overpaying for. I can take that down to a very fine-grained level with AWS. Why would I want to pay someone else to hide that information from me?
"The edge" is like "no-code visual programming language". No one seriously wants convenience over power; but it's a great marketing pitch.
2030 will not be the revenge of managed hosting brought to you by lazy corporations like Cloudflare. It will be distributed self-managed stacks running everywhere.
One big challenge for cloud workloads is multi-tenancy. If you want to run arbitrary untrusted code on the cloud, your only option is something like gVisor (which isn't exactly a compromise-free solution). Nested virtualization is not secure and will likely even preform worse.
My claim is that it isn't possible to build services on top of GCE/EC2 that compete with 1st party cloud offerings in important ways.
The problems with nested virtualization are mostly in silicon and to some extent in kvm. Firecracker doesn't really have much to do with it as the VMM isn't the problem.
You could use Firecracker to build your own GCE/EC2 competitor on bare metal, but that solves a different problem.
I think the cloud providers have incredible amounts of engineering resources. Their aim is to do anything to get everyone onto the platforms. I don’t see any clear trend coming out in the years ahead. There will be a myriad of solutions (some wholly owned by the cloud provider and some with a third party like snowflake or databricks involved) and customers can choose what works for them.
I was just watching the AWS keynote and it seems they are doing the opposite, offering more and more ready-made services so that startups don't need to write software at all.
What's the end goal of this? In the future amazon will use ML to auto-generate startups and offer them for sale. Then startup entrepreneurs will not need to hire programmers anymore, they will just buy a premade startup from AWS and become traveling salesmen. Basically gig worker CEOs for Bezos.
The reality of auto-ML is that you don't need garbage data to learn garbage. All you need is a "developer" who has no idea how dirty or unstable their data is, how accurate/precise the results should be, or where bias and edge cases manifest before GIGO becomes your project's mantra.
The claims of auto-ML and auto-programming are two sides of the same coin. They're both silicon snake oil.
Software is easier to administer these days (don't say buzzwords like "cloud native" never did anything for you), and the startling thing is that the larger clouds still have a near monopoly on robustness/service choice. Of course I'm lying a bit here -- OVH has managed databases, and there are Managed Service Providers (MSPs) that run in places that are not the major clouds but the point here is that fundamentally technological leverage and hardware prices are actually chipping away at the moats of the large clouds every day. Larger clouds have to move up the value chain, and that is exactly where smaller companies can have an advantage (not in pricing, but in quality).
Hetzner has just opened it's first US data center in Ashburn, Virginia -- and IMO was worth using when it was only in Germany. Time to interactive is really important, but almost no one worries about this when it comes to dealing with backends. Deploying your frontend to cloudfront/vercel/any other CDN and leaving your relatively simple backend (what you might use for a simple three tier ruby/django app) is extremely cost effective but requires know-how. Hetzner starting operations in the US is going to introduce new competition in the lower layers of this vertical, and there's absolutely no reason that the Managed Service Providers (MSPs) can't take advantage of this and grow their customer base. I'm trying to start making the know-how portable -- building a cloud that runs on many providers (starting with Hetzner) and I'm calling it Nimbus Web Services[0] with a launch early next year.
[0]: https://nimbusws.com
The profit margin/markup cloud providers make increases the higher you climb the abstraction layer. 1GB of RAM is 10X more expensive in Lambda than in EC2, but costs AWS the same to provide.
Second - services offered are a key selling point and driver of competition between clouds. they all want more features.
Third - considering point 1 & 2, clouds prefer to offer their own versions of things. i.e AWS and the Elasticsearch fork.
Interesting article.
The words 'traditional' and 'cloud' in one sentence... I can't stand that. The cloud is just marketing speak for the internet. Make it vague on purpose so you can sell the same sh!t in another package to more people. And grab all the data in the meantime.
HN is smarter than this, right!?
But what percentage of cloud programmers are wise to this? The individual programmers make the decisions that cause lock in
Cloud vendors know how locked in you are when you negotiate discounts, but by that time the key decisions are long past
In the vast majority of cases that decision really isn't going to be influenced by whether your existing system on AWS does or doesn't use Amazon specific tech. If you're "moving" your service from AWS to Azure those kinds of implementation details just don't matter, in most cases you're effectively going to build a replacement system and not really migrate an existing one. The costs of such a migration would in most cases dwarf any possible savings, no matter how carefully you tried to avoid lock-in.
I'm obviously generalising a fair bit, but the exceptions are likely to be less complex systems that are perfectly fine using fairly generic services.
Can AWS seriously buy and operate infrastructure for half the price than anyone else ? I can't imagine that being cheaper than running the datacenter yourself.
They simply call city/state/country X, and tell them: Yo, we are going to build a datacenter farm here for AWS. You are not going to tax us, provide half the funds, and we will try to source the workforce in your region mkay?
And that is how their datacenter is almost gratis, and ours costs millions.
Once you are at the AWS scale, things are differen.
But will vendor lock-in will be significantly lowered if the scenario predicted comes to pass?
Regarding the article: "Kubernetes will be some weird thing people loved for five years"
What will replace it? It seems to me that people are moving towards K8 because it's the right abstraction.
Regarding suggestions to use Herzner. I just looked because, while I knew the name, I didn't know the offerings. All I see is web hosting and Linux VMs.
> If that customer switches their $1M/year budget to Snowflake, then about $400k7 goes back to AWS, making AWS about $200k in gross profits.
> That seems kind of bad for AWS? I don't know, we ignored a bunch of stuff here.
> …
> I'm not so sure? I spent six years as a CTO and moving from one cloud to another isn't something I even remotely considered. My company, like most, spent far more money on engineer salaries than the cloud itself. Putting precious eng time on a cloud migration isn't worth it unless cloud spend starts to become a significant fraction of your gross margins. Which is true for some companies! But those are in a minority.
I like this style -- conversational, well-cited, like an industry insider giving you an off-the-cuff read on their discipline at a party -- and I'm glad we're seeing more of it. Do I misattribute it to Money Stuff? Was someone doing it before?
(Some of my formative reading experiences were with Art Buchwald and Erma Bombeck and I think I see a hint of that too.)
Disclaimer: I work for IBM, and my opinions are my own.
Sorry/not sorry but I’m sick of this bizarre startup fetish for syntax art and finance as usual.
The algorithms are public domain. It’s still feudal property ownership. We call caste cohort now, having conjured another abstraction to confuse the rubes.
We send kids to college to define statistical objects of unknowable information network effects in many contexts to keep them busy. We’ll probably just morph to supporting the logistics network in the abstract. I can see teens and 20-something basically nationalizing that approach once enough old people die. It’ll all be boxed up behind tidy APIs