4 ms·

F/OSS may have also paved the way for today's lock-in into "the cloud."

MaxBarraclough 6y ago
This is a common sentiment but I think it glosses over the upside of cloud computing. Yes, the managed services generally lock you in, but cloud computing has given us cheap and robust VMs in world-class infrastructure. If you want to keep your project portable, you only need to avoid the vendor-specific managed services. As the FSF put it, there is no cloud, just other people's computers. Using someone else's computers doesn't have to mean lock-in.
- ls65536 6y ago
  One way in which I've often thought about it is that whenever you build something on a foundation over which you have no (or little) say or control, then at least work to make it possible to be able to substitute that foundation for an alternative in the future. Or at the very least, be aware of the risks that come with such an arrangement and mitigate them appropriately. Even beyond software or cloud-based tech, this can be useful to think about and apply even more broadly in life, for example when consideing any variety of real or virtual tools, platforms or services that you may depend on.
  - MaxBarraclough 6y ago
    That all sounds sensible. As you say, deliberately committing to lock-in isn't necessarily a mistake. The Amazon Aurora managed database solution looks very impressive, for instance, and I imagine it could make good sense to use it despite the lock-in. In that instance, the service is compatible with MySQL/Postgres, but I imagine it could still be a considerable challenge to move away from it (moving from one high-availability Postgres-based database solution to another). The upsides may outweigh the downsides of lock-in, but the upside needs to be substantial.
    - WrtCdEvrydy 6y ago
      The real lock-in is the IAM on Cloud. Aurora to anything else is fine since you can take a snapshot and move it to another engine easily.
      - MaxBarraclough 6y ago
        I was thinking the worst case would be something like Google Cloud Datastore, a proprietary 'managed-only' database that isn't compatible with any existing product. I think there was an attempt to make a Free and Open Source drop-in replacement, but I don't think it got far.
- baq 6y ago
  generally agree, except the 'cheap'. the top cloud providers offer VMs which are everything but cheap.
  - MaxBarraclough 6y ago
    AWS North Virginia offers t4g.micro instances (AArch64 VMs with 1GB of RAM) for $0.0084 per hour, which works out as just under $74/year. [0] (Not counting data-store cost.) It's backed by highly reliable server-grade hardware, and is connected to the high-speed AWS network. Doesn't that count as cheap? I agree that 'lower tier' providers may be even cheaper, but they still count as cloud computing, so I think my point stands. As a slight off-topic, I've found that the cheaper providers generally offer an inferior product. You can expect to encounter poorly considered features, broken features, or expected features missing entirely. [0] https://aws.amazon.com/ec2/pricing/on-demand/ https://aws.amazon.com/ec2/pricing/on-demand/
    - baq 6y ago
      i'm mostly comparing to low-end on-prem hardware. $74 isn't a lot; but then, it's still much more expensive than something like a raspberry pi 4 with a USB SSD. also, the network isn't that relevant when going this low, since you won't be serving anything substantial out of it. you can get the price lower by using AWS features, but then it isn't 'just a VM' anymore. IMHO getting into the cloud without using any cloud-native features isn't money well spent. you'll be much better off avoiding the VMs as much as possible - which is where your point about on-demand pricing makes sense for elastic workloads.
      - MaxBarraclough 6y ago
        > i'm mostly comparing to low-end on-prem hardware Running your own servers properly is a considerable undertaking. If you're just playing around, that's a different matter. Power-management equipment alone would cost more than what you'd spend on AWS. Even if you somehow got all your hardware for free, the time spent setting up would cost far more than AWS are asking. > $74 isn't a lot; but then, it's still much more expensive than something like a raspberry pi 4 with a USB SSD Serious cloud computing instances are backed by server-grade hardware, with automatic recovery systems to help cope with hardware failures if they do occur, in a dedicated facility with measures in place for everything from burglary to fire to power outages to network outages. The major cloud providers can offer all this for a few pounds/dollars a month due to economies of scale. If it's your intent to just play around, a Raspberry Pi might be a fine choice, but a Raspberry Pi plugged into the wall isn't close to a proper server setup. > the network isn't that relevant when going this low, since you won't be serving anything substantial out of it Firstly, that's not necessarily true. If you're running something like an SFTP/FTPS server, you might make good use of the connection speed, despite only using a lightweight VM. Even if you're hosting a proper Web 2.0 site, an efficient architecture goes a long way. HackerNews and StackOverflow use famously few servers, for instance. Secondly, a lot of ISPs are hostile to web hosting from home connections, so a Raspberry Pi might not be an option even if you're only hosting a 'toy' site. Thirdly, it's not just performance, it's also reliability. AWS invest in redundancy and robustness. A home/small office connection isn't in the same league. > getting into the cloud without using any cloud-native features isn't money well spent If you can get a serious virtual/physical server for a better price elsewhere, that might be worth considering, sure. GitHub does this - they're hosted with a company called Carpathia, rather than with one of the major cloud providers. [0] The 'cloudy features' of a platform like EC2 are powerful though, features like automatic recovery from hardware failure, the ability to easily change the hardware spec of your instance with just a reboot of downtime, the ability to easily transform your virtual HDD into a virtual SSD, etc. [0] https://github.com/holman/ama/issues/553 https://github.com/holman/ama/issues/553
