4 ms·

Why can't you just rent the server from some company? Such a company is only responsible for making sure the hardware works (there are no power outages, the dis

Why can't you just rent the server from some company? Such a company is only responsible for making sure the hardware works (there are no power outages, the disks work, the network is up and reachable) Isn't that what Amazon does? (even though they are virtual servers)? You'd still save a lot of money compared to cloud servers, Can you post some numbers? A 24 core 48GB Dell server with 3x120GB SSD's costs around $11K, or around $300/month for a 36 month lease. An 8 core 15GB 160GB AWS c3.2xlarge costs around $200 each per month with a 3 year reserved instance. 3 of them will fit in one of the Dells, so it would cost around $600/month, or about $300 more than the raw purchase price for the hardware alone. But also with that price you get network, power, cooling, rack space, maintenance, etc, so it's not clear that buying and running that server is significantly cheaper. Some bare metal servers are up and running within 120sec How long does it take if you want 500 of them? And 2 hours later you want to turn them off. Then 2 hours after that you want to bring them all back online again. you can't just shut them down and stop paying like cloud servers. But that's the big value-add in Cloud servers, it's capacity on demand so you only pay for what you us -- need to spin up 500 servers to run month-end processing? You only need to pay for them for the few hours or days a month when you need them. Further, you can add multi-datacenter or multi-region redundancy at very little additional cost - you don't need to keep those redundant servers running when you're not using them.

dogma1138 11y ago
Why should you? also you forget that not ever service scales the same way or has the same usage across the year. Take for example something old school and established (ZzZzZ) - accounting. Say you are an accounting firm with an established IT infrastructure and you now want to launch a new service that will allow new smaller clients to perform certain tasks even a single one (say fixed assets devaluation for deductibles). The core of the service is a messaging API as it's an accounting application it's usage wont be fixed and the product team estimates that on a normal week it will handle 20,000 requests, on a end or the quarter week it will handle 500,000 and at the end of the financial year it will handle 2,000,000 how do you scale this? Say a single server will 20,000 request so you have here a 1 to 100 scaling between peak and normal usage which means that if you own your own infrastructure you are paying for 99 servers to idle during most of the time. Even if you can some how manage to do some inner-organizational thin provisioning you will still be wasting allot of hardware because as it turns out most of your other internal services also follow a similar usage trend so that might not be an option to begin with. Now you can rent VPS/IAAS from say Amazon or Rackspace but then you still have a huge overhead sure you'll pay less for usage because those 99 instances will be down but you still need to pay for other resources e.g. reserved IP addresses and storage, you need to practice and test the machines every couple of weeks/months and you need an live-ops/sys-admins with balls of steel to be confident enough to agree to spin up 99 instances at the very last moment and hope that everything will work out smoothly. But even that doesn't really solve it because it doesn't allow you to be flexible with onboarding new costumers, it can't predict various trends like a change in legislation or a holiday weekend prompting people to use your service earlier / later than expected. But if you say just use a PAAS/SAAS messaging service all of this goes away, you don't worry about scaling as long as the service can handle your peak traffic, you don't worry about waste because you pay what you use so if you've only sent 18796 messages in week 37 you pay for that exact amount, you don't need to worry about some promotion that the marketing and product dev team was running that caused an influx of new customers without telling you, and you don't have to really worry about down time, backups, and even security (as long as you get sufficient assurance from your service provider) because as long as their service is up you are up and running.
lbradstreet 11y ago
Just a side note. After some benchmarking, I recently discovered that c3.2xlarge does not actually have 8 cores, rather it had 4 real cores = 8 hyper threaded cores. I was very surprised by this and suspect most other AWS users would also be surprised. This is not to say that AWS is a bad deal, but I think Amazon could be a little more transparent about it. See http://www.pythian.com/blog/virtual-cpus-with-amazon-web-services/ http://www.pythian.com/blog/virtual-cpus-with-amazon-web-ser... for more details.
sgt101 11y ago
a bigger issue than the cost, even the fully loaded cost is the capability you can buy. I have a feeling that a lot of faults that in the google infrastructure result in 2 minutes down time, or even just a raised eyebrow in the ops centre would put most SME's (or event big corporates) on there arse for a week. Do you have a spare generator? If main power goes how long do the UPS keep you going for ? If you have a dc fire what happens... These are things that you can plan for but need real capability to deal with, capability that needs scale.

dogma1138 11y ago

Why should you? also you forget that not ever service scales the same way or has the same usage across the year. Take for example something old school and established (ZzZzZ) - accounting. Say you are an accounting firm with an established IT infrastructure and you now want to launch a new service that will allow new smaller clients to perform certain tasks even a single one (say fixed assets devaluation for deductibles). The core of the service is a messaging API as it's an accounting application it's usage wont be fixed and the product team estimates that on a normal week it will handle 20,000 requests, on a end or the quarter week it will handle 500,000 and at the end of the financial year it will handle 2,000,000 how do you scale this? Say a single server will 20,000 request so you have here a 1 to 100 scaling between peak and normal usage which means that if you own your own infrastructure you are paying for 99 servers to idle during most of the time. Even if you can some how manage to do some inner-organizational thin provisioning you will still be wasting allot of hardware because as it turns out most of your other internal services also follow a similar usage trend so that might not be an option to begin with. Now you can rent VPS/IAAS from say Amazon or Rackspace but then you still have a huge overhead sure you'll pay less for usage because those 99 instances will be down but you still need to pay for other resources e.g. reserved IP addresses and storage, you need to practice and test the machines every couple of weeks/months and you need an live-ops/sys-admins with balls of steel to be confident enough to agree to spin up 99 instances at the very last moment and hope that everything will work out smoothly. But even that doesn't really solve it because it doesn't allow you to be flexible with onboarding new costumers, it can't predict various trends like a change in legislation or a holiday weekend prompting people to use your service earlier / later than expected. But if you say just use a PAAS/SAAS messaging service all of this goes away, you don't worry about scaling as long as the service can handle your peak traffic, you don't worry about waste because you pay what you use so if you've only sent 18796 messages in week 37 you pay for that exact amount, you don't need to worry about some promotion that the marketing and product dev team was running that caused an influx of new customers without telling you, and you don't have to really worry about down time, backups, and even security (as long as you get sufficient assurance from your service provider) because as long as their service is up you are up and running.

lbradstreet 11y ago

Just a side note. After some benchmarking, I recently discovered that c3.2xlarge does not actually have 8 cores, rather it had 4 real cores = 8 hyper threaded cores. I was very surprised by this and suspect most other AWS users would also be surprised. This is not to say that AWS is a bad deal, but I think Amazon could be a little more transparent about it. See http://www.pythian.com/blog/virtual-cpus-with-amazon-web-services/ http://www.pythian.com/blog/virtual-cpus-with-amazon-web-ser... for more details.

sgt101 11y ago

a bigger issue than the cost, even the fully loaded cost is the capability you can buy. I have a feeling that a lot of faults that in the google infrastructure result in 2 minutes down time, or even just a raised eyebrow in the ops centre would put most SME's (or event big corporates) on there arse for a week. Do you have a spare generator? If main power goes how long do the UPS keep you going for ? If you have a dc fire what happens... These are things that you can plan for but need real capability to deal with, capability that needs scale.