Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Ideal, Non-Proprietary Cloud

CmdrTaco posted more than 6 years ago | from the looks-like-cotton-candy dept.

The Internet 93

jg21 writes "As previously discussed on Slashdot, the new tendency to speak of 'The Cloud' or 'Cloud Computing' often seems to generate more heat than light, but one familiar industry fault line is becoming clear — those who believe clouds can be proprietary vs. those who believe they should be free. One CEO who sides with open clouds in order that companies can pick and choose from vendors depending on precisely what they need has written a detailed article in which he outlines how, in his opinion, Platform-as-a-Service should work. He identifies nine features of 'an ideal PaaS cloud' including the requirement that 'Developers should be able to interact with the cloud computer, to do business with it, without having to get on the phone with a sales person, or submit a help ticket.' [From the article: 'I think this means that cloud computing companies will, just like banks, begin more and more to "loan" each other infrastructure to handle our own peaks and valleys, But in order for this to happen we'd need the next requirement.']"

Sorry! There are no comments related to the filter you selected.

Security? (3, Insightful)

llamalad (12917) | more than 6 years ago | (#24272645)

Am I missing something, or does the article make no mention of security?

Re:Security? (0)

Swizec (978239) | more than 6 years ago | (#24272671)

You're missing that this is slashdot and you weren't supposed to RTFA.

Re:Security? (1)

llamalad (12917) | more than 6 years ago | (#24272749)

I didn't. I clicked on it and hit "control-f".

All the same, just from the summary, as soon as I got to the notion that boxes would be loaned back and forth between companies my spider-sense got all unpleasant and tingly.

I don't think I care whether my cloud is open or proprietary, as long as security is designed in from the start and not an afterthought.

Upload the crown jewels of your enterprise (5, Insightful)

mosel-saar-ruwer (732341) | more than 6 years ago | (#24273429)


In this day and age - when hardware is essentially worthless [today, for under $200, you can get what would have been a $10 million supercomputer ten years ago], and when even RDBs are essentially worthless [MySQL & PostgreSQL being free downloads], the only things which add value are:
.

1) Your schema [or your customizations of the vendor's standard template of the schema for your industry], and

2) Your business logic for manipulating the schema [or your customizations of the vendor's standard template of the business logic for your industry], and

3) The actual data in your database, and

4) Your algorithms for analyzing the data in your database [or your customizations of the vendor's standard template of the analysis algorithms for your industry].

Of those, at least 1), 3), and 4) are going to have to be uploaded to "The Cloud" [and 2) might have to at least interact with "The Cloud"], and unless "The Cloud" encrypts everything - both data & logic [and how do you really "encrypt" something if ultimately the registers in the CPU have to see unencrypted data, and especially unencrypted logic & algorithms?] - then you've just uploaded the crown jewels of your entire enterprise for all the world to see.

Also - bandwidth for the upload of the jewels (5, Informative)

