36
votes
Capitalism is dead. '[Technofeudalism is] something much worse’: Yanis Varoufakis on extremism and the tyranny of big tech
Link information
This data is scraped automatically and may be incorrect.
- Authors
- Carole Cadwalladr
- Published
- Sep 24 2023
- Word count
- 2785 words
AWS is 100% rent-seeking. It was originally deployed to help Amazon subsidize its own infrastructure. It's a service, yes...but it's a service the same way that a landlord is offering a service.
The person building on top of AWS is building capital. Amazon is merely charging rent. And when approaching it like that, it becomes quite apparent the power disparity between Amazon (and Microsoft and Google) and their customers. And that's just their actual cloud offerings, not even getting at the "you are the product" aspects of other services.
And since a cloud migration can be incredibly expensive, especially if you use their managed services, it very much ceases to be a market once you've 'picked' your provider. You're stuck with what they charge you unless you have enough saved up to afford to eat the loss of a migration off of them.
As a complete tangent, my favorite rendition of this song is still William Shatner's, though Ben Folds does a lot of the heavy lifting there.
I find this take around AWS and other Infrastructure as a Service (IaaS) environments somewhat weird. They are, rather explicitly, renting you computing infrastructure. There are companies that offer a lease-to-own public/private cloud hybrid, but the pure IaaS platforms are very upfront that you are renting compute resources. They have native and managed services that create a lock-in effect, which is true of any major technical adoption. Running complex software systems on your own hardware is still lock-in.
In this way, would renting an auger from Home Depot be rent-seeking? I mean, you are renting equipment, and I now don't need to buy it, nor do I need a place to store it or worry about maintenance. If I will use it enough, then sure, buying makes sense. But for occasional workloads, it doesn't.
The counterargument I often hear then is that with the server, you can redeploy other workloads to it, but this assumes all compute resources are perfectly fungible. They aren't. Getting complete usage of your hardware at scale is actually quite hard. Most organizations have significant waste in their use of VMs and even containers and lack the (expensive) orchestration tools to right-size and automate spin-up and tear-down. Additionally, when you have to buy more hardware when you run out of resources, it means you have to buy more than you need based on predicted growth. Finally, when you have a downcycle, and your cloud infrastructure is used less, your costs do go down. With owned equipment, you still have the full costs of data centers, hardware, power, cooling, etc., so it is harder to make your compute resource costs direct costs on the service you are selling.
In a cloud environment, it is trivial to tag resources as dev, test, prod, and automate shutdowns, limit spending, and control bloat. The APIs are all there, and best practices are reasonably well-defined.
In a former role, I was director of cloud engineering, so I know this space well. While a naive organization can absolutely waste its money getting to a cloud-hosted model, or putting things in the cloud that just don't belong, there are many use cases where the cloud can save you money, or the expanded capabilities are worth it. Building isolated enclaves in a cloud environment, separating customer data, and automating across large platforms are all easier in the cloud. Those efficiencies and tools of being in the cloud are worth something. Not to mention the compliance tools baked in.
Here's a small, fun example of the sort of stuff you can cobble together easily in the cloud at a personal level. I game with my friends, and we often like to play games that benefit from dedicated servers. It gets expensive to run dedicated servers all the time, and we are all busy working professionals who don't want to dink around when we all have the time to play. I also have kids who might want to join us in Valheim or something, and they might want to play on their own.
In AWS, I have an API gateway defined that charges me based on invocations and, in my case, REST calls. One invocation returns a JSON blob that contains lists of games and game server commands like start, stop, restart, and connect. Each of these commands is just a link to another API gateway call with the proper query string variables. The initial blob also returns a list of iFrames of Cloud Watch dashboards for the server resources and uptime.
Each API call triggers a Lambda function in either node.js or python. The functions start and stop the servers, return their current IP address, etc. The servers themselves are all Linux systems I launch and configure from a pre-built template I made for hosting all Steamcmd compatible games.
I don't pay anything at rest, except for the small amount of storage used by the servers. I don't pay for the API gateway except for when they are invoked. I don't pay CPU for servers that are off. I don't pay for Lamda functions when they aren't being run. I do pay for the S3 bucket that the servers back up the game worlds to on startup. Oh, and they access the S3 bucket using an IAM role assigned to the servers, so I don't have to mess around at all with credentials on the systems for the backup.
So, I pay pennies unless the servers are in use. They auto-shut off at 3 am if someone forgets to shut them off, and I can distribute a small dynamic HTML file to all of my friends so they can hop on any time. I pay maybe $20-$30/month for a dozen or so servers to be available for us to use anytime. If I add a new server, it just appears in their HTML dashboard and is perfectly sized to the game and our group size.
I couldn't do any of that self-hosted. I would have to manually spin things up and down, give VPN access to my network to my friends, or some other less elegant solution. I have built highly scalable applications in the cloud-first style that scale costs with revenue, etc, so it's not like I couldn't make something workable at home. It's that the features of the cloud make it a better choice.
Am I paying rent to AWS? Yeah. But I control the data. I can get it out whenever I want. I control the costs. And I get good value for what I pay, and if that changes, I can take my ball and go home.
The same is true of large corporate deployments if they are well-managed. But judging an entire ecosystem based on poorly managed deployments doesn't make a lot of sense to me.
It helps if you are more familiar with the economic concept of rent seeking. To quote wikipedia-
Obviously pretty broad, but there's a very common example provided-
and if you want a more modern example
There are others, and it's an interesting topic, but unfortunately a lot of people hear rent seeking and feel that "everything charging rent or a fee is rent seeking" and it's just not. Vord comparison of a landlord being rent seeking is a pretty common tell, simply because there are 100% landlords that are not rent seeking by the traditional definition (arguably most), but with this being a heated subject and landlords charging "rent" the misuse is understandable.
So now there's the textbook definition and the colloquial(?) definition (sorta like Narcissist vs NPD).
Bluntly, while there are a lot of dangerous things about AWS and its peers, it,s pretty clearly 100% NOT rent seeking. The claim vord made that they've built "nothing of value" is just preposterous if you have any idea the level of tech that goes into these distributed systems. The problems stem much more from the monopoly/oligopoly issues inherent in the system with lots of ways to lock you into the ecosystem (much like the issues with landlords really have little to do with rent seeking behavior and a lot more to do with cornering the market of a limited supply.).
It makes this subject impossible to discuss because what people are saying and what they mean are totally different things. AWS is not a healthy thing, but its just not rent seeking. Arguably they will be able to rent seek if they get you locked in their environment and arbitrarily raised prices (still not sure that 100% applies since its more like just upping the toll on the bridge you built rather than the chain example) but this becomes a really difficult thing to judge (as there are very legit reasons to raise prices) and still stems more from them even being able to do that without reasonable competition.
I appreciate you breaking down the background, thank you!
I do agree that competition is good, and it is unfortunate that in the IaaS space, at least in the US, that we really have three providers: AWS, Azure (Microsoft), and GCP (Google).
At the same time, in my prior role where I mostly used AWS, I still had a footprint on Azure, and I had an extremely obnoxious Microsoft account manager who was constantly offering me free training credits and migration assistance if I'd move to Azure. AWS and GCP have some similar programs, they just aren't as pushy as Microsoft was.
So if you are a large organization, you have all three chasing your business.
I think the view of whether services like AWS are healthy or not depends on your view of their customers. As a customer who has a data center, and a cloud practice, and a blend of operational and capital dollars I can tell you that the challenges of on premise and cloud are very different. I had a whole set of criteria and workflows to determine if a workload or service belonged on premise or in one of our cloud environments, and a whole different set of headaches getting capital vs operational budget. Generally though, where cloud shines is where you can tie the direct costs to a discrete activity or service. Then the funding gets baked into the execution of that process or delivery of the service. If the business needs more of X process it costs more, and when they need less it costs less. Very appealing to the finance folks. On premise and capital dollars was better suited to services related to overhead expenses that would be difficult to track consumption per unit or service. So the capital dollars become part of our overhead rate.
I certainly didn't feel taken advantage of, but I also didn't swallow the hype and move everything to the cloud. I don't generally view big businesses as rubes in need of protection, and most small businesses or individuals just don't have a complex enough deployment to truly create an insurmountable lock in effect that can't be overcome by some concentrated effort.
In fact, I greatly valued having both on premise and cloud. Sometimes you have a use case that just needs somewhere to run, or is very steady state, and those work well on premise, though a case can be made for reserved instances. And for workloads that are bursty, tied to variable services or processes, temporary, or otherwise differentiated, cloud is really helpful to have.
For example, I had over 50 office sites, with 5 large campus plants and networks. Some services just shouldn't be tied to any one physical location. Putting our authoritative DNS on the cloud, and anycasting our small resolvers at every site is a great example of cloud and on premise pairing.
But I digress. Thanks for the reply, and have a great night!
I guess. But I do almost the exact thing with an old laptop sitting in my closet, and it costs me like $5 a month in electricity. If I didn't also use it for other things, I could probably drop that to $2/mo by turning it off at 11PM and spinning it up at 5PM. I opened the range of ports that I used on my router to direct to my server. No need to spin down the servers, they just sit idle consuming no resources, outside a small handful that are extreme memory hogs. And a sufficient aggressive swap config takes care of that no problem. And I don't have to worry about egress costs, which bit me in the butt one month when my free tier cloud node ended up routing a bit of traffic for my other servers.
If I want a new game, I add it to the config, spin it up, and basically forget about it.
I get using the tools that you're comfortable with.... but hearing "Oh I just spend 3x the amount of money and double the complexity to do the same thing" over and over and over again is why I doubt the value of the cloud for a solid 90% of use cases. At the price you're paying, even if I amortize the cost of the laptop in with how long I've been doing this, I'm still ahead of you after 3 years.
This is… not a reasonable comparison. You have one computer that can do one game, not a cloud of computers capable of servicing multiple parallel groups of players playing different games. Also, you actually bought an entire computer, which doesn’t upgrade itself every couple years and sometimes requires maintenance. You would have to do a whole lot of multiplayer gaming to break even on this when OP is only paying $240-360/year for this setup.
Isn't it? Its for a group of friends, not hundreds or thousands of players.
32 GB of RAM plus some swap and 4C/8T buys you quite a bit of parallel play for many games with a bunch of idle spare.
If I was needing that level of scale, it would be a different story. And that's kind of my point...many people incorrectly assume that they need gigantic autoscaling infrastructure managed by someone else.
When in reality, assuming you have a non-trivial base load, over provisioning hardware to be able to handle most peak load and just letting it sit 80% unused during low demand will be less costly.
I'm not saying there's no space for autoscaling cloud services. I'm just saying that the space for them is much smaller than most presume and lots of people are paying too much money for it.
I think the crux of the situation is that different people and organizations have different needs, value features differently, and thus pursue different solutions for similar looking work.
Some companies want to minimize risk by outsourcing risk to companies or services with more expertise or resources to manage a failure. Others want to maximize control, or minimize costs. Or align costs with revenue. Usually a blend of all of that and other factors and constraints, often on a service by service basis.
I value my cloud solution because it just works, and it will continue to just work without any intervention from me. The game servers will always turn on when people want to play, I never have to worry about a bad hard drive, dimm, buying an upgrade, etc. I have ultimate flexibility, and different people can do different things while chatting on teamspeak. I don't have to worry about my home ISP going down and keeping other people from using it, etc. Those are all things I value, and value differently than you. Could I minimize costs other ways? Yes. But I would incur some amount of risk or work associated with it, and that's not worth it to me. I value the rare moments schedules align across timezones more, and that is of course when I would learn about a show stopping issue.
So God speed to you and folks self hosting at home. I get it, I used to do it. It's not wrong. But neither is cloud. It's just different solutions that reflect different needs or values.
So, the personal example was to highlight the capabilities to build a service with direct costs. I.e., a scalable service that costs almost nothing at rest and whose costs scale up and down based on use (and hopefully revenue).
That said, without more details, I'm not sure that what I laid out is really the same feature-wise as what you described, and if they are feature-comparable, I doubt my solution is particularly more complex. I don't have your details, but if I wanted to build what I have in AWS at home, I would need the following:
Hardware. I would need a piece of hardware to run the game servers. Some of these games are indie and don't have very efficient server tools. The Forest comes to mind as an example of one that requires Windows emulation and 8 GB of memory for the number of players we have. I could build a fairly modest small form factor system with a good SSD fairly cheap.
Port forwarding. I would probably put the host in a DMZ rather than futz with individual ports because it would be hosting so many games with different and overlapping ports it would take a bit of work to keep track of it all.
Web host. To have a website that my friends and family can use to self-serve, I need to host the API I described above. Instead of just writing the Python or node function, I now need to configure the web server. It's not hard, but it's another thing I need to deal with. I also need to write the functions to either launch the appropriate VM or container. None of the on-prem tools I've used have been as clean as the AWS BOTO3 library, where the python function is literally three lines of Python to reboot the particular VM. It's not hard, but it's one more thing to manage and patch.
Hypervisor or Docker. To have each self-contained game and run one or more at a time, I would need to run a hypervisor that I can programmatically manage from invocations of the web API. It's not hard, but it's something else to manage and patch. In AWS, I don't need to think about the hypervisor hardly at all.
So, running on-premise, the hardest part would be solving the network issue with multiple games running concurrently that all want to bind to the same port, and some don't easily allow port remapping. I think I can deal with that; my home firewall is an enterprise appliance not unlike what I used when I operated a large VPN service. But coordinating the configurations from the network appliance to the host to the VM/container on my own would require some work on my part that I get out of the box in AWS.
I would also have much more surface area in terms of security and patching. In AWS, the only server I have to patch is the game VM's themselves, and that is handled via a cron job on the host. I don't have to patch or manage web servers, storage servers, etc.
And the big thing I keep going back to is that my kids can play one game while I play another at the same time, and I don't need to have a host in my house sized for my worst-case. I can spend a little more in one month and less in the next. Am I paying a premium for flexibility? Maybe. I'm also avoiding the cost of a pricier or more robust local server.
That said, I'm all for home lab and saving money. But I think I gave enough examples above as to why an enterprise would value a unified API across the entire OSI model, the ability to scale with actual usage, and the sorts of cool stuff you can build for even personal stuff.
As someone without a background in economics, could you help explain a bit about how this is rent seeking? I only skimmed the Wikipedia page, but as far as I knew, AWS needs to pay for (among many other things) equipment depreciation, vendor support contracts, their own support tiers, property taxes, employee (ops and dev) wages, literal power to keep the lights (and data center AC) on, etc. which is where most of the service price comes from.
They charge economic rent, but that sounds like it’s another term for a profit margin, and doesn’t touch on the market and regulatory manipulation that the parent article refers to as rent seeking (which I guess might literally mean “seeking to increase your rent/profit”?).
I suppose I’m not sure how any service could avoid being called rent seeking if the definition is simply owning something (eg my time or equipment) and using it to perform an action (eg providing a haircut).
edit: Wow does the economics rabbit hole go deep. I couldn’t wrap my head around this with some spare time on the lunch break; I suppose I’ll write back in a while in case I get to a point of decent understanding.
This doesn’t sound like rent seeking because it’s not rent seeking. OP is conflating rent seeking with renting.
You are correct, I did mix them up a little bit. AWS is renting. Amazon is rent-seeking by offering AWS. Rent-seeking is growing one's existing wealth without creating new wealth.
Landlord whom buys a house and then rents it out: Rent-seeking
Home developer whom builds a new home, then sells it at a profit margin: Not rent-seeking.
The first case does not create value, merely profiting from the ownership of value. The second one is creating value. There are arguments to be made about building out and then only renting the building-out...but even then only the actual act of building is creating value and then renting it out is rent-seeking behavior.
And in that vein...I still see AWS as rent-seeking. They're not helping companies build out IT infrastructure. They're luring companies into renting hardware that they should be owning.
I don’t see AWS as not creating wealth, is I suppose the difference in opinions. By creating efficiency and purchasing hardware they enable businesses that in some cases may not be able to profitably exist in the first place.
In some cases, probably. Definitely not in many cases. The other day I needed a cluster of over 60 machines for a day or so. I can tell you, I don’t need to own those computers — it would have taken a week to install them, I would have needed to buy a new office suite to physically fit them, and now they would be sitting idle.
I agree with you. It really feels like the people criticizing AWS have a pretty narrow set of experiences. Having managed a data center, and a cloud practice, there are good cases for both and bad examples of each.
Similar to your example, I helped a physics department setup a cloud environment to host an annual workshop. Once a year they need lots of compute for a week to do collaborative wave function modeling, and the rest of the year very little. It's a perfect example where buying hardware isn't ideal, and I'm not sure where this belief that all of AWS customers are rubes being taken advantage of is coming from.
Mostly ignorance, in my experience. I've seen a vitriolic backlash against cloud services among a certain subset of IT staff, after it became trendy to go fully cloud based for a few years.
Like many things, in reality choosing the correct approach requires a nuanced understanding of the circumstances. Sometimes cloud is the way to go, sometimes on-prem is what you need, and often there's a hybrid middle ground that can get you the best of both worlds.
A rental property is different because the supply of housing and space to put houses is limited and you deprive others of a place to buy if you rent it out instead.
You can set up a server in your basement if need be, you don't have to rent, the parts aren't hard-limited.
The book, Technofeudalism, is available for, uh, preview on Anna's Archive for anyone wanting to get a taste. I haven't read it yet, but seems interesting. Figured there might be some discussion to be had on here about the article or the general concept.