3 ms·

Yup. The way cloud sales works makes it seem almost impossible to justify restructuring your infrastructure to your management. It's a genius sales strategy.

• yipbub 7y ago
  Can you explain how that works please?
  • carlio 7y ago
    The short version is lockin. Unless you get very careful ops engineers making it truly cloud-agnostic, you can't even move from AWS to GCP without a huge amount of overhead. I'm a contractor and several of the companies I've worked with recently have almost hard-coded their services to expect certain things available to them on GCP or AWS that aren't as easily available on the other. You can argue that they should use 12facter and real DevOps and portability and so on but that's just not what people are actually doing so they've locked themselves in and for companies that are struggling to pay their hosting bill already, saying "We need 3 months of 6 developers' time to move" isn't going to go down well.
    • scarface74 7y ago
      No matter how careful you are to avoid lock-in, infrastructure has weight. You have data, network infrastructure, security audits, IAM permissions, Infrastructure as code (no Terraform is not a magic bullet), training, DNS entries etc. I wonder how many people who think they have a large “cloud agnostic” infrastructure have actually sat down with project managers and come up with a project plan and cost analysis of a large migration. I have witnessed how much it costs to do just a Workday migration.
    • cachestash 7y ago
      This is why we choose to sit everything on top of OpenShift, we get Red Hat support 24/7 to run it and if we needed to migrate to a different provider its far less painful as OpenShift abtracts the cloud providers API's away from us. The only real changes we need to make our admin based. Technical changes are very minimal.
      • ablekh 7y ago
        OpenShift costs quite a bit. Have you compared, costs- and ROI-wise, the OpenShift approach with an alternative of having a small team of consultants (or internal team, if available) architect your platform in a cloud-agnostic way, based on vanilla K8s, plus required additional OSS packages?
  • einpoklum 7y ago
    To paraphrase the "sibling" post: If you've invested the effort and personnel in being able to move from some cloud provider to some other cluster/cloud solution, it probably already makes sense to just get your own servers and move yourself there, since you're basically capable of doing that (and your costs will be cut by a large factor).
• grey-area 7y ago
  It's pretty easy to cut down clusters to the minimum number of nodes for them to function (say cutting 10 servers to 2), or downgrade the size of instances to compensate for lower traffic. There's no need to restructure infrastructure in most cases, if anything using a cloud provider makes this easier.
  • icedchai 7y ago
    It's "easy" to do this, but it's also just as "easy" for your service to fall over when you do it wrong. Capacity planning and performance engineering is a lost art in a world where you would simply throw money at the problem until it went away.
    • grey-area 7y ago
      It's not that hard (I've done this recently for clients). If your traffic is 90% of normal for a few months, scaling down with load makes a lot of sense, then you can scale back up when ready. There are also autoscaling solutions like serverless.
      • icedchai 7y ago
        This is true for simple services. It's different when you're dealing with something like a Cassandra or Elasticsearch cluster, where the system isn't stateless and scaling up takes some time for re-balancing.
        • grey-area 7y ago
          Sure, it won't apply to all services, particularly datastores are best left alone, but if you need a quite few web workers say which sit in front of your search or db to service millions of users, and can cut that in half during low traffic times, you may save significant money, as the user pram above has noted.
  • Horba 7y ago
    Aren't you making gp's point for him?