3 ms·

Yes I would, there are some cases where the featureset is better. Also, it really is just a few lines of code. If you separate out IAC-code and configuration co

Yes I would, there are some cases where the featureset is better. Also, it really is just a few lines of code. If you separate out IAC-code and configuration code even if you are running through say a jenkins pipeline it's not much trouble to change a few .tf files around to get the same result on a different provider... You act like writing terraform is hard or convoluted and I don't understand where you are coming from on that. https://github.com/terraform-providers https://github.com/terraform-providers

toiletduck 7y ago
Writing Terraform is easy - having it work after six month of features being delivered, the cloud provider evolving, and working with all your other microservices, isn't particularly. Assuming you can do that and just change a few lines to redeploy in a new cloud environment (imagine that including GKE to EKS) seems naive.
- scarface74 7y ago
  On another note, in the list of top ten things that will add business value and either make the company money or save the company money where does “being cloud agnostic rate”? What competent CTO would go through a migration from one provider to another on a whim? The chance of regression and business interruption is too high and the benefits too low to make it worth it if you’re at any type of scale.
  - solidasparagus 7y ago
    At a certain scale, being cloud agnostic is actually very financially beneficial. The negotiating leverage leads to substantially better private pricing deals with your cloud provider.
    - scarface74 7y ago
      At a certain scale are you really going to move your entire infrastructure over to another provider? The time, migration cost, and business risks are usually not worth it. The time you’re spending migrating, testing, validating for correctness and often compliance is time you’re not spending on creating business value. On top of that, you’ve migrated all of the practices from being at a colo without any of the time to market , lower headcount, and flexibility or availability that you get from using native cloud services. You’re investing time and not taking into account any of the opportunity cost. Businesses are so dependent on vendors these days - from payroll, to Office Suites, to database vendors, to even their physical facilities it’s silly to optimize for one part of your infrastructure at the expense of other opportunities in the rare case that you might change vendors. Do you also have a migration plan for all of your other dependencies? Are all of your documents in an open source format? What about your project management system? Your AD? Your device management system? Are all your desktops running Linux? Are you using Microsoft Exchange? What are you using for time tracking? Expense reimbursement? SSO? Alerting and monitoring?
      - solidasparagus 7y ago
        When your cloud costs reach the high hundreds of millions to billions of dollars per year, it is worth it. At that point you probably want to run your infrastructure across cloud providers anyway.
        scarface74 7y ago
        At that point, you’re going to need the in house expertise anyway and you would probably be better off managing your own data center. Even if you are “cloud agnostic”, at that size just your networking infrastructure, compliance, auditing, and data migration is going to cost a boatload of money and it would take years to save enough to make the migration worth it. Not to mention the retraining and risks that come from the migration. You probably also have a few direct connections to the cloud provider.
    - toiletduck 7y ago
      Cloud agnostic in terms of using the best products from each service: sure. It makes sense to leverage the strengths of each cloud provider. Having all your infra written with shim layers to move it freely between providers sounds like the scale you need to start thinking about hosting your own "cloud provider" or stop using public cloud.
scarface74 7y ago
Do you get the cross AZ redundancy? and you’re managing more servers and probably spending more than just using an ELB. What about the HA from the target servers? If you were using a load balancer + autoscaling group with a min/max of 2. If your server went down or your entire AZ went down, autoscaling would bring another one up. If the server or AZ went down running your load balancer, it would also be redundant? One of our web servers crashed in the middle of the night once. I got an alert saying it crashed and that another one was brought up. I turned over, went back to sleep and investigated the next morning. If the “server” running an ELB crashed, I wouldn’t have to care. Do you really think that you’re going to be changing providers Willy nilly once you reach any type of scale? It’s just like all of the bushy tailed “architects” who use the repository pattern just in case one day their CTO on a whim decides to move their six figure a year Oracle installation to Postgres. What business value is being added by going through all of the trouble of staying “cloud agnostic” compared to the lack of HA and maintenance. Btw, we also don’t have to manage Jenkins servers. We have a cloud formation template with parameters and quick create link that a developer can click on to create a CodeBuild project anytime they want to create a new build project. They specify the Github link that triggers the job. You then specify your build steps as a list of bash (Linux) or Powershell (Windows) commands in a yaml file. We could also do the same with CodePipeline - create a CF template that creates Code Pipeline jobs on the fly, but we do use OctopusDeploy for deployments. CodeBuild runs Docker containers to run builds. Again no servers to manage but I believe by default it can run 50 builds simultaneously. If a build job needs custom tooling or a custom version of a runtime, the developer can build a custom Docker container to run the build. You’re doing more work just in the eventuality that you may want to rip out your entire infrastructure and you’re paying more for the privilege.
- arminiusreturns 7y ago
  You've obviously fully bought into AWS and don't want to hear anything to the contrary. That's fine if it works for you, but you aren't interested in honest conversation, so I'm done here.
  - scarface74 7y ago
    It’s not about “fully buying into AWS”. I would say the same about Azure or GCP - well not GCP I wouldn’t trust Google for any infrastructure. If you have a static workload and the staff to handle infrastructure, AWS may not be worth it. Use a colo or a cheaper service like Linode. Everything I use managed services for I’ve done on prem. I’m saying that it is just as much a waste of money and time to use any cloud provider just to duplicate what you could do at a colo. I would say the same thing about spending extra money for Oracle or SQL Server. Why spend extra on a commercial solution and not take advantage of it. You wouldn’t use Excel just to create CSV files.

