5 ms·

This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/P

by jcims 6y ago

This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/PaaS services. It’s the most direct route vs formalizing a standard but, uglh.

kristianpaul 6y ago
Its not a mystery AWS profit from docker as is call ECS, they even had ecs cli that felt like a poor version of docker's tool. So upstream support in AWS was actually an good move.
scarface74 6y ago
How do you have a “standard” without each provider having to wait on a committee anytime they want any improvements? Even the almighty Terraform which for some reason people still think makes it easy not to experience “cloud lock-in” has cloud specific provisioners.
- mrweasel 6y ago
  I was so disappointed when I learned that I'd been duped in regards to Terraforms abilities. My colleagues had explained that Terraform would allow us to avoid being locked in to own cloud provider, because it's "cloud agnostic" so we could easily move to between Azure, GCP and AWS. Imagine my disappointment when I learned that no actually, Terraform will need to know which type of EC2 instance you want, you need to configure an AWS load balancer, not just "a load balancer". Terraform does NOTHING to help you move between cloud platforms aside from providing a language that will work across providers. You still need to understand how everything ties together and is configured in each platform, now you just can use the examples in the documentation or the newest features.
  - jareware 6y ago
    Either your colleagues were very misinformed, or this was a slight misunderstanding on your part: Terraform IS cloud agnostic, but not in the way you understood. Instead, it allows you to use the same tool and management model for resources on any of the 3 big cloud providers, about a 100 assorted SaaS providers, and most importantly, wire them together (e.g. create a Mailgun configuration, and set up its verification DNS records on AWS), all in code, and in the same workflow.
    - scarface74 6y ago
      I had a (friendly) back and forth with someone from Hashicorp on HN a while back. They are careful not to call Terraform “cloud agnostic” for that reason.
- BjoernKW 6y ago
  In my opinion, being cloud-agnostic is today’s being database-agnostic. In more than two decades of professional software development, I have only once encountered a situation where an existing application was migrated to a different RDBMS instead of just being rewritten. Using an ORM framework for the sake of database independence seems hardly justified in that case. I suppose that things will turn out much the same with cloud agnosticism. Similar to the RDBMS case, being agnostic of the underlying technology prevents you from using that technology’s more interesting features, to the extent that you’re treating a database as a dumb data store or cloud hosting as a mere space for hosting your files.
  - mrgordon 6y ago
    I mostly agree with you but we definitely reduced reliance on AWS specific functionality after starting to offer on-premise software installations. Most of them don’t gain you THAT much and then the software really isn’t very portable.
    - ramraj07 6y ago
      I question this logic - there seem to be fundamental differences in even the basic services between various cloud providers. For example you can resize a compute-attached disk size live in GCP while you can't in AWS. Many intricacies like this are annoying, but at the same time advantageous if you know and use them. If you are primarily trying to just offer another layer on top of these cloud services, (like snowflake) where cross-cloud compatibility is part of your selling point, then it makes sense to abstract the cloud layer. Otherwise, I feel like it's better to choose a reliable vendor and stick to them, optimizing according to their strengths/weaknesses. Or go cross cloud but for very specific technologies (iirc BuzzFeed did this).
      - clappski 6y ago
        You can create/resize/delete non-root EBS volumes without any downtime of the attached host(s), as far as I'm aware? Pretty sure I've done so in the past. You'll have to resize2fs or whatever but it shouldn't take any downtime.

by jcims 6y ago

kristianpaul 6y ago

Its not a mystery AWS profit from docker as is call ECS, they even had ecs cli that felt like a poor version of docker's tool. So upstream support in AWS was actually an good move.

scarface74 6y ago

How do you have a “standard” without each provider having to wait on a committee anytime they want any improvements? Even the almighty Terraform which for some reason people still think makes it easy not to experience “cloud lock-in” has cloud specific provisioners.

mrweasel 6y ago
I was so disappointed when I learned that I'd been duped in regards to Terraforms abilities. My colleagues had explained that Terraform would allow us to avoid being locked in to own cloud provider, because it's "cloud agnostic" so we could easily move to between Azure, GCP and AWS. Imagine my disappointment when I learned that no actually, Terraform will need to know which type of EC2 instance you want, you need to configure an AWS load balancer, not just "a load balancer". Terraform does NOTHING to help you move between cloud platforms aside from providing a language that will work across providers. You still need to understand how everything ties together and is configured in each platform, now you just can use the examples in the documentation or the newest features.
- jareware 6y ago
  Either your colleagues were very misinformed, or this was a slight misunderstanding on your part: Terraform IS cloud agnostic, but not in the way you understood. Instead, it allows you to use the same tool and management model for resources on any of the 3 big cloud providers, about a 100 assorted SaaS providers, and most importantly, wire them together (e.g. create a Mailgun configuration, and set up its verification DNS records on AWS), all in code, and in the same workflow.
  - scarface74 6y ago
    I had a (friendly) back and forth with someone from Hashicorp on HN a while back. They are careful not to call Terraform “cloud agnostic” for that reason.
BjoernKW 6y ago
In my opinion, being cloud-agnostic is today’s being database-agnostic. In more than two decades of professional software development, I have only once encountered a situation where an existing application was migrated to a different RDBMS instead of just being rewritten. Using an ORM framework for the sake of database independence seems hardly justified in that case. I suppose that things will turn out much the same with cloud agnosticism. Similar to the RDBMS case, being agnostic of the underlying technology prevents you from using that technology’s more interesting features, to the extent that you’re treating a database as a dumb data store or cloud hosting as a mere space for hosting your files.
- mrgordon 6y ago
  I mostly agree with you but we definitely reduced reliance on AWS specific functionality after starting to offer on-premise software installations. Most of them don’t gain you THAT much and then the software really isn’t very portable.
  - ramraj07 6y ago
    I question this logic - there seem to be fundamental differences in even the basic services between various cloud providers. For example you can resize a compute-attached disk size live in GCP while you can't in AWS. Many intricacies like this are annoying, but at the same time advantageous if you know and use them. If you are primarily trying to just offer another layer on top of these cloud services, (like snowflake) where cross-cloud compatibility is part of your selling point, then it makes sense to abstract the cloud layer. Otherwise, I feel like it's better to choose a reliable vendor and stick to them, optimizing according to their strengths/weaknesses. Or go cross cloud but for very specific technologies (iirc BuzzFeed did this).
    - clappski 6y ago
      You can create/resize/delete non-root EBS volumes without any downtime of the attached host(s), as far as I'm aware? Pretty sure I've done so in the past. You'll have to resize2fs or whatever but it shouldn't take any downtime.