Hacker News Reader

Comment by zarzavat | Hacker News Reader

> If you are not using cloud native features you are essentially just using a virtual datacenter at which point AWS is an expensive choice.

Hence “you probably don’t need AWS”.

> On the other hand, if you use Kinesis, Lambdas, RDS, VPC peering, and IAM accross all of them including EC2 and EKS, then no, none of those other options can even come close. Purely the lack of system-wide IAM alone would be a dealbreaker.

Hence you are locked in and have zero negotiating position. Your business has an existential risk based on AWS - assuming your code is critical to the business and could not practically be rewritten because of all this special sauce you’re using.

That might be okay but I sure hope your CTO made that decision consciously.

View on HN

The same is true in reverse. If your team assumes they need the optionality of avoiding cloud lock-in, your CTO had better have made an explicit choice to pay the overhead of not using these cloud services.

Sure, you can play FUD games about AWS suddenly raising prices, but I doubt you'd have any historical evidence to back that up. So you'd better be able to say why being cloud-agnostic is critical to your business.

AWS prices are already high, the danger is not so much that they will raise prices but that if your business conditions change. Perhaps there’s a new competitor and you can’t afford to splurge on cloud costs anymore, or your business needs to cut costs and focus on profitability because of economic conditions - you are stuck with this albatross.

High compared to what? GCP? Azure? A raspberry pi in a closet with a cable modem?

You generally pay for what you need and for what you can afford. If you don't need AWS or you can't afford AWS, it wouldn't make sense to use AWS. That goes for in-house software development, infrastructure management and pretty much anything else too...

I run a startup and work in another.

In my startup we use mostly linode and handle a lot of volume. I have a few VPSs and some dedicated hardware for specific tasks. Monthly bill roughly 200-250USD all included.

The other startup used the AWS free credits. Got extra credits and lived it up. Adopted Kubernetes and all the big AWS stuff. Brought in a few devops professionals. All super smart people.

Monthly spend 7kUSD on traffic/usage that's actually much smaller than the one I have with my startup. Availability is roughly the same (if anything, my startup has better uptime).

So yes, this is an Apples to Oranges comparison. I get that. They can better scale in theory etc. But if they pay 7k right now, I can't imagine how expensive it will be when they scale.

They started just using EC2 but slowly got roped into AWS services so now they have no vendor neutrality and no viable/easy way to reduce these costs.

What type of usage volume are we talking about here?

But AWS spend a lot of time selling you lambda over any of these other solutions.

If you have less traffic then you should spend less.

This sounds like they don't have anyone who actually knows what they are doing, or did any form of cost/benefit analysis which will always mean you spend more than you should.

So none of your requirements match up with AWS services. Of course it's not going to be a great match in that case, right?

If you need 'some random compute and a bit of networking' then no, do not use AWS.

Vendor neutrality isn't worth match to a business unless you are the EFF or intend to move vendors all day long.

You don't need AWS or any other cloud for volume (traffic volume, that is), heck I'd say stay away from the clouds for volume since that is where the bulk of your money disappears anyway.

They likely overcomplicating things for no good reason. If you can handle their load on a $250 VPS what the heck the are doing with AWS?

It depends on the situation, but by keeping a simpler architecture there's not necessarily any overhead. AWS has huge complexity which is a tradeoff against the complexity of simpler solutions, regardless of the $billing cost.

That sounds exceptionally vague. Simplicity rarely is bound to some vendor and more likely to be based on requirements and implementation engineering. It mostly gets as complex as it needs to be.