toiletduck 7y ago

Writing Terraform is easy - having it work after six month of features being delivered, the cloud provider evolving, and working with all your other microservices, isn't particularly. Assuming you can do that and just change a few lines to redeploy in a new cloud environment (imagine that including GKE to EKS) seems naive.

scarface74 7y ago
On another note, in the list of top ten things that will add business value and either make the company money or save the company money where does “being cloud agnostic rate”? What competent CTO would go through a migration from one provider to another on a whim? The chance of regression and business interruption is too high and the benefits too low to make it worth it if you’re at any type of scale.
- solidasparagus 7y ago
  At a certain scale, being cloud agnostic is actually very financially beneficial. The negotiating leverage leads to substantially better private pricing deals with your cloud provider.
  - scarface74 7y ago
    At a certain scale are you really going to move your entire infrastructure over to another provider? The time, migration cost, and business risks are usually not worth it. The time you’re spending migrating, testing, validating for correctness and often compliance is time you’re not spending on creating business value. On top of that, you’ve migrated all of the practices from being at a colo without any of the time to market , lower headcount, and flexibility or availability that you get from using native cloud services. You’re investing time and not taking into account any of the opportunity cost. Businesses are so dependent on vendors these days - from payroll, to Office Suites, to database vendors, to even their physical facilities it’s silly to optimize for one part of your infrastructure at the expense of other opportunities in the rare case that you might change vendors. Do you also have a migration plan for all of your other dependencies? Are all of your documents in an open source format? What about your project management system? Your AD? Your device management system? Are all your desktops running Linux? Are you using Microsoft Exchange? What are you using for time tracking? Expense reimbursement? SSO? Alerting and monitoring?
    - solidasparagus 7y ago
      When your cloud costs reach the high hundreds of millions to billions of dollars per year, it is worth it. At that point you probably want to run your infrastructure across cloud providers anyway.
      - scarface74 7y ago
        At that point, you’re going to need the in house expertise anyway and you would probably be better off managing your own data center. Even if you are “cloud agnostic”, at that size just your networking infrastructure, compliance, auditing, and data migration is going to cost a boatload of money and it would take years to save enough to make the migration worth it. Not to mention the retraining and risks that come from the migration. You probably also have a few direct connections to the cloud provider.
  - toiletduck 7y ago
    Cloud agnostic in terms of using the best products from each service: sure. It makes sense to leverage the strengths of each cloud provider. Having all your infra written with shim layers to move it freely between providers sounds like the scale you need to start thinking about hosting your own "cloud provider" or stop using public cloud.

scarface74 7y ago

Do you get the cross AZ redundancy? and you’re managing more servers and probably spending more than just using an ELB. What about the HA from the target servers? If you were using a load balancer + autoscaling group with a min/max of 2. If your server went down or your entire AZ went down, autoscaling would bring another one up. If the server or AZ went down running your load balancer, it would also be redundant? One of our web servers crashed in the middle of the night once. I got an alert saying it crashed and that another one was brought up. I turned over, went back to sleep and investigated the next morning. If the “server” running an ELB crashed, I wouldn’t have to care. Do you really think that you’re going to be changing providers Willy nilly once you reach any type of scale? It’s just like all of the bushy tailed “architects” who use the repository pattern just in case one day their CTO on a whim decides to move their six figure a year Oracle installation to Postgres. What business value is being added by going through all of the trouble of staying “cloud agnostic” compared to the lack of HA and maintenance. Btw, we also don’t have to manage Jenkins servers. We have a cloud formation template with parameters and quick create link that a developer can click on to create a CodeBuild project anytime they want to create a new build project. They specify the Github link that triggers the job. You then specify your build steps as a list of bash (Linux) or Powershell (Windows) commands in a yaml file. We could also do the same with CodePipeline - create a CF template that creates Code Pipeline jobs on the fly, but we do use OctopusDeploy for deployments. CodeBuild runs Docker containers to run builds. Again no servers to manage but I believe by default it can run 50 builds simultaneously. If a build job needs custom tooling or a custom version of a runtime, the developer can build a custom Docker container to run the build. You’re doing more work just in the eventuality that you may want to rip out your entire infrastructure and you’re paying more for the privilege.

arminiusreturns 7y ago
You've obviously fully bought into AWS and don't want to hear anything to the contrary. That's fine if it works for you, but you aren't interested in honest conversation, so I'm done here.
- scarface74 7y ago
  It’s not about “fully buying into AWS”. I would say the same about Azure or GCP - well not GCP I wouldn’t trust Google for any infrastructure. If you have a static workload and the staff to handle infrastructure, AWS may not be worth it. Use a colo or a cheaper service like Linode. Everything I use managed services for I’ve done on prem. I’m saying that it is just as much a waste of money and time to use any cloud provider just to duplicate what you could do at a colo. I would say the same thing about spending extra money for Oracle or SQL Server. Why spend extra on a commercial solution and not take advantage of it. You wouldn’t use Excel just to create CSV files.