5 ms·

>A smart company will do a cost-benefit analysis, not blindly go to the cloud But often times those cost-benefit analysis don't take into account how quickly y

by matlock 13y ago

>A smart company will do a cost-benefit analysis, not blindly go to the cloud But often times those cost-benefit analysis don't take into account how quickly you can improve and work on your infrastructure. The performance or cost improvements need to be a lot to slow down your team even a bit. Especially for startups this can hit them very hard.

druiid 13y ago
Not sure that this would really change the analysis that much. If you were buying physical servers and installing them yourself then sure, this could very well (perhaps even will) cause slowdown. Most everyone that does bring up using physical hardware for start-ups on here instead discuss leasing managed dedicated servers. You can just as easily spin instances on those up/down as needed, and many of the solution providers out there will even have Openstack/VMWare/etc. available pre-installed so you don't have to do any of that legwork. I think engineering for 'The Cloud' can be just as time consuming if not more so for start-ups. For Amazon at least you have to engineer for failure. With a dedicated server configuration you still do need to engineer for that, but you aren't worrying about if depending on the solution providers block storage is going to take certain aspects of your architecture offline when it goes down (yet again), or if the portal won't allow you to bring up/down new instances during a very critical period of time, etc.
- Spooky23 13y ago
  It's a risk shift. Generally speaking, most sysadmins at small places do a horrible job engineering for failure. Or, worse, they don't have professional SA's, just devs who know enough to be dangerous. So while you don't run into a US-East EBS failure every now and again that affects millions of servers, you are subject to random unforseen failures because somebody didn't do X correctly. (Where X could include: disk configuration, HA configuration, DR plan, backup/restore plan, os management, firewall management, etc) There's no one right answer here. I've rolled specific hardware solutions managed by a single team for certain applications, and everything was fine. I've been stuck working within the bounds of a managed services provider, and things worked too. Cloud is just another model. EC2 lets you roll a globally distributed solution with good tooling for low cost.
  - matlock 13y ago
    >EC2 lets you roll a globally distributed solution with good tooling for low cost This is the Crux. There are other options available, but going cloud makes it very easy to roll out something big without the necessity to have experts in all the lower level parts of your infrastructure. It lets you focus and the price for that is absolutely reasonable
  - druiid 13y ago
    I fully agree on the SA stuff. Sadly more often than not it's some dev who knows enough to be really dangerous. I make a good amount of money by coming in and mopping up after those kinds of scenarios (sadly... I'd rather make less money up-front by helping in the planning phase). I will say however that while yes, it's a risk shift you can still have and will have plenty of those risks that are shifted to the cloud still unaccounted for. For instance, backups. Just because your servers are now on 'the cloud' does not mean they're immune from losing all of their data if the instance dies, especially on EC2. On EC2 it's generally just a 'whoops, bye!' scenario. At least with Rackspace cloud it might be a 'whoops, restore from a VM image snapshot from last week'.

by matlock 13y ago

druiid 13y ago

Not sure that this would really change the analysis that much. If you were buying physical servers and installing them yourself then sure, this could very well (perhaps even will) cause slowdown. Most everyone that does bring up using physical hardware for start-ups on here instead discuss leasing managed dedicated servers. You can just as easily spin instances on those up/down as needed, and many of the solution providers out there will even have Openstack/VMWare/etc. available pre-installed so you don't have to do any of that legwork. I think engineering for 'The Cloud' can be just as time consuming if not more so for start-ups. For Amazon at least you have to engineer for failure. With a dedicated server configuration you still do need to engineer for that, but you aren't worrying about if depending on the solution providers block storage is going to take certain aspects of your architecture offline when it goes down (yet again), or if the portal won't allow you to bring up/down new instances during a very critical period of time, etc.

Spooky23 13y ago
It's a risk shift. Generally speaking, most sysadmins at small places do a horrible job engineering for failure. Or, worse, they don't have professional SA's, just devs who know enough to be dangerous. So while you don't run into a US-East EBS failure every now and again that affects millions of servers, you are subject to random unforseen failures because somebody didn't do X correctly. (Where X could include: disk configuration, HA configuration, DR plan, backup/restore plan, os management, firewall management, etc) There's no one right answer here. I've rolled specific hardware solutions managed by a single team for certain applications, and everything was fine. I've been stuck working within the bounds of a managed services provider, and things worked too. Cloud is just another model. EC2 lets you roll a globally distributed solution with good tooling for low cost.
- matlock 13y ago
  >EC2 lets you roll a globally distributed solution with good tooling for low cost This is the Crux. There are other options available, but going cloud makes it very easy to roll out something big without the necessity to have experts in all the lower level parts of your infrastructure. It lets you focus and the price for that is absolutely reasonable
- druiid 13y ago
  I fully agree on the SA stuff. Sadly more often than not it's some dev who knows enough to be really dangerous. I make a good amount of money by coming in and mopping up after those kinds of scenarios (sadly... I'd rather make less money up-front by helping in the planning phase). I will say however that while yes, it's a risk shift you can still have and will have plenty of those risks that are shifted to the cloud still unaccounted for. For instance, backups. Just because your servers are now on 'the cloud' does not mean they're immune from losing all of their data if the instance dies, especially on EC2. On EC2 it's generally just a 'whoops, bye!' scenario. At least with Rackspace cloud it might be a 'whoops, restore from a VM image snapshot from last week'.