cpach 6y ago
Interesting. How do you mean?

This is a common sentiment but I think it glosses over the upside of cloud computing. Yes, the managed services generally lock you in, but cloud computing has given us cheap and robust VMs in world-class infrastructure. If you want to keep your project portable, you only need to avoid the vendor-specific managed services. As the FSF put it, there is no cloud, just other people's computers. Using someone else's computers doesn't have to mean lock-in.

ls65536 6y ago
One way in which I've often thought about it is that whenever you build something on a foundation over which you have no (or little) say or control, then at least work to make it possible to be able to substitute that foundation for an alternative in the future. Or at the very least, be aware of the risks that come with such an arrangement and mitigate them appropriately. Even beyond software or cloud-based tech, this can be useful to think about and apply even more broadly in life, for example when consideing any variety of real or virtual tools, platforms or services that you may depend on.
- MaxBarraclough 6y ago
  That all sounds sensible. As you say, deliberately committing to lock-in isn't necessarily a mistake. The Amazon Aurora managed database solution looks very impressive, for instance, and I imagine it could make good sense to use it despite the lock-in. In that instance, the service is compatible with MySQL/Postgres, but I imagine it could still be a considerable challenge to move away from it (moving from one high-availability Postgres-based database solution to another). The upsides may outweigh the downsides of lock-in, but the upside needs to be substantial.
  - WrtCdEvrydy 6y ago
    The real lock-in is the IAM on Cloud. Aurora to anything else is fine since you can take a snapshot and move it to another engine easily.
    - MaxBarraclough 6y ago
      I was thinking the worst case would be something like Google Cloud Datastore, a proprietary 'managed-only' database that isn't compatible with any existing product. I think there was an attempt to make a Free and Open Source drop-in replacement, but I don't think it got far.
baq 6y ago
generally agree, except the 'cheap'. the top cloud providers offer VMs which are everything but cheap.
- MaxBarraclough 6y ago
  AWS North Virginia offers t4g.micro instances (AArch64 VMs with 1GB of RAM) for $0.0084 per hour, which works out as just under $74/year. [0] (Not counting data-store cost.) It's backed by highly reliable server-grade hardware, and is connected to the high-speed AWS network. Doesn't that count as cheap? I agree that 'lower tier' providers may be even cheaper, but they still count as cloud computing, so I think my point stands. As a slight off-topic, I've found that the cheaper providers generally offer an inferior product. You can expect to encounter poorly considered features, broken features, or expected features missing entirely. [0] https://aws.amazon.com/ec2/pricing/on-demand/ https://aws.amazon.com/ec2/pricing/on-demand/
  - baq 6y ago
    i'm mostly comparing to low-end on-prem hardware. $74 isn't a lot; but then, it's still much more expensive than something like a raspberry pi 4 with a USB SSD. also, the network isn't that relevant when going this low, since you won't be serving anything substantial out of it. you can get the price lower by using AWS features, but then it isn't 'just a VM' anymore. IMHO getting into the cloud without using any cloud-native features isn't money well spent. you'll be much better off avoiding the VMs as much as possible - which is where your point about on-demand pricing makes sense for elastic workloads.
    - MaxBarraclough 6y ago
      > i'm mostly comparing to low-end on-prem hardware Running your own servers properly is a considerable undertaking. If you're just playing around, that's a different matter. Power-management equipment alone would cost more than what you'd spend on AWS. Even if you somehow got all your hardware for free, the time spent setting up would cost far more than AWS are asking. > $74 isn't a lot; but then, it's still much more expensive than something like a raspberry pi 4 with a USB SSD Serious cloud computing instances are backed by server-grade hardware, with automatic recovery systems to help cope with hardware failures if they do occur, in a dedicated facility with measures in place for everything from burglary to fire to power outages to network outages. The major cloud providers can offer all this for a few pounds/dollars a month due to economies of scale. If it's your intent to just play around, a Raspberry Pi might be a fine choice, but a Raspberry Pi plugged into the wall isn't close to a proper server setup. > the network isn't that relevant when going this low, since you won't be serving anything substantial out of it Firstly, that's not necessarily true. If you're running something like an SFTP/FTPS server, you might make good use of the connection speed, despite only using a lightweight VM. Even if you're hosting a proper Web 2.0 site, an efficient architecture goes a long way. HackerNews and StackOverflow use famously few servers, for instance. Secondly, a lot of ISPs are hostile to web hosting from home connections, so a Raspberry Pi might not be an option even if you're only hosting a 'toy' site. Thirdly, it's not just performance, it's also reliability. AWS invest in redundancy and robustness. A home/small office connection isn't in the same league. > getting into the cloud without using any cloud-native features isn't money well spent If you can get a serious virtual/physical server for a better price elsewhere, that might be worth considering, sure. GitHub does this - they're hosted with a company called Carpathia, rather than with one of the major cloud providers. [0] The 'cloudy features' of a platform like EC2 are powerful though, features like automatic recovery from hardware failure, the ability to easily change the hardware spec of your instance with just a reboot of downtime, the ability to easily transform your virtual HDD into a virtual SSD, etc. [0] https://github.com/holman/ama/issues/553 https://github.com/holman/ama/issues/553

cpach 6y ago

Interesting. How do you mean?