6 ms·

Infrastructure as code can work on any cloud provider including smaller ones like Digital Ocean, Linode, OVH, Hetzner, etc which are mentioned in the article.

Infrastructure as code can work on any cloud provider including smaller ones like Digital Ocean, Linode, OVH, Hetzner, etc which are mentioned in the article. A lot of the things you said apply just as much to them as to AWS. In my opinion using AWS is fine, as long as you use cloud agnostic stuff and avoid AWS specific services. That way if you ever have to switch, you just have to rewrite the provisioning part of your infra-as-code, everything else can be easily migrated over with some config changes.

oneplane 4y 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. 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 4y 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 4y 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 4y 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 4y 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 4y 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.
- dijksterhuis 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
cube2222 4y ago
> as long as you use cloud agnostic stuff and avoid AWS specific services That is a big tradeoff, and it's not something obvious. If being banned from AWS is an important and relatively big risk for your business, sure, go for it. But if not, then those AWS-specific services are exactly where you get all those productivity gains from, and where AWS (and GCP for that matter) shines in comparison to smaller ones, like DO or Linode, or on-premises.
mywittyname 4y ago
Developer skill sets vary a lot. I know my way around linux, but I'm no system administrator. So there's a good chance that I'll do something wrong if I built products using pure EC2. Also, frankly, I hate dealing with system administration stuff. I'll take a more expensive Aurora instance over a self-managed MySQL cluster any day of the week. I'm sure there are tons of developers out there who know a lot about infrastructure and system administration. For those people, it might be worth spending time managing infra, but my time is absolutely better spent using a turn key solution and focusing on product development. For smaller teams, getting feature-rich products out the door can be more important than building the most cost-optimal product. Bigger teams can afford dedicated staff to optimize infra.
hnlmorg 4y ago
The real benefit of the cloud is their SaaS offerings. If you go cloud agnostic you create more on going maintenance overhead (since you now have to manage services), higher hosting costs and you still have to rewrite most of your IaC when switching clouds anyway. Contrary to common belief, IaC platforms like Terraform doesn't mean the same code works across different clouds. It just means the same language can be used to provision services. However how you define services in that language will differ from one cloud to another even if the types of services are the same. So unless you're going multi-cloud from day one, it's much better to write your services to be specific to the cloud you're using and benefit from them rather than boycotting them because of a theoretical decision of multi-cloud that you might never actually make. Most companies that talk about going multi-cloud never actually do because the benefits of being multi-cloud are actually pretty small for most domains. Being multi-cloud is one of those things that sounds more important than it actually is.
redredrobot 4y ago
> using AWS is fine, as long as you use cloud agnostic stuff and avoid AWS specific services IMO this is exactly when you should not be using AWS. AWS is a premium offering and you can find cheaper alternatives for the commoditized offerings like EC2, RDS (the older, non-AWS-specific features) and (maybe) S3. It's the high-level services where the real value is in AWS - the cutting edge technologies that only exist in a specific cloud (or multiple clouds but where it's difficult to port across clouds due to subtle differences). This is where the extremely high development cost is able to be amortized over many customers, allowing you to get scalable, easy-to-use, and easy-to-operate services at a much lower cost than would be possible outside of that cloud. A great example of that for AWS is Serverless Aurora.
rsanek 4y ago
> using AWS is fine, as long as you use cloud agnostic stuff and avoid AWS specific services This is the worst of both worlds. You get the expense of AWS but without any of the things that would make the cost worth it. IMO you should either avoid using their services and move to something way cheaper (OVH, as the article mentions Hetzner), or fully buy into the benefits AWS has to offer.
mr_toad 4y ago
> Infrastructure as code can work on any cloud provider including smaller ones like Digital Ocean, Linode, OVH, Hetzner, etc which are mentioned in the article. Back in the ‘old days’ of the cloud you’d hear a lot of talk about “commodity computing”. Compute was fungible. No salespeople, no politics. It was a utopian environment for developers. But in the decade and a half since, the landscape has changed. Now cloud is infested with salespeople, consultants, and worst of all, third-party solutions. It’s the same old hodgepodge of half-finished incompatible products tossed over the wall that on-prem used to be, only more expensive.
Communitivity 4y ago
I think it's all about what features you are using, and how much you want to BYOC (Bring Your Own Code). Infrastructure as code is something you can do on smaller deployment environments as well, even in air-gapped environments. The benefit of AWS, for me, is the reliability and all the capabilities that work out of the box that aren't differentiators for my solution (so it's great that I can offload them to someone else, if security, etc. allows). I agree that it's a good idea to have a layer of abstraction so you can use other service providers, even though you may take a bit of a performance hit for doing so.

oneplane 4y 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. 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 4y 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 4y 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 4y 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 4y 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 4y 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.
dijksterhuis 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.

cube2222 4y ago

> as long as you use cloud agnostic stuff and avoid AWS specific services That is a big tradeoff, and it's not something obvious. If being banned from AWS is an important and relatively big risk for your business, sure, go for it. But if not, then those AWS-specific services are exactly where you get all those productivity gains from, and where AWS (and GCP for that matter) shines in comparison to smaller ones, like DO or Linode, or on-premises.

mywittyname 4y ago

Developer skill sets vary a lot. I know my way around linux, but I'm no system administrator. So there's a good chance that I'll do something wrong if I built products using pure EC2. Also, frankly, I hate dealing with system administration stuff. I'll take a more expensive Aurora instance over a self-managed MySQL cluster any day of the week. I'm sure there are tons of developers out there who know a lot about infrastructure and system administration. For those people, it might be worth spending time managing infra, but my time is absolutely better spent using a turn key solution and focusing on product development. For smaller teams, getting feature-rich products out the door can be more important than building the most cost-optimal product. Bigger teams can afford dedicated staff to optimize infra.

hnlmorg 4y ago

The real benefit of the cloud is their SaaS offerings. If you go cloud agnostic you create more on going maintenance overhead (since you now have to manage services), higher hosting costs and you still have to rewrite most of your IaC when switching clouds anyway. Contrary to common belief, IaC platforms like Terraform doesn't mean the same code works across different clouds. It just means the same language can be used to provision services. However how you define services in that language will differ from one cloud to another even if the types of services are the same. So unless you're going multi-cloud from day one, it's much better to write your services to be specific to the cloud you're using and benefit from them rather than boycotting them because of a theoretical decision of multi-cloud that you might never actually make. Most companies that talk about going multi-cloud never actually do because the benefits of being multi-cloud are actually pretty small for most domains. Being multi-cloud is one of those things that sounds more important than it actually is.

redredrobot 4y ago

> using AWS is fine, as long as you use cloud agnostic stuff and avoid AWS specific services IMO this is exactly when you should not be using AWS. AWS is a premium offering and you can find cheaper alternatives for the commoditized offerings like EC2, RDS (the older, non-AWS-specific features) and (maybe) S3. It's the high-level services where the real value is in AWS - the cutting edge technologies that only exist in a specific cloud (or multiple clouds but where it's difficult to port across clouds due to subtle differences). This is where the extremely high development cost is able to be amortized over many customers, allowing you to get scalable, easy-to-use, and easy-to-operate services at a much lower cost than would be possible outside of that cloud. A great example of that for AWS is Serverless Aurora.