mosel-saar-ruwer (732341) | more than 6 years ago | (#24273993)


And in this day and age, when even medium-sized businesses can be sitting on literally terabytes of data, how are you going to upload all of that data to "The Cloud" so that "The Cloud" can analyze it for you?

Maintaining a constant 10Mbps WAN connection to "The Cloud" would be monstrously expensive, and yet, at 10Mbps = (10 / 8)MBps = 1.25MBps, that means you would need
.

1 terabyte / 1.25MBps
= (1000 * 1000 * 1000 * 1000 bytes) / (1.25 * 1000 * 1000 bytes per second)
= [(1000 * 1000) / 1.25] seconds
= 800,000 seconds
= [800,000 / (60 * 60 * 24)] days
= 9.259 days

just to upload a terabyte of data at WAN speeds of 10Mbps.

So "The Cloud" isn't going to have realtime interactions with your corporate database - "The Cloud" is going to BE your corporate database.

Re:Upload the crown jewels of your enterprise (0)

Anonymous Coward | more than 6 years ago | (#24282103)

You need to be more careful with semantics. You are confusing concepts of 'worth', 'value', 'cost' and maybe even 'purchase price', which is what you are _really_ talking about when you say 'worth'.

(Case in point, the hardware you discuss is probably 'worth' today much more than the hypothetical supercomputer of the last decade, even though the 'cost' and immediate 'price' is an order of magnitude less.)

Don't under-estimate the danger of sloppy language use.

Re:Security? (4, Insightful)

thatskinnyguy (1129515) | more than 6 years ago | (#24272739)

Am I missing something, or does the article make no mention of security?

Or some sort of business model where someone makes money to run all of this.

Re:Security? (2, Interesting)

ObsessiveMathsFreak (773371) | more than 6 years ago | (#24273421)

Or indeed, mention of anyone, anywhere actually using "cloud computing".

Re:Security? (2, Informative)

Electrum (94638) | more than 6 years ago | (#24275351)

Or indeed, mention of anyone, anywhere actually using "cloud computing".

Yeah, no one is actually using [amazon.com] Amazon's EC2.

Re:Security? (2, Informative)

Jick (29139) | more than 6 years ago | (#24281801)

There are already great examples of businesses using the cloud to support their infrastructure (Amazon's posterchild being SmugMug.)

One of the major reasons people will migrate is efficiency. In this green-age that we're now in, companies are looking to reduce their individual power requirements while increasing scale. Who can provide cheaper power or more efficient cooling for datacenter? Your on-site NOC or ACME colo? ACME colo, or sunpowered-ocean-cooled-datacenter.com? By making this leap, companies are able to lower their costs, 'at the cost' (har har) of building their applications in a cloud-friendly manner.

There are a few major hurdles left to cross for widespread adoption, but you can see this wave coming from miles away.

Two of those hurdles are reliability and performance. As a business looking to lower costs by switching to cloud-based computing (say Amazon's EC2), I need to know what kind of performance I can get and how reliable the service will be. This information is starting to come out via services like CloudStatus.com [cloudstatus.com] -- which is able to give performance and health metrics on a real-time & historical basis.

You'll definitely see a huge push towards SLAs which will push adoption. The competition is heating up in this space.

// Disclaimer -- I work for Hyperic which wrote CloudStatus

Reality? (0)

Anonymous Coward | more than 6 years ago | (#24273367)

So the discussion comes down to: proprietary vaporware, or free vaporware.

When discussing vaporware, it seems to me that any matters beyond that point are superfluous.

Re:Reality? (2, Interesting)

clang_jangle (975789) | more than 6 years ago | (#24276103)

When discussing vaporware, it seems to me that any matters beyond that point are superfluous.

Are you mad?! Vaporware MUST be kept free, or we're all doomed!
Seriously though, yes, "the cloud" paradigm is a myth, but it's a myth much beloved by certain software companies who hope to restore the "balance" of scarcity in the future. So if we actually do get "the cloud", it will almost certainly be proprietary, as that's really the whole point. Of course we probably won't get it, as other than reintroducing scarcity, it serves no realistic purpose. At this time, we don't even have a proper definition for "cloud computing", other than "essential software will no longer be local". How transparent is that?

So does this mean..... (3, Funny)

mike_c999 (513531) | more than 6 years ago | (#24272667)

... That cloud computing silver lining has started to tarnish already?

Never so apropos (2, Funny)

$RANDOMLUSER (804576) | more than 6 years ago | (#24272729)

I've looked at clouds from both sides now,
From up and down, and still somehow,
It's cloud illusions I recall,
I really don't know clouds, at all.

You beat me to it! (1)

khasim (1285) | more than 6 years ago | (#24273431)

I cannot wait until Web 3.5 gets here and we can tag articles with sound clips.

So many things I would have done
But clouds got in my way

Re:So does this mean..... (0)

Anonymous Coward | more than 6 years ago | (#24273029)

... That cloud computing silver lining has started to tarnish already?

No, I just think some folks are in a fog.

Re:So does this mean..... (1)

HTH NE1 (675604) | more than 6 years ago | (#24275707)

I'm just wondering how deep this Platform-as-a-Service will dye my Easter eggs [paaseastereggs.com] .

Huh? (2, Insightful)

sarathmenon (751376) | more than 6 years ago | (#24272679)

What makes him so sure that interoperability will be even on the provider's list? I don't see any easy way to use EC2 with some third party solution for storage. Plus, it would be lame if I had to go via internet for every request that should ideally be local.

Re:Huh? (4, Funny)

bsDaemon (87307) | more than 6 years ago | (#24272703)

No, you just don't get how awesome it'll be to get all your Web 2.5rc1 content via Internet2 through the cloud, man... it'll totally shift your paradigm.

Re:Huh? (0)

Anonymous Coward | more than 6 years ago | (#24274425)

Thanks, but I'm only really interested if it can also leverage my synergies.

Re:Huh? (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24282929)

I don't see any easy way to use EC2 with some third party solution for storage.

It's really no "harder", technologically, than using EC2 with S3. It's just that S3 is probably cheaper, especially when bandwidth between the two is free.

More specifically: An EC2 instance is just a Xen virtual machine. Amazon places no restrictions on what you run inside -- and as far as I know, they haven't even released their own S3 bindings, in any language. It's up to you to connect to S3, and it's exactly the same process, whether you're connecting from EC2 or not.

it would be lame if I had to go via internet for every request that should ideally be local.

That's exactly what EC2+S3 is. It's faster, certainly, if you're in Amazon's datacenter, but people can (and do) use S3 without EC2. Keep in mind that if either speed or reliability of the connection between the two is a concern, then you've chosen poorly for either hosting or storage.

But if you were expecting to, say, mount S3 as a local disk, you'll be disappointed. People have done so, but with deep black magic write-caching tricks that would probably work over a WAN as well.

Interoperability? (1)

spankymm (1327643) | more than 6 years ago | (#24272693)

Sounds like he has his head in the clouds.

Can't work yet. (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24282947)

When a concept is so new that people can't even define it, now is not the time to be trying to develop an "open standard". Now is the time to be rapidly prototyping different ideas.

When we have several, stable clouds, then it might be time to talk about interoperability, or at least a compatibility layer.

Speaking of non-proprietary clouds... (3, Interesting)

Anonymous Coward | more than 6 years ago | (#24272731)

The guys at Red Hat have released the first version of a project called Genome genome.et.redhat.com [redhat.com] . This looks to be an open source project that makes Fedora, Red Hat Enterprise Linux, and CentOS clouds using Xen, KVM, and commodity hardware.

renting software .. (5, Insightful)

rs232 (849320) | more than 6 years ago | (#24272765)

Relying on third party technology is never going to provide the reliability or uptime required. The more straight forward solution is to hire some rackspace and host your own solution. 'Cloud Computing' is just the latest marketing promotion designed to move us to renting software.

Re:renting software .. (5, Informative)

larry bagina (561269) | more than 6 years ago | (#24272799)

hiring rackspace is relying on third party technology.

Re:renting software .. (1)

Free the Cowards (1280296) | more than 6 years ago | (#24274387)

What he meant to say, I believe, was relying on unfamiliar and therefore frightening third party technology.

Re: who owns the Cloud .. (1)

rs232 (849320) | more than 6 years ago | (#24275009)

"hiring rackspace is relying on third party technology"

Just for the box, a USB and an Internet connection. If you don't own your own technology, you're not a real business ..

Re:renting software .. (3, Insightful)

dkf (304284) | more than 6 years ago | (#24272861)

'Cloud Computing' is just the latest marketing promotion designed to move us to renting software.

For some software that makes sense. Some apps cost an enormous amount to buy a copy of (no, MS Office isn't one of these!) and many smaller businesses don't need a copy continually. For example, a small engineering firm probably doesn't need a Computational Fluid Dynamics package the whole time, but when they're designing a product it's useful to rent some use of one.

Does this mean that everyone will be hiring everything? I really doubt it. I reckon that the end result will be a mixed economy with some purchases and some hiring. Which will be the dominant mode at any time? Well, that'll probably change from year to year. Guess what? That's true for other parts of the economy too. IT's not that special...

Re:renting software .. (2, Insightful)

sm62704 (957197) | more than 6 years ago | (#24273103)

For example, a small engineering firm probably doesn't need a Computational Fluid Dynamics package the whole time, but when they're designing a product it's useful to rent some use of one.

Except that the training required to learn this software is more expensive than the software. It would be cheaper to hire an engineer who had his own tools.

It's like when your car breaks - it's cheaper to hire a mechanic than to rent diagnostic computers and other tools the mechanic has and learn about internal combustion engines and how to use the tools you rented.

Remember, the term "cloud computing" was coined by the clueless who didn't understand the chart's meaning, or he would have simply said "distributed computing".

Re:renting software .. (2, Interesting)

dkf (304284) | more than 6 years ago | (#24281109)

Except that the training required to learn this software is more expensive than the software. It would be cheaper to hire an engineer who had his own tools.

Not really. The top-end CFD codes are really very expensive indeed, and have "interesting" restrictions on use too. (I know of at least one that is considered to be a munition, being greatly useful for designing missile systems.)

It's like when your car breaks - it's cheaper to hire a mechanic than to rent diagnostic computers and other tools the mechanic has and learn about internal combustion engines and how to use the tools you rented.

Except that the focus is on renting to businesses, not consumers. While cloud computing can be made to work with consumers, you typically won't sell it to them "raw", but rather as packaged services that might be paid for directly or through advertising. This whole area of cloud-driven business models is very complex indeed.

Remember, the term "cloud computing" was coined by the clueless who didn't understand the chart's meaning, or he would have simply said "distributed computing".

I should warn you, I work in this field. Cloud computing is more about the space where SOA and grid computing meet, while distributed computing tends to be more about building clusters and stuff like that. The issue is that once you go over the size of a cluster, the overheads of messaging go up massively as you start having to take into account things like security and management (i.e. asshats of all varieties). This means as you move up to the cloud level of conceptual operation you've got to think in terms of breaking your overall processing in different ways. For example, if you were doing drug discovery, you might use a large high-availability cluster (possibly based off a SETI@home-like cycle scavenger) to do the initial search for candidates, and then you'd refine the matches with supercomputing time (using finer and more complex models of molecular interactions) where you know you're not just throwing effort away on a "no hope" option. And that is actually a simple example of what is going to be the case; science and engineering workflows can easily get much more complex, especially when working with multiple datasets with elaborate security requirements (common in medical research). And it's when you consider the effects of this on the way that software vendors work that the whole renting stuff drops out as a way of (probably) increasing the size of market for those guys.

In short, your cynicism is both understandable and laudable, but misplaced.

Re:renting software .. (1)

sm62704 (957197) | more than 6 years ago | (#24289815)

I know of at least one that is considered to be a munition

IINM Back in the 1980s, it was illegal to export dBase for pretty much the same reason.

As to "cloud computing", I think it's a terrible name. It's akin to back when the clueless called DOS "doss" without even knowing what an operating system was or what DOS stood for. Database admins didn't coin the term, their pointy haired bosses did.

Re:renting software .. (2, Insightful)

samkass (174571) | more than 6 years ago | (#24272871)

You're making a lot of assumptions about needs, uptime, costs, and levels of in-house expertise when you make those blanket statements. There's always a balance between "relying on third parties" and "not invented here syndrome". In the latter case, you'll have people attempting things way outside their area of expertise and reliability or uptime will be significantly worse than if they'd let the experts do their job and paid a fair price.

Re:renting software .. (0)

Anonymous Coward | more than 6 years ago | (#24272945)

It's not cheap to set up a CDN so there's some value in that as a service. If they can offer cheap, on demand VPS's developers can take it from there. But the cloud is being targeted at consumers with services like .Mac (or mobileMe or whatever they call it this week) when anybody in the know will just use rsync.

Yet another business model that relies on ignorance and makes the trivial overly complex. Obviously there's a huge market for this type of thing :-/

Re:renting software .. (5, Insightful)

querist (97166) | more than 6 years ago | (#24272951)

I believe that you are partly correct in your assertion that cloud computing is, eseentially, marketing hype intended to move us toward renting software.

One advantage that cloud computing has over your proposed solution is that you are not paying for the idle time where your rack of computers is not doing anything. You only pay for what you use (within limits - I suspect a cellphone-like billing plan will emerge). This and the rapid scalability would be wonderful for smaller businesses.

Imagine that you have minimal needs during most of the year - word processing, billing, etc, but on a quarterly basis you need to do your taxes (US businesses normally must file tax reports on a quarterly basis) and on an annual basis you need to do a large amount of computing - employee tax records, inventory, other annual processing. With cloud computing, if you are willing to accept having your data somewhere else that is not in your physical control, you simply ramp-up the computing need in December and then you're done. You finish on time and have a larger "bill" at the end of the month. This is very much like electricity - in cooler months you don't run your AC in the house, but when a heat wave comes along you run the AC more and you just pay a higher bill. You don't maintain your own power generation capacity, you simply use more of the available supply when you need it.

One of the nice ideas behind "cloud" computing is that computational is treated as a consumable resource, much like electricity. Cloud computing, in that way at least, is similar to "grid computing". The differences are important, however.

"Grid" computing is related to raw computing power being distributed for a large problem. Cloud computing, on the other hand, is not so much about one user being able to access huge amounts of processing power at once as it is about making computing resources available on demand and from anywhere.

Imagine it like this for a moment: every device that plugs into a wall outlet has its own "power meter" like the one that the electric company use to determine how much to bill you each month. (Let's not go into a discussion about estimates, how often they really read the meters, etc., please. This is only an analogy.) You can take your devices anywhere, and when you plug it into the wall the little meter records how much electricity you use.

So, when you are at a hotel, a friend's house, or the public library, you are still being billed personally for the electricity that your laptop computer is using. You can do what you like with the electricity as long as you don't violate any laws of physics and as long as you stay within the limits of your connection or access. (In other words, don't try to draw 40 amps from a 20 amp outlet - you'll trip the breaker.)

But, instead of electricity, you are accessing computational services in the form of data storage and software as well as data transfer. The nice thing is that you can access it from anywhere (such as Google Apps) with little dependence on operating system or platform.

If (and this is a big "if") they can work out the security concerns, this could be very useful for large businesses.

Re:renting software .. (3, Insightful)

Z34107 (925136) | more than 6 years ago | (#24274037)

"Cloud computing" sounds exactly like how (I'd imagine, beinga young'un) mainframe time was rented back in the Bad Old Days. Except that one mainframe has been replaced with one "cloud."

However they billed for a batch job back in the '50s is how I'd expect them to build for their cloud. Just replace dumb terminals or an operator with the interwebs, and you're good to go.

Re:renting software .. (1)

nurb432 (527695) | more than 6 years ago | (#24281365)

An entire building of mainframe hardware would be even closer to 'the cloud' as it could share processing across the cpu's once you got out of batch and into something interactive like TSO.

Re:renting software .. (0)

Anonymous Coward | more than 6 years ago | (#24282163)

How does cloud know what punch cards is?!!!

Re:renting software .. (0)

Anonymous Coward | more than 6 years ago | (#24274939)

With the current cost of dual core CPU-based servers you can have them in stack just for the occasion :-)

Pricing model in cloud computing looks extremely unconvincing.

Re:renting software .. (2, Insightful)

random name 6721 (876265) | more than 6 years ago | (#24277513)

Imagine it like this for a moment: every device that plugs into a wall outlet has its own "power meter" like the one that the electric company use to determine how much to bill you each month...

Well, true, Cloud computing could provide that. But you are missing the point of the name 'Grid Computing' - the original idea was to model compute time provisioning after a Power *Grids*: you plug your laptop into an outlet, and, voila, ...

So, your wall outlet idea was already promised by Grid Computing -- what Cloud computing seems to add, IMHO, is support for (a) very simple interfaces to use the provided resources, and (b) support for specific usage modes. Grids are more all-purpose infrastructure, which makes them rather complex, and non-trivial to use. Clouds focus on a few, but very common use cases, which makes them much more simple to use. IMHO, the infrastructure to implement a Cloud can very well be a Grid...

Best, Andre.

Re:renting software .. (1)

pr0nbot (313417) | more than 6 years ago | (#24277753)

If (and this is a big "if") they can work out the security concerns, this could be very useful for large businesses.

Perhaps we will see 'cloud computing' at the LAN level rather than the WAN level.

Re:renting software .. (1)

recharged95 (782975) | more than 6 years ago | (#24281571)

"You can take your devices anywhere, and when you plug it into the wall the little meter records how much electricity you use."

So you're saying cloud computing is just a computer network with distributed apps. Genius.

Nice explanation, but I see the corporate consultants strike again.

Re:renting software .. (1)

lsatenstein (949458) | more than 6 years ago | (#24347583)

Cloud computing is renting of software. It has many advantages.

For certain applications (eg: Human Capital Management, otherwise known as HR) the benefits are substantial.

A) global companies can access application from almost anywhere

B) Self-service functionality for employees,

C) Software maintenance is done once for all renters

D) No requirement for software support staff.

E) Backup and restores are vendors reponsibilities.

F) Eliminates that huge front end licensing charge for at-home applications.

Drawbacks. If you want to switch vendors, it is problematic. Similarly if you want to repatriate the system inhouse. Again, for HCM, and salesforce automation, cloud computing is a good alternative.

Re:renting software .. (1)

JoeMerchant (803320) | more than 6 years ago | (#24273439)

There are times when it makes sense to rent - if you're catering to a fashion driven market where you're "in" one day and "out" the next, you want to be able to reach as much of the world as possible when you're "in" and not have to carry the infrastructure costs while you're "out." In this case, it might make sense to pay 10x the ownership costs while you're "in", since you'll still be making huge profits then, as long as you can drop your costs to 0 when you've got nothing going on. With these kinds of margins, there's a market for "Cloud Services."

On the other hand, if you do the same damn thing day in and day out, at a predictable pace, for decades at a time, you might as well own everything you need and maintain it all yourself - 'cause every dollar that goes to a service company could have been accomplished in-house for $0.50 or less.

It all depends on your style of work. The "Cloud" is for the exciting people... Personally, I don't have enough of a trust fund to be that exciting most of the time.

Re:renting software .. (3, Insightful)

Timothy Brownawell (627747) | more than 6 years ago | (#24273529)

Relying on third party technology is never going to provide the reliability or uptime required.

Even if the third party has way more experience and better hardware than you do?

Re: third party expertise .. (1)

rs232 (849320) | more than 6 years ago | (#24274959)

"Even if the third party has way more experience and better hardware than you do?"

I've worked for some of the 'premier' ISPs and major multinationals, one being a consultancy to the business sector. I've seen better IT infrastructure in the average tech college. As for the expertise of the consultancy, as far as I could make out it conssted of a VB macro to create unique file names for the reports, written as PPT files. Oh yea, the only other 'innovation' was splitting the research department up into teams and refering to them as ' pods ' .. :)

Re:renting software .. (1)

shagymoe (261297) | more than 6 years ago | (#24273683)

You can't get the same scaling from a physical server as you can get from "the cloud" for anywhere near the same price.

Re: economies of scale .. (2, Insightful)

rs232 (849320) | more than 6 years ago | (#24275187)

"You can't get the same scaling from a physical server as you can get from "the cloud" for anywhere near the same price"

Most people don't need such scaling and I can get more per price from a box hosted in a server farm. The reason "the cloud" would be cheaper is they build and staff it at the lowest possible cost. Things happen like forgetting to test the emergency generators [theregister.co.uk] , or what probably really happened, skimping on routine maintenence.

reliability (1)

LukeCrawford (918758) | more than 6 years ago | (#24276461)

I think having all your servers with one provider (even if you are that provider) is usually a bad idea. People make mistakes. hardware dies. natural disasters happen.

Re:renting software .. (1)

CopaceticOpus (965603) | more than 6 years ago | (#24276807)

When hiring your own rackspace, there are several things you must manage. How do you provide redundancy if a server goes down? Or a switch goes down, or the power supply to the whole building? There are answers, but they are expensive and complex. Furthermore, how much storage and bandwidth do you buy? Can you predict spikes and sudden growth?

We've not yet arrived with cloud computing, but the potential seems obvious to me. Simply tell the system "host this domain, run this database, serve up these pages, handle these email addresses", and you're done. You don't have to know or care what hardware you are on. You don't have to worry about redundancy or usage spikes, because a quality provider will have that supported by the cloud. If your usage is low your hosting will be very cheap, and as you grow you simply pay more in hosting charges, without any of the pain and outages of trying to scale up.

Ultimately, this is about spending time on the things that are unique to your business (such as your custom software) and letting someone else worry about the details. Your business probably doesn't operate its own bank or manufacture its own electricity, and soon computing and hosting could fit into this same category.

Re:renting software .. (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24277387)

The more straight forward solution is to hire some rackspace and host your own solution.

Which might be very bad (server in a closet behind the women's bathroom -- it actually has happened). Or it might be very good. If you get good enough at running a datacenter, you might start renting out your spare capacity -- thus, Cloud Computing.

Unless you were talking about renting some rackspace in a datacenter owned and managed by someone else. In which case, what's your point? The only difference here is the pricing model -- you'll be paying for all that rackspace 24/7, even if you only use it for five hours a day. A properly scalable cloud architecture will cost you close to nothing at 3 AM on a Friday when no one's on your site, but will be able to handle the Slashdot effect if you have to.

'Cloud Computing' is just the latest marketing promotion designed to move us to renting software.

Actually, it's not about renting software, it's about renting hardware.

True, you could use all that hardware to build something like Google Docs, which is essentially renting software -- although "renting" is a strange word, considering it's free (ad-supported). Or you could use it to run something entirely different.

I think that's where the confusion is. This article is about 'cloud computing' as in Amazon EC2. You're thinking more of apps in the 'cloud' (as the newest buzzword for web apps just like any other), which is an entirely different discussion.

"Proprietary"? (2, Interesting)

samkass (174571) | more than 6 years ago | (#24272903)

The word "proprietary" is a very vague term that's usually used to connote some sort of "them", where the "us" are the good guys.

The bottom line is that wherever there is value, someone will find a way to charge for it. If this "cloud computing" really has no model under which anyone finds it valuable enough to commercialize it, then it's probably not going to be very popular anyway.

Re:"Proprietary"? (1)

sm62704 (957197) | more than 6 years ago | (#24274185)

I thought "us" was the good guys? Isn't "us" always the good guys? And isn't "them" always the bad guys?

And after all, we're only ordinary men. Me and you, God only knows it's not what we would choose to do. -Pink Floyd

Re:"Proprietary"? (3, Interesting)

Chandon Seldon (43083) | more than 6 years ago | (#24274847)

The word "proprietary" is a very vague term [...] The bottom line is that wherever there is value, someone will find a way to charge for it.

Proprietary implies lock-in and monopoly. The opposite is an "open standard" where there can be a competitive market.

Think proprietary = monopoly, open = free market.

Re:"Proprietary"? (1)

samkass (174571) | more than 6 years ago | (#24291729)

That seems like a somewhat shallow definition. I've heard commercial software called a "de-facto standard" while a competing open-source project who don't give CVS/repository access to anyone "proprietary". Is PDF proprietary or "open"? Has it changed state? I've heard APIs be called proprietary even when they're freely published and unencumbered by patent if they're not attached to a standards body...

Basically, the word means little more than "bad" these days.

Re:"Proprietary"? (1)

Chandon Seldon (43083) | more than 6 years ago | (#24292393)

Basically, the word means little more than "bad" these days.

The fact that some people are confused about the meaning of a term doesn't mean that it has somehow lost its meaning.

That seems like a somewhat shallow definition.

Yes, a bit. The literal definition of "proprietary" is simply "having to do with property". As jargon in the software field, it means "controlled by a single entity".

Haha... (1)

ibanezist00 (1306467) | more than 6 years ago | (#24272933)

Proprietary buzzwords, what will they think of next? What will the next dynamic paradigm shift be?

In seriousness, with all of the glaring security issues and discomforts that people have with sharing their private information over a network, how will this idea ever seriously take off? Will the average home user ever consider such an idea? Personally, though it may be "inconvenient", I feel more secure having my data stored locally than working with it over a cloud.

just like fiat monetary systems? (5, Insightful)

conspirator57 (1123519) | more than 6 years ago | (#24272939)

so we'll end up with a sub-prime computing crisis?

how can you bail out companies that fail to keep sufficient computing reserves in hand to cover their potential obligations?

Re:just like fiat monetary systems? (0)

Anonymous Coward | more than 6 years ago | (#24275035)

so we'll end up with a sub-prime computing crisis?

No. You will end up with the short end of Erlang formula [wikipedia.org] . Essentially, a cloud optimizes the usage of hardware. You pay less to access the hardware, but there is a nonzero risk that the computing cloud will be busy when you need it.

Essentially, the only thing a computing cloud has going for it has better utilization of resources. With hardware and power costs being what they are, I can't really see anyone wanting to eat the pain of not getting access when they need it.

Re:just like fiat monetary systems? (1)

conspirator57 (1123519) | more than 6 years ago | (#24275389)

but, just like other market economies, this depends on good or perfect information in the market to do anything like optimization. The purveyors of the cloud must all have the same good information on likely demand. Otherwise non-zero risk of unavailability turns into computing lines, or a zero risk of getting computing performed in anything like a timely manner.

I'd bet that many consumers will be unwilling and/unable to forecast their consumption growth and that statistical models will eventually fail.

Plus, wherever people build systems, others devise methods to game them. Expect people to intentionally be bursty in job submissions in order to throw your models.

Addressing another flaw brought up by others: security. As a minimum, and not addressing hardware level or virtualization-based "evil genius" problems some form of capability contract based computing is needed to enable mutually untrusting parties to transact the computation of one's algorithms on another's data without inapproriate disclosure. See http://www.erights.org/ [erights.org] for more.

Re:just like fiat monetary systems? (2, Insightful)

Anonymous Coward | more than 6 years ago | (#24277033)

how can you bail out companies that fail to keep sufficient computing reserves in hand to cover their potential obligations?

Simple: The computing provider uses a standard contract that doesn't offer any particular service level guarantee or compensation for downtime and call it 'industry standard'.

Then if they don't have enough reserves to cover their obligations they laugh in their customers' faces.

Re:just like fiat monetary systems? (1)

rootooftheworld (1284968) | more than 6 years ago | (#24288245)

Why do I think they're gonna oversell, like our beloved ISPs?

Re:just like fiat monetary systems? (0)

Anonymous Coward | more than 6 years ago | (#24313073)

They've already got that for network connections, I've heard people says you'd be nuts to use Cogent as a sole business or ISP connection, but that it's so cheap, it's nuts to not have a backup or "additional capacity" connection through them.

Re:just like fiat monetary systems? (0)

Anonymous Coward | more than 6 years ago | (#24280541)

Been reading up on ol' Ronny lately?

http://www.house.gov/htbin/blog_inc?BLOG,tx14_paul,blog,999,All,Item%20not%20found,ID=080721_2234,TEMPLATE=postingdetail.shtml

Re:just like fiat monetary systems? (1)

dkf (304284) | more than 6 years ago | (#24281241)

so we'll end up with a sub-prime computing crisis?

how can you bail out companies that fail to keep sufficient computing reserves in hand to cover their potential obligations?

Well, on one level that level of commoditization represents a rather large success, so I'd be happy enough.

What you will see will be a market economy in computing. Some providers will be cheap-and-cheerful bit-shifters, others will provide stronger guarantees and/or fancier service but cost more. The customers will vote with their money according to how much they value things. What is needed though is a better way to express contracts in electronic form so that customers properly know what they're getting and service vendors know which contracts to stop honoring first in a crunch.

Let there be diversity. Choice is good, especially if we can have software to help us sort through all the choices. By analogy, it's good that I've got a choice of airlines for going intercontinental, and I'm glad that there's travel agents to act on my behalf.

Re:just like fiat monetary systems? (1)

conspirator57 (1123519) | more than 6 years ago | (#24281373)

while you see roses, I look at other commodity industries that require infrastructure, like power. California in particular had a great deal of fun with regulation and subsequent gamed "deregulation". The "power" companies saw there was no good reason to own production capacity and so divested themselves of power generation stations only to be bitten by that decision later. I guarantee you that some business/marketing idiot will push the market that way and that much market turbulence followed by even more idiotic regulations will result. In the meanwhile some other idiot will use it as an excuse to ban personal ownership of user-programmable computers. (Think the Disneys of the world will allow computing trends to continue in isolation?)

Open STANDARDS (1)

ActusReus (1162583) | more than 6 years ago | (#24272969)

Pretty much any technology leads to both open implementations and proprietary implementations. The central question is whether the STANDARDS for interacting with those implementations are open or proprietary. Maybe you deploy Java to a proprietary WebLogic server, or an open JBoss server... but you're dropping basically the same EAR or JAR file in either case. THAT'S one of the key factors determining whether a technology will catch on.

Before you can start developing the proprietary or open implementations, you have to develop the standards. Before you can develop the standards, you have to figure out what it is your developing in the first place. That is, can anyone actually define what this nonsense sales-and-managerspeak "cloud" buzzword even means? It seems like whenever Gartner and Gang tries to shill a new technology that doesn't widely catch on, they just wait a few years and try again with a different buzzword. Ten years ago this was called a "cluster", and few people cared. Five years ago this was called a "grid", and few people cared. Today it's called a "cloud", and I... well, you know.

Re:Open STANDARDS (1)

Thiago Tomei (1104697) | more than 6 years ago | (#24274315)

I humbly disagree. A "cluster" is something that every entity (academic or business-like) in need of moderate computing power considers using nowadays. The grid is used by international collaborations, mainly scientific ones like the LHC ones, LIGO, and the protein-folding guys. The cloud is simply a rehashing of the grid, perhaps more business oriented. And I can assure you that people DO care.

Clouds (1)

jovius (974690) | more than 6 years ago | (#24272973)

I believe clouds should be free, and I'd like to do business with clouds.. not Storm clouds, however.

Blogosphere weather (2, Funny)

sm62704 (957197) | more than 6 years ago | (#24273015)

Today's forecaset: cloudy. This afternoon, continued cloudy with occasional periods of distributed computing.

Tonight: Dark, with periods of light toward morning.

Tomorrow: Ignorant, with occasional words coined by the ignorant used by the knowledgable. May be occasional clouds in the afternoon. In case of tornado, stay in your basement.

Re:Blogosphere weather (1)

ZarathustraDK (1291688) | more than 6 years ago | (#24273603)

Sailing-weather : Watch out, more torrents than ever.

When, dammit? (1)

Monty Worm (7264) | more than 6 years ago | (#24273671)

This looks interesting, but as this is a list of requirements, it isn't available. I need it now.

Some background:
For my employer, I've made an application, under perl and postfix, that runs an email forwarding application. The part the user interacts with mostly is a database server on a webcluster, but the smtp side is handled by (at the moment) 8 machines.

This wouldn't be so bad, but they're getting a little flooded. If I could run the software in the cloud, it could grow and shrink dynamically, which would be great.

In practice, all this would mean is that it could mark and discard spam faster, so the very small amount of legitimate email could be moved faster, rather than the several hours it currently takes to get to the front of the queue.

Re:When, dammit? (1)

Stu Charlton (1311) | more than 6 years ago | (#24295705)

You could use Amazon EC2 to do this today, with the caveat that some are blacklisting EC2 as mail forwarding servers due to spam.

2008 -- Year of the Cloud (3, Funny)

istartedi (132515) | more than 6 years ago | (#24273831)

Every buzzword soaked trade publication on the planet has Cloud on the cover now. When looking for a job, I'm going to put my name and contact info on my resume. Then, in place of the usual job history and qualifications I will put, in the largest font that fits, one word: CLOUD. My pay will go up 25%. Then, in 6 months, people will be saying "remember cloud computing?".

Re:2008 -- Year of the Cloud (1)

foxylad (950520) | more than 6 years ago | (#24283869)

I disagree - 2008 and will be remembered as the birthday of cloud computing, the same way 1981 is remembered as the birthday of the PC. The PC was easy to use, so all of us could have a computer on our desks. Good clouds will be easy enough to use that web applications will become mainstream.

I think Google's "Run your app here" approach is better than "Here's a copy of your OS". Suddenly a developer can launch a serious web application, without having to worry about scaling, redundancy, or all the work that goes into making a service secure and reliable. It's a bit like c versus python - python reduces the power of c, but makes it an order of magnitude easier to learn and use.

It all comes down to ease. With appengine, it's easy to deploy a web app - you don't need to know how to set up iptables, tripwire, or build custom kernels. You don't need to understand how to replicate databases if your web app becomes popular, and you don't need to figure out LVM if storage becomes an issue. And all this is going to cost ten (probably a hundred or a thousand) times less than if you used your own servers. There are serious limitations, but the benefits far outweigh them in most cases.

I'm putting my money where my mouth is, and starting to migrate the services my company sells to appengine. I will be able to provide better services for less money, and still have a bigger margin. In six months, people will be saying "Remember when you had to build servers to run web apps?".

The Cloud is a fallacy and a fallic "C" (0)

Anonymous Coward | more than 6 years ago | (#24274063)

The Cloud is a made up phrase to market proprietary "solutions". Therefore the idea of a non-proprietary cloud is bull.

I am all for non-proprietary web based applications. But you can stick this Cloud into those marketing guys' proverbials.

Clouded (1)

PingPongBoy (303994) | more than 6 years ago | (#24274255)

The whole issue is a little cloudy to me.

buzzword (2, Funny)

owlnation (858981) | more than 6 years ago | (#24274605)

Ok, I hate buzzwords as much as the next person not wearing a pale blue shirt...

But I'd like to suggest "cloudware" as a potential interchangeable word for "vapourware".

For obvious reasons...

Meh (1)

paimin (656338) | more than 6 years ago | (#24274643)

I'll wait for Cloud 2.0

XenoServers is what you wanted, but they are dead (1)

LukeCrawford (918758) | more than 6 years ago | (#24276381)

abandoned after ec2 came out. EC2 does most of what it sounds like you want... except for the redundancy in providers. Personally, I'm working on building a better provisioning system for my own VPS services at http://prgmr.com/xen [prgmr.com] but the idea is that it's not that hard, even with the way ec2 is now, to take your ec2 image and run it on another xen host, or take a xen image and run it on ec2. (now getting a 'public' image off amazon ec2 and downloading it, that's hard. but if it's your image, downloading it is trivial. and amazon has all the tools you need to turn it into a plain file or tarball that any Xen provider can use)

Cloud computing should be proprietary right now (1)

Lida Tang (1296025) | more than 6 years ago | (#24281897)

Skimming through the comments here, they seems to break down into several categories:

  • Don't need it because I can do it myself.
  • It is just like some other technology.
  • Beware of vendor lock in.

I don't see any posts talking about

here is what we used cloud computing for and here are the problems with the current platforms.

This tells me that whatever this technology is, it is still early and people are still testing the water. If we want some kind of standard or open implementation of clouds, we are going to need much more people using it to explore what is good and bad about the model.

The beginning of a new technology should be about trying to find the limits of it. It is stupid to worry about open or proprietary before we even know if people will want it. The proprietary people are getting first crack at it because they think it will make them money. So let them find out what the issues are and if they can make money.

After they do your R&D for you, then you can make an open and free version. That's been the model of most successful open source projects.

Lessons learned from EC2 (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24283511)

#1... one key feature of the dedicated model for web applications is a stable, static IP address.

No it isn't. The key feature is a stable, reliable way to connect to your apps, wherever they are -- when I type example.com, I should be routed to the right place.

This means a built-in hardware load balancer, dynamic DNS, or anything in between.

Amazon's Elastic IP, for example, can take 15 minutes to switch between instances -- something like 10-12 minutes during which requests are sent to the old instance, then 2-3 minutes during which all traffic is dropped on the floor and no instance is reachable, and then, finally, traffic is routed properly to the new instance.

The only advantage is that if you don't have to do this often, you aren't paying for a hit to your DNS servers every few minutes, just in case.

#2... The API needs to be publicly available to everyone. Provide a credit card (that works and is yours) and you should get compute, storage, and RAM on-demand.

This is important -- not only are we moving beyond "submitting a ticket", but it has to be programmatic, not just point-and-click from a web interface.

For example, one could auto-scale on demand -- kill a few instances for the night, as no one's up at 3 AM, then bring them back up when you get traffic. Or bring up an extra few dozen to gracefully handle a Slashdotting.

But there's no one-size-fits-all solution. Autoscaling is nice, but consider that we might know exactly when we need power, and when we don't. We might deliberately spawn a ton of instances to handle a large batch encoding (like YouTube should have, when switching to high-def h.264), or deliberately turn off an instance when we don't need it (only really need a staging server and SVN/Trac during the day).

#3... I propose that cloud computers should support PHP, Ruby, Python, Java and the most common frameworks, libraries, gems/plugins, and application/web servers for each of these languages.

Absolutely not. That is the wrong way to go about this.

Specifically: What happens when I want to deploy an Erlang app, which uses a Smalltalk VM for a database, and forks off ffmpeg commands to do encoding? What if I like Ruby just fine, but I want to deploy, say, Sinatra + Sequel + sqlite?

I really like what Google has done with Python. All the low-level details are handled for you -- just throw a Python app up on App Engines and you're good to go. Probably not even OS-level virtualization -- could even be a language-level jail.

Which is all really great -- if you're running Python. And it's completely useless if you're not.

Compare this to Amazon -- they'll run just about anything that will work on x86/x86_64 Linux. It's up to the individual languages/frameworks to target Amazon.

So, to answer:

Essentially, a developer should be able to move between Joyent, the Amazon Web Services, Google, Mosso, Slicehost, GoGrid, etc. by simply pointing the "deploy gun" at the cloud (having used the API mentioned above to spin up instances) and go.

This would be better accomplished by extending an existing tool like Rubber [github.com] to support multiple clouds than to demand that every cloud hook into every possible framework.

After all, once we know enough about the requirements of the cloud model to actually draw up a list like this, and start working on standards, it shouldn't be too difficult to create a standard which allows Rubber (and friends, like PoolParty, Scalr, etc) to be portable without having to rewrite themselves for each cloud.

#4... Amazon is innovating with SimpleDB, Google has BigTable as solutions for the problem, but developers can't leave either cloud because neither SimpleDB nor BigTable are available anywhere else.

Again, far, far too early to create a standard.

However, we have Hadoop, we have CouchDB, and there are other, similar projects. Hadoop, at least, already has an EC2 appliance image ready. And someone has ported the Google App Engine APIs to Hadoop.

This is yet another thing that I think should be possible to build on top of the cloud, not necessarily supplied with the cloud.

I am thinking that the cloud itself should present itself more as a basic infrastructure -- like assembly language. Provide exactly enough so that companies like RightScale can start building higher-level constructs on top of it.

5. Application Services (e.g. email infrastructure, payments infrastructure)

Again, something which can be built on the cloud, and isn't required to be in the cloud. Next!

6. Automatic Scale (deploy and forget about it)

Given open APIs and sufficient control of each instance, this can also be built inside the cloud. That said:

No cloud computer automatically scales applications.

PoolParty, Scalr, and RightScale (and probably more) all provide scripts for automatically scaling based on various metrics, supporting my earlier point...

But more importantly, this is simply wrong. Google App Engines automatically scale, and automatically provide failover. Out of the box, nothing to configure. (Correct me if I'm wrong -- I don't actually have an account, so this is based on what I can glean from secondhand sources.)

7. Hardware Load Balancing

I'll file that under "nice to have". Again, no reason you couldn't build this in the cloud, and he admits as much:

Of course, if the cloud computer is open as we've described, you can build your own cloud. It's also true you can generate your own electricity from coal, if you want to bother. But why bother?

Because demanding more features raises the barrier of entry into the cloud computing game, which reduces competition. And, in particular, hardware load balancers won't exactly be effective at anything but load balancing, which makes them not as easy to cloud-ify.

It's trivial to setup, say, nginx to do load balancing. So why would you bother using hardware?

Software load balancers will get you nowhere close to the throughput required to achieve 5 billion page views per month.

Assume 30 days in a month. That's about two and a half billion seconds.

nginx can serve 8-9k requests/second. [wordpress.com]

So assuming it takes less than five hundred requests to load a page, it looks like nginx can easily handle five billion requests/month. And it can do it on just another instance, which simplifies the architecture for the cloud provider.

#8... Storage should be available to developers as a service. Where this is done today, it is done using a proprietary API and represents lock-in.

Am I missing something? Why, exactly, wouldn't the S3 API work for this? It's certainly open and documented -- the only problem would be an open implementation of it.

That's assuming you're demanding storage as yet another feature the cloud must provide itself.

9. "Root", If Required

When we're talking about something like EC2, yes, absolutely -- root is a must. More than that -- it should be possible to install any distro we want. Ideally, we should be able to compile our own kernels.

However...

By definition, cloud computers must be built on top of some sort of virtualization technology, so the developer never has "root" to the cloud, only "root" to the developer's part of the cloud.

Sorry, but as it's been pointed out before, "cloud computers" are loosely defined. If we include Google App Engines, then there is not necessarily a traditional virtualization technology in place -- it could be entirely application-based.

I would argue, however, that building on virtualization (in the Xen sense) is necessary for an open cloud, given the kind of software ecology we have today.

Elastic IP + Round Robin? (1)

Slashdot Parent (995749) | more than 6 years ago | (#24298415)

Amazon's Elastic IP, for example, can take 15 minutes to switch between instances -- something like 10-12 minutes during which requests are sent to the old instance, then 2-3 minutes during which all traffic is dropped on the floor and no instance is reachable, and then, finally, traffic is routed properly to the new instance.

Have you experimented at all with round-robin DNS records pointing to two different elastic IPs in different availability zones? If one availability zone goes tits-up, does round-robin yield acceptable performance, routing clients to the good zone?

Re:Elastic IP + Round Robin? (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24298931)

Have you experimented at all with round-robin DNS records pointing to two different elastic IPs in different availability zones?

Nope.

Of course, the long-term plan is to have at least one on hot standby (or acting in another capacity) in a third zone -- the elastic IPs are not bound to availability zones, so however much this degrades performance, that'll only last 15 minutes.

If one availability zone goes tits-up, does round-robin yield acceptable performance, routing clients to the good zone?

I guess that really depends on the client properly detecting that one of the servers is dead, and that it should use the next one.

Keep in mind, that's not the only way to do it -- dynamic DNS is still feasible, so that's another way to narrow the window during which clients have to figure the situation out themselves. And given that we're mostly an AJAX widget, we can always do our own manual client-side load balancing, if we have to.

I wouldn't worry about it too much. I think this is another case of Amazon deliberately exposing the ephemeral nature of hardware, so that we are forced to engineer around it. I've never seen an instance crash, so our ephemeral store is probably as solid as many other providers, but we backup to S3 anyway.

Re:Elastic IP + Round Robin? (1)

Slashdot Parent (995749) | more than 6 years ago | (#24303083)

Keep in mind, that's not the only way to do it -- dynamic DNS is still feasible, so that's another way to narrow the window during which clients have to figure the situation out themselves.

Doesn't dynamic DNS take more than 15 minutes to propagate though the Internet? I think most DNS servers disregard TTL values of under 60 minutes, no?

Re:Elastic IP + Round Robin? (1)

SanityInAnarchy (655584) | more than 6 years ago | (#24313017)

I think most DNS servers disregard TTL values of under 60 minutes, no?

Actually, I don't know. If you're right, then sure, Elastic IP is a much better solution.

We are using dynamic DNS for internal things (where's the DB server now?), and neither Amazon's internal nameservers, nor my ISP's, nor anything in between, seems to be slowing it down. I've got a TTL of 100 on that.

Video Game Cloud (1)

Xarin (320264) | more than 6 years ago | (#24285241)

I always thought that all those Xbox 360s and PS3s would make a great cloud when they are not being used. One could for example trade idle time for Xbox Live points to make it worthwhile. I would think Sony could cut a similar deal and render their movies on all of the idle PS3s.

A cloud by any other name... (1)

Stu Charlton (1311) | more than 6 years ago | (#24295957)

Disclaimer, I'm the chief architect of a cloud vendor.

I'd say the cloud buzz started when Google's Eric Schmidt started saying that they were in the "cloud computing business" circa 2006, and with the release of Nick Carr's "The Big Switch" book in January 2008.

Here's the question: "Why is my enterprise IT so expensive, not innovative, and hard to use and my online services so affordable, innovative, and easy to use?"

The answer could be one of three things:
1. maybe the online vendors do things differently and better in some ways, let's learn from them and change IT
2. online vendors use commodity hardware in clusters, so we all should move to that too
3. maybe online vendors know more about IT than we do, let them do the dirty work.
4 they're not, go back to sleep

So, there's a few ways to look at "cloud":
- A new way to do IT management & provisioning on demand and at scale, regardless of who hosts it (e.g. Puppet + Virtualization + a Web API)
- A large cluster of computers instead of a few large computers (e.g. Hadoop)
- Outsourced infrastructure with an API for manipulating it and a "retail channel" to pay for it with credit cards (e.g. Google App Engine, Amazon EC2)
- It's a fog. Nothing to see here, move along.

Now, my opinion:

Is a cloud always a cluster? Often, yes, but not always. Sometimes it might be several independent clusters working together (e.g. database vs. web vs. integration). Sometimes one large box makes sense (e.g. for certain database apps).

Are these buzz words to rent software? Perhaps. Much enterprise software is sold and bound to physical CPU's for $10,000 to $60,000 each. That doesn't really work well when you're virtualizing stuff and growing & shrinking it regularly.

Will everyone want to outsource? Hell, no. It can be a shell game. Security is a problem (though I'll note, we do store money in a bank, not under our bed in a mattress, these days, so our computing may make some sense). Privacy is even more of a problem.

Having said that, is it not cool that you can programmatically create a small army of Linux nodes for 10 cents an hour each via Amazon EC2? Won't it be cool to be able to broaden this idea (i.e. being able to manage large numbers of services & apps on there via an API or command line or even GUI?)

Is this proprietary? In a way, yes, in a way no. Amazon EC2 is proprietary, but there already is the open source Eucalyptus project that emulates it to be able to use the EC2 API to provision Xen containers on Rocks Clusters. There are EC2 API libraries that are mostly open source. Then there's Puppet -- a couple of years old and is a great GPL project for infrastructure automation (i.e the new CFEngine) which fits into what the cloud is trying to do. Zenoss is a few years old and is a great management platform that some cloud vendors hook into. Elastra is working to open source tools for its ECML and EDML languages to build a cloud package / design / platform ecosystem.

Are online services cheaper and easier to use than the enterprise? In some cases, certainly. Some internal IT departments require a $10k+ tax on top of server purchases to cover IT installation and provisioning costs, and then take 2 weeks to 2 months to bring the server online. Using an API to bring up a server up , auto-configured as part of a MySQL cluster, in under 30 seconds, is quite a relief.

Re:A cloud by any other name... (1)

Slashdot Parent (995749) | more than 6 years ago | (#24298555)

Are online services cheaper and easier to use than the enterprise? In some cases, certainly. Some internal IT departments require a $10k+ tax on top of server purchases to cover IT installation and provisioning costs, and then take 2 weeks to 2 months to bring the server online.

This, I think, is the Big Deal, here.

My current client, in the mid '90s, embarked on a huge digitization project. They hired an external vendor to scan hundreds of thousands of documents for them, and the deliverable was approximately 100GB of TIFF images that needed to be OCR-ed into PDF. To accomplish this, they bought 5 servers, 5 Windows licenses, and 5 copies of Adobe Acrobat Capture (or whatever it's called) + data center costs. I think it took a month or two to process all of those TIFFs.

If this client had to do such a project today, assuming they were OK with their documents being outside the corporate firewall (which is a HUGE assumption), I would have done this using EC2/S3/SQS. I'd build a quick script that uploaded the TIFFs to S3, plopped a metadata message on the queue (start/end page number for each document, etc.) for each document, and then I'd build a script on an extra-large CPU intensive that pegged the CPU with OCRing, popping a message off the queue, grabbing the TIFFs from S3, and plopping the PDFs back to S3. I would just add more and more OCR instances until the processing rate was acceptable, and when the project was over, I'd download the PDFs and be done with it.

I'm guessing that using EC2, the project could have been done in a week, and the processing done in a day. It probably would have been less than 1/10th the cost, too. Do you know what my client did with those servers after the PDF conversion? They just left 'em in service in case they needed to convert any more TIFFs into PDFs in the future (they did not) and promptly forgot about their existence. So they paid for all that hardware, software, electricity, and data center space, for 10 frickin' years, when they could have paid for it for 24 hours.

I'm convinced that cloud computing is going to be huge. Not necessarily the EC2s of the world, but even inside corporate data centers. Using VMWare, or some of the other virtualization packages, a company can really scale down its hardware requirements. Currently, the servers supporting business-hours computing and after-business-hours processing is on separate hardware, with much of that hardware sitting idle for half the day. Why not use resources from the idle webservers for overnight batch processing and vice versa?

That's exactly what the NY Times is doing. (2, Interesting)

Stu Charlton (1311) | more than 6 years ago | (#24299573)

The NY Times converted [nytimes.com] 4 terabytes / 11 million TIFF based images & articles from their archives in 24 hours using 100 EC2 instances. And continue to do it to this day. Cost? A couple hundred dollars.

Re:That's exactly what the NY Times is doing. (1)

Slashdot Parent (995749) | more than 6 years ago | (#24302891)

Thanks for that link. It's great to have my curiosity settled regarding whether or not they could have processed all of those TIFFs in 24 hours on EC2.

Do you happen to know which OCR software they used? It wasn't clear to me from the article.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?