The really exciting news here is the bit at the end:
"I am 100% convinced that if there were a general-purpose platform for running behind the firewall to automate scaling and deployment and take IT out of many loops, there are a whole lot of enterprises who’d love that kind of elasticity in their infrastructure.
Machine virtualization is a big deal, obviously. Lightweight lockin-free data-center virtualization might be bigger, I think."
He's right! At Loopt there are many, many things we can't use conventional, public, cloud offerings for because of privacy and/or security concerns. I would jump immediately at the opportunity to install 3-5 racks of Sun hardware and/or software, and get my own mini-cloud to expose to Loopt developers.
Right now the closest I can get is VMWare, but even it is still much to close to the metal. Something like this could truly revolutionize how private data centers are managed.
Imagine:
* Need a QA environment for a while? Provision it. Drop it when done.
* Need to shift the allocation of processing resources between various internal tasks and services as load and usage varies? Script it. Done.
I'm sure there are tons of use cases I'm missing. Those are just my top two.
Using REST seems silly. Or rather, not necessarily silly, but not very significant, either. Bray himself admits that using REST + JSON was basically arbitrary:
Simply because we wanted a bits-on-the-wire interface. APIs, in the general case, suck; and are really hard to make portable. Bits-on-the-wire are ultimately flexible and interoperable. If you’re going to do bits-on-the-wire, Why not use HTTP? And if you’re going to use HTTP, use it right. That’s all.
There's no official announcement online from Sun, other than a bits written about CommunityOne. Most of the information has come from this post by Tim Bray where he writes about his experience on the project. Everything I've read is about the API, but where's the service? They're already 3 years behind Amazon so there's no rush. Wait a few months and announce it all at once.
Not sure about this. I am currently building stuff on Amazon and only use the REST interface. Even when it comes to needing my own Java API, converting to Java to XML isn't a big deal anymore.
It would be good to see the proportion of SOAP/REST usage there. WS/SOAP is good but in the beginning when a lot of innovation is going on there will be some flux and supporting both would be costly.
WS/SOAP is self-documenting and can have client-side code fully auto-generated in a 100% reliable manner. REST, as it is not even near a documented standard besides "use HTTP verbs" not so much.
With the right toolkit WS/SOAP is basically automated on the server and client-side with no work involved.
Until REST gets there, enterprise applications and developers will still prefer WS/SOAP en-masse simply due to tool support.
Yeah - I'd agree in general. However, I'd argue that SOAP isn't really there yet either - it's more progressed, but issues such as versioning and lifecycle management aren't something many orgs really have a handle on yet.
So I guess my query is - How will these orgs feel about Sun moving to REST when they are still investing/maturing a SOA based on SOAP?
As far as I am aware automatically scalable infrastructure is not something that was available until recently, nor is it subsumed by the 'net/web' designation. There is more to it than the web. Have I missed something?
Automatically scalable infrastructure has been available, and in use, I'm sure for quite a number of years. It's nothing new in terms of software.
AWS etc selling such a service, is newer, but it seems like cloud is just being used now as a new "web 2.0" buzzword. "Upload your photos to the cloud!" "Cloud based solutions" "Your music in the cloud" etc etc
Cloud is a vague term, but like "web 2.0" is sorta does refer to some specific things. "Cloud" seems to be overloaded to mean both web services, outsourced virtual datacenters (e.g. EC2), and using virtualization/cluster technology in your own datacenter.
I think programmers hate terms like 'cloud' because they're fuzzy, ambiguous and inspecific. Marketers like them for the same reasons. :)
I understand your considerations, but the article has nothing to do with software-as-a-service type 'clouds'. This is purely on the infrastructure-on-demand and platform layers, and as such actually new, as you also agreed with. Sorry if I am getting a bit technical but Clouds and REST happen to be very close to my research subject. I am one happy bunny today seeing their combination put forward by a major player.
Another thing to keep in mind that this is Tim Bray we are talking about. He can hardly be considered a peddler of hype.
Hey np. I probably shouldn't have commented on this particular one. I think it was a combination of articles and this one just pushed me over the edge today. The last few were far less worthy.
I agree there is good work going on. "infrastructure-on-demand" or "elastic-infrastructure" sounds so much nicer (to me) than 'cloud' though.
"I am 100% convinced that if there were a general-purpose platform for running behind the firewall to automate scaling and deployment and take IT out of many loops, there are a whole lot of enterprises who’d love that kind of elasticity in their infrastructure.
Machine virtualization is a big deal, obviously. Lightweight lockin-free data-center virtualization might be bigger, I think."
He's right! At Loopt there are many, many things we can't use conventional, public, cloud offerings for because of privacy and/or security concerns. I would jump immediately at the opportunity to install 3-5 racks of Sun hardware and/or software, and get my own mini-cloud to expose to Loopt developers.
Right now the closest I can get is VMWare, but even it is still much to close to the metal. Something like this could truly revolutionize how private data centers are managed.
Imagine: * Need a QA environment for a while? Provision it. Drop it when done. * Need to shift the allocation of processing resources between various internal tasks and services as load and usage varies? Script it. Done.
I'm sure there are tons of use cases I'm missing. Those are just my top two.