Call me traditional or old-fashioned, but I like having physical access to my data. I also like being responsible for ensuring our services stay up and running. If e-mail is down, I can fix it, instead of calling someone else to check it out for me. Several techs in our state from a recent meeting shared this sentiment as well.
I guess you like it because it's your job, and if your job was reduced to passing questions onto someone else, you'd be redundant.
Myself, I'd far prefer *not* to have physical access to my data. If I can have secure access to my data without having to worry about messy, space-consuming, power-consuming, attention hogging hardware, I'll take that thanks.
Cloud computing services often provide common business applications online that are accessed from a web browser, while the software and data are stored on the servers.
Okay... cloud computing is "business application accessed from a web browser". Well, in the respect I think the deal might be a good step for cloud computing.
The Wikipedia page quite nicely sums up why it's more than just that: "This definition states that clouds have five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service."
It's likely that LA's private pool of resources will exhibit most of that. Whether that elasticity is necessary, I'm not sure. I wonder whether Google will be able to dynamically reassign resource from their public pool to their LA pool?
I think this is a step towards relieving MS of their monopoly, even on OSs.
How long until LA city employees don't need Windows for anything. If everything they do is in the browser, they can use Linux (maybe in the guise of ChromeOS)
If they were only reporting the news, instead of 'producing' it, their readership numbers maight not be tanking as badly...
Quite the opposite, in my opinion. A good newspaper reports the news in a balanced and accurate manner - but has well signposted analysis and opinion, in which it's fine to show bias or "an agenda".
This is what makes a newspaper entertaining, and worth spending money on.
Can Amazon EC2 deliver me 15ms network latency between my application and my customers?
I guess it depends where your customers are in relation to the Amazon farm you use.
It would take you less than half an hour and a dollar to find out: provision an EC2 instance, ping it from a typical customer site, then bring it down.
Do follow up with your findings!
I still think it's an odd requirement. I use a lot of Ajax heavy sites, they feel perfectly responsive and I don't have anywhere near a 15ms response time to any of them.
In the realm of applications that really do need low latency, I suspect it would be a mistake to run a game server from an EC2 instance because there are specialist hosting services for that kind of thing. But I'd be interested to hear how it went, if anyone's tried it.
Since when did code optimized for speed go out of fashion?
Since 1974, when Donald Knuth claimed "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
Of course there's a balance to be made - don't write stuff that's blatantly inefficient. But neither should you spend a week optimising a routine, when a $1000 worth of hardware removes the problem.
I should add... one would expect Amazon to reduce their per-byte prices year on year, in line with falling costs.
Big question: can the industry adopt standards to make migration between services easy, such that customers aren't locked in to one provider, and competing providers can push each others' prices down?
While I can see that makes some sense for a company in a fast growth phase when they stop growing those S3 bills are going to keep on coming while the hard drives and thier enclosures will keep on going for years.
In the specific case of Smugmug (an photo sharing site), their storage needs will never stop growing (as long as users don't abandon them). When their user base stops growing, they'll still be uploading images every day, and those images don't get deleted. I daresay as time goes by, the average size of each file will increase (higher res cameras; more consumer bandwidth; video).
But you're right, many applications will hit a ceiling on their storage needs. Their owners, as Smugmug did, should do the sums and decide what's best value for them. Amazon et al should be manipulating their price structure to compete with owning your own disks.
Until Amazon, or any other "cloud" provider can guarantee PCI-Compliance, we can't even consider them. Our current data center guarantees Level-I compliance and we have it in writing.
It's a valid observation.
If I was to launch a retail web site -- say, hypothetically, ThinkGeek hadn't been invented yet, and I got there first today -- then I'd expect (once I got a Slashvertisment out there) huge numbers of moochers looking at the T-shirt designs but not buying, along with a much smaller number of buyers.
So I would consider hosting images and perhaps the catalogue site on EC2/S3/RDS or some other cloud service - where I can dynamically scale to a slashdotting - and pass buyers to a secure checkout service hosted somewhere else.
I think the GP wants to be able to write an application targeted at a single system, and have it magically scale by adding resource.
Sorry, nobody's achieved that. You have to program with clusters in mind. As long as you do that, however, EC2 lets you add and remove machines from the cluster on demand, via API calls.
Google AppEngine loses you some flexibility, but gives you access to an API that takes full advantage of their massive distributed resources.
a cloud has properties that most datacentres do not.
Like what?
Like, a single node failing is routine, routed around in software, and not considered a problem. Yes, in a traditional datacentre you'd have dual or treble redundant servers, but if one goes down in the middle of the night it's a crisis and an operator's pager goes off. Not in a cloud.
Like: Bringing up a new VM, or hundreds of new VMs, is something you can do on a whim. Yes, newer VM-oriented datacentres have the technology to do this, but because of the way they're managed and financed, usually you have to go through a time consuming approval/requisitioning process to even add one VM.
Like: Dynamic scaling and location. For example, with S3, if your store is getting a lot of hits, you'll benefit from Akamai-like caching wherever in the world Amazon has a presence.
And more. Anything you can imagine that comes from using a small fraction of a really huge pool of computing resources, spread across the planet.
What you don't mention is that you pay a premium for using only what you need instead of building out your own infrastructure. In some cases, the premium is upwards of 100% (have had to run the numbers for several clients, for some it works out well, for some it's grossly more expensive).
I think that's fair. It would be pretty amazing if it worked out cheaper in all cases, and everyone should run the numbers and evaluate the benefits before going into it.
But, there are plenty of scenarios where due to predictable loads (or simply low loads), or simple requirements Amazon's pricing model is a bad fit.
I would be most tempted by Amazon's model if I was starting up a service, was hoping for huge sudden growth, but didn't have the confidence to invest upfront in my own hardware for that capacity.
Remind me, which of those companies is hosting anything on MySQL that is actually important (i.e. people would care if it's lost)?
Let's take "important" as meaning "of monetary value", just to simplify the question. Facebook's data is valuable for two reasons:
1. The users treasure it. Their goodwill is vital, if Facebook is to keep them coming back to be served adverts 2. It's a treasure trove of minable information about demographics and connections between people's consumer preferences. Facebook makes money by selling that info.
For non-cloud computing, you pay too much every single day, until you reach optimum usage level. Then you exceed the optimum usage level, and have to buy another server, and pay too much again. So it's a series of server-sized steps, approximating a curve.
If you were paying by the timeslice, the cloud equivalent would show a smooth curve, matching the growth in usage.
OTOH with EC2 you pay by the hour of uptime, rather than by processor usage, so CPU usage isn't of the essence for many applications.
You might well optimise to minimise the stuff you really are paying for. Web designers already try to minimise download bandwidth. You might also strive to compress data before storing it -- but as always, it's a tradeoff between how much it saves, and how much it costs to do.
Slashdot Mirror
Call me traditional or old-fashioned, but I like having physical access to my data. I also like being responsible for ensuring our services stay up and running. If e-mail is down, I can fix it, instead of calling someone else to check it out for me. Several techs in our state from a recent meeting shared this sentiment as well.
I guess you like it because it's your job, and if your job was reduced to passing questions onto someone else, you'd be redundant.
Myself, I'd far prefer *not* to have physical access to my data. If I can have secure access to my data without having to worry about messy, space-consuming, power-consuming, attention hogging hardware, I'll take that thanks.
Ugh. Sorry about the quoting cockup.
my impression was that "cloud computing" was many clients connected to each other serving each other content.
You're either thinking of P2P or mesh computing.
Let's see what Wikipedia has to say about it
Cloud computing services often provide common business applications online that are accessed from a web browser, while the software and data are stored on the servers.
Okay... cloud computing is "business application accessed from a web browser". Well, in the respect I think the deal might be a good step for cloud computing.
The Wikipedia page quite nicely sums up why it's more than just that: "This definition states that clouds have five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service."
It's likely that LA's private pool of resources will exhibit most of that. Whether that elasticity is necessary, I'm not sure. I wonder whether Google will be able to dynamically reassign resource from their public pool to their LA pool?
I'm not pre-empting the answer, this is a genuine question and not an attempt to score points:
Were paid Google Apps customers as badly affected as users of the free GMail service?
Do big customers like LA City Council have more stringent SLAs?
I think this is a step towards relieving MS of their monopoly, even on OSs.
How long until LA city employees don't need Windows for anything. If everything they do is in the browser, they can use Linux (maybe in the guise of ChromeOS)
If they were only reporting the news, instead of 'producing' it, their readership numbers maight not be tanking as badly...
Quite the opposite, in my opinion. A good newspaper reports the news in a balanced and accurate manner - but has well signposted analysis and opinion, in which it's fine to show bias or "an agenda".
This is what makes a newspaper entertaining, and worth spending money on.
continuing mental degradation as a result of sitting through trash like X Factor.
You clearly don't enjoy it on as many levels as I do ;)
Spotify isn't free, as long as you count listening to adverts as a payment method.
I pay for GMail by seeing ads.
I pay for Spotify by hearing ads.
I pay for X Factor by fast-forwarding through ads...
Can Amazon EC2 deliver me 15ms network latency between my application and my customers?
I guess it depends where your customers are in relation to the Amazon farm you use.
It would take you less than half an hour and a dollar to find out: provision an EC2 instance, ping it from a typical customer site, then bring it down.
Do follow up with your findings!
I still think it's an odd requirement. I use a lot of Ajax heavy sites, they feel perfectly responsive and I don't have anywhere near a 15ms response time to any of them.
In the realm of applications that really do need low latency, I suspect it would be a mistake to run a game server from an EC2 instance because there are specialist hosting services for that kind of thing. But I'd be interested to hear how it went, if anyone's tried it.
I guess you *could*. But it's likely not the best/cheapest backup option using Amazon Web Services.
Alternatives:
- rsync to an EC2 instance - you can even then take snapshots to S3.
- use one of the many backup utilities that store on S3
"Can they deliver me 15ms to my customers?"
Why do I have to use more words asking you to make sense, than you use to hint at some meaning?
You could start by telling us what application you have in mind. Obviously not HTTP. Nobody needs a web page to load in 15ms.
I recommend you don't play Tux Racer over X on an Amazon EC2 instance. That's not what it's designed for.
Since when did code optimized for speed go out of fashion?
Since 1974, when Donald Knuth claimed "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.6084&rep=rep1&type=pdf
Of course there's a balance to be made - don't write stuff that's blatantly inefficient. But neither should you spend a week optimising a routine, when a $1000 worth of hardware removes the problem.
15 milliseconds to my customers?
Perhaps more words on either side would cause your question/observation/whatever to make sense?
All databases are for web sites now?
[applause]
Can I quote you in full, when the next cloud story hits?
I should add... one would expect Amazon to reduce their per-byte prices year on year, in line with falling costs.
Big question: can the industry adopt standards to make migration between services easy, such that customers aren't locked in to one provider, and competing providers can push each others' prices down?
While I can see that makes some sense for a company in a fast growth phase when they stop growing those S3 bills are going to keep on coming while the hard drives and thier enclosures will keep on going for years.
In the specific case of Smugmug (an photo sharing site), their storage needs will never stop growing (as long as users don't abandon them). When their user base stops growing, they'll still be uploading images every day, and those images don't get deleted. I daresay as time goes by, the average size of each file will increase (higher res cameras; more consumer bandwidth; video).
But you're right, many applications will hit a ceiling on their storage needs. Their owners, as Smugmug did, should do the sums and decide what's best value for them. Amazon et al should be manipulating their price structure to compete with owning your own disks.
Until Amazon, or any other "cloud" provider can guarantee PCI-Compliance, we can't even consider them. Our current data center guarantees Level-I compliance and we have it in writing.
It's a valid observation.
If I was to launch a retail web site -- say, hypothetically, ThinkGeek hadn't been invented yet, and I got there first today -- then I'd expect (once I got a Slashvertisment out there) huge numbers of moochers looking at the T-shirt designs but not buying, along with a much smaller number of buyers.
So I would consider hosting images and perhaps the catalogue site on EC2/S3/RDS or some other cloud service - where I can dynamically scale to a slashdotting - and pass buyers to a secure checkout service hosted somewhere else.
I'm sorry but administering a db just isn't that difficult or time-consuming.
It's quite a lot more difficult and time-consuming than not administering a DB.
I think the GP wants to be able to write an application targeted at a single system, and have it magically scale by adding resource.
Sorry, nobody's achieved that. You have to program with clusters in mind. As long as you do that, however, EC2 lets you add and remove machines from the cluster on demand, via API calls.
Google AppEngine loses you some flexibility, but gives you access to an API that takes full advantage of their massive distributed resources.
a cloud has properties that most datacentres do not.
Like what?
Like, a single node failing is routine, routed around in software, and not considered a problem. Yes, in a traditional datacentre you'd have dual or treble redundant servers, but if one goes down in the middle of the night it's a crisis and an operator's pager goes off. Not in a cloud.
Like: Bringing up a new VM, or hundreds of new VMs, is something you can do on a whim. Yes, newer VM-oriented datacentres have the technology to do this, but because of the way they're managed and financed, usually you have to go through a time consuming approval/requisitioning process to even add one VM.
Like: Dynamic scaling and location. For example, with S3, if your store is getting a lot of hits, you'll benefit from Akamai-like caching wherever in the world Amazon has a presence.
And more. Anything you can imagine that comes from using a small fraction of a really huge pool of computing resources, spread across the planet.
What you don't mention is that you pay a premium for using only what you need instead of building out your own infrastructure. In some cases, the premium is upwards of 100% (have had to run the numbers for several clients, for some it works out well, for some it's grossly more expensive).
I think that's fair. It would be pretty amazing if it worked out cheaper in all cases, and everyone should run the numbers and evaluate the benefits before going into it.
I know Smugmug.com believe they're $500K by using S3 instead of their own storage servers. http://blogs.smugmug.com/don/2006/11/10/amazon-s3-show-me-the-money/
But, there are plenty of scenarios where due to predictable loads (or simply low loads), or simple requirements Amazon's pricing model is a bad fit.
I would be most tempted by Amazon's model if I was starting up a service, was hoping for huge sudden growth, but didn't have the confidence to invest upfront in my own hardware for that capacity.
Remind me, which of those companies is hosting anything on MySQL that is actually important (i.e. people would care if it's lost)?
Let's take "important" as meaning "of monetary value", just to simplify the question. Facebook's data is valuable for two reasons:
1. The users treasure it. Their goodwill is vital, if Facebook is to keep them coming back to be served adverts
2. It's a treasure trove of minable information about demographics and connections between people's consumer preferences. Facebook makes money by selling that info.
For non-cloud computing, you pay too much every single day, until you reach optimum usage level. Then you exceed the optimum usage level, and have to buy another server, and pay too much again. So it's a series of server-sized steps, approximating a curve.
If you were paying by the timeslice, the cloud equivalent would show a smooth curve, matching the growth in usage.
OTOH with EC2 you pay by the hour of uptime, rather than by processor usage, so CPU usage isn't of the essence for many applications.
You might well optimise to minimise the stuff you really are paying for. Web designers already try to minimise download bandwidth. You might also strive to compress data before storing it -- but as always, it's a tradeoff between how much it saves, and how much it costs to do.
Excellent point. And by hosting on EC2, at least they haven't spent a fortune on hardware, should Amazon drive them out of the market.