rsanek 4y ago

> using AWS is fine, as long as you use cloud agnostic stuff and avoid AWS specific services This is the worst of both worlds. You get the expense of AWS but without any of the things that would make the cost worth it. IMO you should either avoid using their services and move to something way cheaper (OVH, as the article mentions Hetzner), or fully buy into the benefits AWS has to offer.

mr_toad 4y ago

> Infrastructure as code can work on any cloud provider including smaller ones like Digital Ocean, Linode, OVH, Hetzner, etc which are mentioned in the article. Back in the ‘old days’ of the cloud you’d hear a lot of talk about “commodity computing”. Compute was fungible. No salespeople, no politics. It was a utopian environment for developers. But in the decade and a half since, the landscape has changed. Now cloud is infested with salespeople, consultants, and worst of all, third-party solutions. It’s the same old hodgepodge of half-finished incompatible products tossed over the wall that on-prem used to be, only more expensive.

Communitivity 4y ago

I think it's all about what features you are using, and how much you want to BYOC (Bring Your Own Code). Infrastructure as code is something you can do on smaller deployment environments as well, even in air-gapped environments. The benefit of AWS, for me, is the reliability and all the capabilities that work out of the box that aren't differentiators for my solution (so it's great that I can offload them to someone else, if security, etc. allows). I agree that it's a good idea to have a layer of abstraction so you can use other service providers, even though you may take a bit of a performance hit for doing so.