5 ms·

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

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.
  - sp332 6y ago
    EBS is not "compute-attached". GP means the disks that appear to be local to the instance.
    - jcims 6y ago
      EBS volumes appear local to the machine. [ec2-user@ip-1-1-1-1 ~]$ sudo fdisk -l Disk /dev/xvda: 8 GiB, 8589934592 bytes, 16777216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 0D7E094F-1C63-43F2-AC82-3316E992075B Device Start End Sectors Size Type /dev/xvda1 4096 16777182 16773087 8G Linux filesystem /dev/xvda128 2048 4095 2048 1M BIOS boot Partition table entries are not in disk order.
    - scarface74 6y ago
      I think there is a miscommunication. EBS “appears to be local” but it is actually networked attached storage. Instance storage (is that the correct name?) is where the VM and the storage are on the same physical server and it should be faster.
- jcims 6y ago
  Not the person you are replying too but some industries have regulatory mandates for vendor diversity in cases like this. In addition, when your bills get to millions per month, the provider supplies quite a bit of TAMs and technical resources to your account. This can be helpful, but they also get a good understanding of where you are and are not in a position to dip out if things get sideways in billing. (Also, other providers will throw 6-7 figure credits your way to earn your business, being in a position to leverage them is a good thing.) >Many intricacies like this are annoying, but at the same time advantageous if you know and use them. This is very true. Building services or features that depend upon these is a good idea. Enshrining them deep within your assumptions and requirements about how you operate cloud-based workloads can work against you.
  - scarface74 6y ago
    When your build gets to be “millions per month”, you are already locked in. Any migrations is going to be a painful multi year progress. “Infrastructure has weight”. Have you been part of an integration with a health care system? They are so tightly locked in to their existing EMR/EHR system it would make you cry. Every third party vendor that comes along has to integrate with it. Part of the work I did at the company that I mentioned where I was a dev lead involved migrating our company from Workday. Their entire process was integrated into it.
    - jcims 6y ago
      You're definitely locked in at some level, but if you are able and even demonstrate the ability to swing 30% of your workload over to another provider in a quarter, you're going to maintain some leverage. Yes, have worked in healthcare on and off over the past 20 years and know precisely of what you speak. That's a different situation IMHO, same with ERP/HR/etc.

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.
- sp332 6y ago
  EBS is not "compute-attached". GP means the disks that appear to be local to the instance.
  - jcims 6y ago
    EBS volumes appear local to the machine. [ec2-user@ip-1-1-1-1 ~]$ sudo fdisk -l Disk /dev/xvda: 8 GiB, 8589934592 bytes, 16777216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 0D7E094F-1C63-43F2-AC82-3316E992075B Device Start End Sectors Size Type /dev/xvda1 4096 16777182 16773087 8G Linux filesystem /dev/xvda128 2048 4095 2048 1M BIOS boot Partition table entries are not in disk order.
  - scarface74 6y ago
    I think there is a miscommunication. EBS “appears to be local” but it is actually networked attached storage. Instance storage (is that the correct name?) is where the VM and the storage are on the same physical server and it should be faster.
jcims 6y ago
Not the person you are replying too but some industries have regulatory mandates for vendor diversity in cases like this. In addition, when your bills get to millions per month, the provider supplies quite a bit of TAMs and technical resources to your account. This can be helpful, but they also get a good understanding of where you are and are not in a position to dip out if things get sideways in billing. (Also, other providers will throw 6-7 figure credits your way to earn your business, being in a position to leverage them is a good thing.) >Many intricacies like this are annoying, but at the same time advantageous if you know and use them. This is very true. Building services or features that depend upon these is a good idea. Enshrining them deep within your assumptions and requirements about how you operate cloud-based workloads can work against you.
- scarface74 6y ago
  When your build gets to be “millions per month”, you are already locked in. Any migrations is going to be a painful multi year progress. “Infrastructure has weight”. Have you been part of an integration with a health care system? They are so tightly locked in to their existing EMR/EHR system it would make you cry. Every third party vendor that comes along has to integrate with it. Part of the work I did at the company that I mentioned where I was a dev lead involved migrating our company from Workday. Their entire process was integrated into it.
  - jcims 6y ago
    You're definitely locked in at some level, but if you are able and even demonstrate the ability to swing 30% of your workload over to another provider in a quarter, you're going to maintain some leverage. Yes, have worked in healthcare on and off over the past 20 years and know precisely of what you speak. That's a different situation IMHO, same with ERP/HR/etc.