5 ms·

If you are not using cloud native features you are essentially just using a virtual datacenter at which point AWS is an expensive choice. On the other hand, if

If you are not using cloud native features you are essentially just using a virtual datacenter at which point AWS is an expensive choice. 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. This is also why being 'on the cloud' and 'cloud native' is very different. While the latter is a bit too buzzwordy for my taste, it does show the difference between "playing datacenter" and "getting stuff done in new ways, both cheaper and faster". Do not use AWS if you just run a few virtual machines and some basic networking. That also applies to GCP and Azure. It's too expensive for what you need, and too easy to misconfigure and shoot yourself in the foot. On the other hand, if you need API-driven infrastructure with a large gradient between IaaS and SaaS to pick from, then by all means, use AWS.

zarzavat 5y ago
> 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.
- jbmsf 5y ago
  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.
  - zarzavat 5y ago
    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.
    - oneplane 5y ago
      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...
      - invalidname 5y ago
        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.
        codyswann 5y ago
        What type of usage volume are we talking about here?
        happymellon 5y ago
- sharpy 5y ago
  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.
- unethical_ban 5y ago
  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.
  - oneplane 5y ago
    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.
- oneplane 5y ago
  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)
- andag 5y ago
  > 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.
- datatrashfire 5y ago
  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.
dijksterhuis 5y ago
I wrote a big reply to the below quote from you, and then realised were were probably arguing the same point. > Do not use AWS if you just run a few virtual machines and some basic networking. That also applies to GCP and Azure. It's too expensive for what you need. Currently on a contract where I've saved them 6 months of my costs over 3 weeks of part-time development on a single year long project. They saved half of my entire contract on their first foray into AWS compared to Digital Ocean charges. When you know what you're doing AWS can become very cost-effective. Build it with $PLATFORM in mind and all sorts of savings are possible. But the tricky part is whether the team is ready for it, or whether they'll spend more time learning the ropes than the company saves over $NUMBER years. Which I think is what you were getting at?
hackerfromthefu 5y ago
I recommend using descriptive names rather than marketing ones. Proper naming helps you understand and think about things accurately to remove psychological bias/koolaid. Another term which is more descriptive for cloud native is vendor cloud lock-in, which could be reasonably but descriptively shortened to cloud-locked or cloud-married maybe. Native sounds cool but completely loses sight of the cost of lock-in, while locked or married talks to both the benefits and the costs.
- KyeRussell 5y ago
  Vendor lock in is an attribute, or effect, which is not the same as “another term”. You can’t start an argument about semantics only to bend this language so drastically.
- oneplane 5y ago
  Your semantics are misguided at best and malicious at first hand. FaaS is cloud-native, but is a mere abstract context a lock-in? If so, what is the point of ascribing lock-ins at all at that point? Cloud-native isn’t vendor-owned, at best it could be trademarked at the CNCF but that’s not a vendor.
AtlasBarfed 5y ago
"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." If you use those, AWS starts rubbing its hands together and cackling in an evil laugh. I bet they even have an mp3 that plays whenever a major player uses a lock-in api product on AWS. "aws lambda install blah blah" < I obviously don't know the api Somewhere in Seattle: Mwahahahahahaha! Bwahahahahahah! Kwahahahahah! Although RDS is just hosted SQL databases. It isn't a pure lock-in. Identity management, key management, firewalls, and networking all exist in some form at most places. And don't underestimate how bad internal "clouds" are in large enterprises. AWS pure EC2 can still be a huge win, especially if that is the only one that has been "expertly" vetted or negotiated by some lofty level of management on a golf course somewhere.
rstuart4133 5y ago
> 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. I use AWS, but I suspect I'm a fair bit older than you. Those things you say "you can't come close" - they exist elsewhere. There are just software libraries. It's the reverse of "can't come close" - there is a plethora of implementations to choose from, and most are free. Lambdas is just CGI on steroids, RDS is just a database, IAM is just one of any number of authentication / authorisation platforms the most notable one being kerberos which is literally decades old. It's true that AWS's versions of these libraries all play nicely together, whereas the others are going to require more glue. But on the other hand AWS nickel and dimes you on every use. The price of writing the glue can be high and has to be incurred up front, whereas the price of the nickel and dimes - that's a future self problem. Just like smoking and crack. Not unsurprisingly the cloud vendors use the same tricks as the smoking and crack vendors too - they give away their delights for free to early users by handing out free credits like candy, knowing once you're locked in as a heavy user there is no way to avoid paying the piper. The price difference in my experience is typically of the order of an an extra 0. That's not a big deal with your primary costs aren't CPU cycles but rather developer time. That's absolutely the case at the start of an enterprises life, and it seems to remain true for many enterprises for their entire existence. So perhaps AWS works out for many. But personally, I would not take it for my business. There are lots of implementations of all the things you mention, and much more besides out there. Worse, many of AWS's products seem to exist to solve problems created by using other AWS products. Need to monitor you SES reputation? Don't record it yourself - send it to CloudWatch! It's only a small cost. Oh you need to get it to CloudWatch - use SNS - it's only a small cost. Oh you want to trigger stuff from CloudWatch - just use Lambda - it's only a small cost. Oh, you need to control access to all those things - use IAM. Maybe it's true it's all only a small cost - but it a very complex solution compared to parsing you SMTP server logs and writing them to a open source database, which is all that is happening under the hood. At times it seems the only reason AWS structures things in the way they do is to induce you into buying more AWS services. Which is why things like TerraForm exist. Some are happier to where the cost incur the expense of gluing together the many free alternatives out there, in return for the ability to roll it out to the lowest cost provider out there.

