3 ms·

>Existing applications will work in the cloud. There is no need to use the fancy cloud stuff (multi region, auto scaling...) if it's not needed [or not possible

>Existing applications will work in the cloud. There is no need to use the fancy cloud stuff (multi region, auto scaling...) if it's not needed [or not possible]. I'd like to unpack this. >Existing applications will work in the cloud. They may work, but there's a good chance they will not work well. Doing a direct lift and drop of an application onto AWS can be catastrophic if you don't understand storage persistence, or VM availability. An EC2 VM is not like a physical server in that it will not continue to run indefinitely until something breaks. I would say that existing applications will likely not work well without a shift in the way you treat underlying infrastructure. There are a lot of considerations around IO and locality as well. >There is no need to use the fancy cloud stuff (multi region, auto scaling...) if it's not needed You've just said "There is no need... if it's not needed. >[or not possible] If it is not possible to use the surrounding services your application is probably a poor fit for a cloud platform. It can become prohibitively expensive to try to directly replicate your physical datacenter architecture on a cloud platform. Is it possible to just drop your existing application onto some VMs? Sure, but it's probably a bad idea.

dmourati 10y ago
One commentator put it thus: Legacy: unreliable software on reliable hardware. Cloud: reliable software on unreliable hardware. https://twitter.com/samj/status/25208089148 https://twitter.com/samj/status/25208089148
user5994461 10y ago
> An EC2 VM is not like a physical server in that it will not continue to run indefinitely until something breaks. Sorry to contradict but an EC2 VM does run indefinitely until something breaks ;) There are differences in physical storage between local disks, SAN, NAS, Network Storage, NFS, EBS volumes and Google Volume. A sysadmin should know the characteristics of these, doesn't matter whether it's cloud tech or own tech or homelab tech. People with all this knowledge are rare and expensive, yet critical for major migrations to go well. I can understand that this is an obstacle for major migrations to the cloud (and a benefit for my payroll). > You've just said "There is no need... if it's not needed". I think it's VERY important for legacy migrations. A migration should be done starting with the fundamentals, progressing in stages. All articles and talks focus on shiny bleeding edge stuff, which is only the latest stage(s). Depending on the applications and organization, this stage may or may not be worthwhile, it should or should NOT be a goal in the first place. > If it is not possible to use the surrounding services your application is probably a poor fit for a cloud platform. It can become prohibitively expensive to try to directly replicate your physical datacenter architecture on a cloud platform. I'm talking to clients who have to run their own datacenter right now and want to migrate. It is prohibitively expensive.

dmourati 10y ago

One commentator put it thus: Legacy: unreliable software on reliable hardware. Cloud: reliable software on unreliable hardware. https://twitter.com/samj/status/25208089148 https://twitter.com/samj/status/25208089148

user5994461 10y ago

> An EC2 VM is not like a physical server in that it will not continue to run indefinitely until something breaks. Sorry to contradict but an EC2 VM does run indefinitely until something breaks ;) There are differences in physical storage between local disks, SAN, NAS, Network Storage, NFS, EBS volumes and Google Volume. A sysadmin should know the characteristics of these, doesn't matter whether it's cloud tech or own tech or homelab tech. People with all this knowledge are rare and expensive, yet critical for major migrations to go well. I can understand that this is an obstacle for major migrations to the cloud (and a benefit for my payroll). > You've just said "There is no need... if it's not needed". I think it's VERY important for legacy migrations. A migration should be done starting with the fundamentals, progressing in stages. All articles and talks focus on shiny bleeding edge stuff, which is only the latest stage(s). Depending on the applications and organization, this stage may or may not be worthwhile, it should or should NOT be a goal in the first place. > If it is not possible to use the surrounding services your application is probably a poor fit for a cloud platform. It can become prohibitively expensive to try to directly replicate your physical datacenter architecture on a cloud platform. I'm talking to clients who have to run their own datacenter right now and want to migrate. It is prohibitively expensive.