Simple things are simple: need IPv4 networking? Get an IPv4 allocation and route it to a (virtual) port of your choice. That is no different between on-prem, managed-dc, unmanaged-dc, managed server provider and cloud provider. There might be some semantics that are different, where a physical port cannot be unplugged via an API (at best you can down/up a switch port but that's not the same) and routing may or may not be implicit, may need a firewall or routing rule and may need translation. But all of that applies always anyway and gets named differently on who you are paying for it.

If you create something very complex, but it didn't have to be, perhaps it's simply a bad implementation and not a property of the technology that was applied. There are plenty of engineers that think they can roll their own crypto libraries, write their own filesystems and their own RDBMs... but what business case for the 99% out there really requires that? Nearly everything in a business is a generic problem any business has; it's always about products and/or services, and it's always bound to some legal and financial system the business operates in. Everything beyond that is just marketing and trust building.

The only unique thing in most cases is the data you have and the degree of integration of processes within the business. And neither of those are an actual technology problem or complexity driver.

AWS is extremely expensive for what it offers. It doesn't have to raise prices to be a bad idea, it just has a very large mindshare in the space.

I would say otherwise. Some basic things that come to mind - db snapshots that works - S3 - Cloud Trail - know who and when access a server and what commands they enter in their SSH session. - Session Manager - being able to control permissions in a single place. - S3 + Athena + QuickSight - easy reporting at scale - the list goes on and on

As soon as you have decent amount of data which you care about AWS became dirt cheap compared to on-perm when user right. Look at the list above and imagine how much effort you would have to put on an ongoing basis to support this.

> Sure, you can play FUD games about AWS suddenly raising prices, but I doubt you'd have any historical evidence to back that up. So you'd better be able to say why being cloud-agnostic is critical to your business.

I'm not sure if you're being serious here. It's not about rising prices but making your business completely dependent on another entity and losing any options you might otherwise have.

As for past data, history is rife with stories of companies who made the mistake of trusting a big player their technology will be around forever. So many have invested in technologies like Flash because they were 100% sure they will be there forever.

If I was in charge of AWS, I would avoid sudden price increases, but instead focused on many new features and small charges. These look insignificant, "This is just 20 buck per TB, less than our spending on toilet paper." And then these slowly accumulate and the TCO is getting higher and higher, and again some new* smart features lure you - again, at a small cost. In the end, it turns out you can't leave even if you want.

*Or just your old open source library/framework repainted in AWS colors.

True. But while avoiding vendor lock in is a worthy goal, it does have its costs - as in you are now on the hook for duplicating various functionalities that may not work as well together.

For example, let's take a simple producer/consumer system with some sort of queue. That's an easy enough problem. But add in some additional requirements:

* Data encryption - both in transit/rest * Access control * Audit logs

And it becomes much more complicated. It is a trade off. But the productivity gains available by having a common consistent solutions to issues like this... shouldn't be underestimated.

Trying to utilize all three major US cloud providers with their cloud native tools simultaneously, learning those tools and cutting IT, dev and security from on prem to those, takes a massive staff in a regulated industry.

Doing it "right the first time" in one of the big three, then building a skunk works to replicate efforts as a blackout scenario, seems much more cost effective.

The key term is Total Cost of Ownership. Lockin is a cost. Legacy stacks are a cost. Learning three times the tools are a cost.

Having to pay expensive diy-developers is also a cost (and a huge risk). And if you then need to transfer knowledge and reinvent the wheel for all the NIH-applications you're essentially becoming a cloud, but less complete and not scalable at all.

> Hence you are locked in and have zero negotiating position. Your business has an existential risk based on AWS - assuming your code is critical to the business and could not practically be rewritten because of all this special sauce you’re using.

You don't have a negotiation position based on your ability to switch even if you are huge. AWS pricing negotiations is almost exclusively based on volumes.

Cloud services are competitively priced. I'd honestly like to see some examples of people who invested the time to build cloud agnostic get actual ROE on that in terms of pricing concessions by negotiating with AWS/GCP/Azure over and beyond the additional developer time to build said platform.

Unless you intend to create your own CPU architecture, your own internet and your own human population, by your logic, you are always "locked in". Regarding negotiating positions, those are governed by contracts and by money, the same as with any other company.

There is no real lock-in other than the requirements of your own implementation. A lambda on AWS can just as easily be run on Kubernetes, but that means that on top of running the code that you wanted to run, you now have to run Kubernetes too. You could use a hosted Kubernetes control plane, or fully hosted setup, but according to your same logic you would now be locked in to Kubernetes.

It seems to me that you might have a very special use case, or simply not have had the scaled experience or requirements that made a lot of other vendors non-viable.

Business risk-wise, AWS is a very low risk when compared with pretty much anything else. What do you think will fail first, a custom in-house maintained setup (expensive, non-portable between companies and people) on Digital Ocean, Linode, OVH, Hetzner, etc or all AWS Availability Zones in all AWS Regions world-wide? (and we ignore the lack of IAM, lack of things like RDS, SQS, SNS etc)

Reply on news.ycombinator.com