zarzavat 5y ago

> 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.

jbmsf 5y ago
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.
- zarzavat 5y ago
  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.
  - oneplane 5y ago
    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...
    - invalidname 5y ago
      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.
      - codyswann 5y ago
        What type of usage volume are we talking about here?
      - happymellon 5y ago
sharpy 5y ago
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.
unethical_ban 5y ago
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.
- oneplane 5y ago
  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.
oneplane 5y ago
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)
andag 5y ago
> 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.
datatrashfire 5y ago
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.

dijksterhuis 5y ago

I wrote a big reply to the below quote from you, and then realised were were probably arguing the same point. > Do not use AWS if you just run a few virtual machines and some basic networking. That also applies to GCP and Azure. It's too expensive for what you need. Currently on a contract where I've saved them 6 months of my costs over 3 weeks of part-time development on a single year long project. They saved half of my entire contract on their first foray into AWS compared to Digital Ocean charges. When you know what you're doing AWS can become very cost-effective. Build it with $PLATFORM in mind and all sorts of savings are possible. But the tricky part is whether the team is ready for it, or whether they'll spend more time learning the ropes than the company saves over $NUMBER years. Which I think is what you were getting at?

hackerfromthefu 5y ago

I recommend using descriptive names rather than marketing ones. Proper naming helps you understand and think about things accurately to remove psychological bias/koolaid. Another term which is more descriptive for cloud native is vendor cloud lock-in, which could be reasonably but descriptively shortened to cloud-locked or cloud-married maybe. Native sounds cool but completely loses sight of the cost of lock-in, while locked or married talks to both the benefits and the costs.

KyeRussell 5y ago
Vendor lock in is an attribute, or effect, which is not the same as “another term”. You can’t start an argument about semantics only to bend this language so drastically.
oneplane 5y ago
Your semantics are misguided at best and malicious at first hand. FaaS is cloud-native, but is a mere abstract context a lock-in? If so, what is the point of ascribing lock-ins at all at that point? Cloud-native isn’t vendor-owned, at best it could be trademarked at the CNCF but that’s not a vendor.

AtlasBarfed 5y ago

"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." If you use those, AWS starts rubbing its hands together and cackling in an evil laugh. I bet they even have an mp3 that plays whenever a major player uses a lock-in api product on AWS. "aws lambda install blah blah" < I obviously don't know the api Somewhere in Seattle: Mwahahahahahaha! Bwahahahahahah! Kwahahahahah! Although RDS is just hosted SQL databases. It isn't a pure lock-in. Identity management, key management, firewalls, and networking all exist in some form at most places. And don't underestimate how bad internal "clouds" are in large enterprises. AWS pure EC2 can still be a huge win, especially if that is the only one that has been "expertly" vetted or negotiated by some lofty level of management on a golf course somewhere.

rstuart4133 5y ago

> 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. I use AWS, but I suspect I'm a fair bit older than you. Those things you say "you can't come close" - they exist elsewhere. There are just software libraries. It's the reverse of "can't come close" - there is a plethora of implementations to choose from, and most are free. Lambdas is just CGI on steroids, RDS is just a database, IAM is just one of any number of authentication / authorisation platforms the most notable one being kerberos which is literally decades old. It's true that AWS's versions of these libraries all play nicely together, whereas the others are going to require more glue. But on the other hand AWS nickel and dimes you on every use. The price of writing the glue can be high and has to be incurred up front, whereas the price of the nickel and dimes - that's a future self problem. Just like smoking and crack. Not unsurprisingly the cloud vendors use the same tricks as the smoking and crack vendors too - they give away their delights for free to early users by handing out free credits like candy, knowing once you're locked in as a heavy user there is no way to avoid paying the piper. The price difference in my experience is typically of the order of an an extra 0. That's not a big deal with your primary costs aren't CPU cycles but rather developer time. That's absolutely the case at the start of an enterprises life, and it seems to remain true for many enterprises for their entire existence. So perhaps AWS works out for many. But personally, I would not take it for my business. There are lots of implementations of all the things you mention, and much more besides out there. Worse, many of AWS's products seem to exist to solve problems created by using other AWS products. Need to monitor you SES reputation? Don't record it yourself - send it to CloudWatch! It's only a small cost. Oh you need to get it to CloudWatch - use SNS - it's only a small cost. Oh you want to trigger stuff from CloudWatch - just use Lambda - it's only a small cost. Oh, you need to control access to all those things - use IAM. Maybe it's true it's all only a small cost - but it a very complex solution compared to parsing you SMTP server logs and writing them to a open source database, which is all that is happening under the hood. At times it seems the only reason AWS structures things in the way they do is to induce you into buying more AWS services. Which is why things like TerraForm exist. Some are happier to where the cost incur the expense of gluing together the many free alternatives out there, in return for the ability to roll it out to the lowest cost provider out there.