Cloud Architecture is becoming more and more relevant in the software industry today. A lot of efforts are becoming less about software and more about cloud software. The whole gamut of cloud technology; platform, service, infrastructure, or platforms on platforms are growing rapidly in number. The days you didn’t need to know what the cloud was are rapidly coming to an end.
As I move further along in my efforts with cloud development, both at application level and services levels, I’ve come to a few conclusions about what I do and do not need. The following points are what I have recently drawn conclusions about, that cause frustration or are drawn from the beauty of cloud architecture.
REST is King, Period
When I use REST in this context, I don’t just mean a nice clean URI or “not SOAP”. I’m talking about the whole entire enchilada of REST Architecture Principles. A good place to start learning about REST is the Wikipedia Article. Other key resources to check out include; Roy T. Fielding’s Dissertation, specifically chapter 5, Principled Design of the Modern Web Architecture, and the O’Reilly Book RESTful Web Services.
REST Architecture is fundamental to the web and the fact that the web is continuous in uptime. The web, or Internet, doesn’t go down, doesn’t crash, and is always available in some way. REST Architecture and the principles around it are what enables the web to be this way. The cloud seeks to have the same abilities, functionality, and basically be always on, thus REST Architecture is key to that underpinning.
Core Development
Currently I do most of my development with C# using the .NET Framework. This is great for developing in cloud environments in Windows Azure and Amazon Web Services. The .NET Framework has a lot of libraries that work around, with, and attempt to provide good RESTful Architecture. However, there are also a lot of issues, such as the fact that WCF and ASP.NET at their core aren’t built with good intent against RESTful Architecture. ASP.NET MVC and some of the latest WCF Releases (the out of band stuff) are extensively cleaning this up and I hear that this may be sooner than later. I look forward to have cleaner, bare bones, fast implementations to use for RESTful development in Azure or AWS.
The current standing ASP.NET (Web Forms) Architecture is built well above the level it should be to utilize REST Architecture well. Thus it creates a lot of overhead and unnecessary hardware utilization, especially for big sites that want to follow good RESTful Practice.
WCF on the other hand had some great ideas behind it, but as REST increased in popularity and demanded better use of the core principles the web is founded on, the WCF model has had to bend and give way some of its functional context in order to meet basic REST Architecture.
Anyway, that’s enough for my ramblings right now. Just wanted to get some clear initial thoughts written down around Cloud Architecture needs for the software developer.
P.S. This is Cloud Architecture, too 
Image credit: Inhabitat
(Cross-posted @ Composite Code)
Adron,
Some good stuff here, but I am curious about the REST part. I too use REST style architecture but not in all cases. Can you elaborate on why you think the REST architecture is key to cloud computing. The internet or web is always up part doesn’t seem to jive in my mind in context with REST. The internet is always up is because of redundancy in network infrastructure and the redundant routing nature of TCP/IP, nothing to do with REST. Web sites themselves are not always up and URL’s are not always available. I never really thought the Web was a good example of REST style architecture even though it is quoted as such a lot.
markg
Adron,
Really appreciated your paper. REST is king, really? I think REST is mandatory but doesn’t really address cloud big challenges e.g. billing and scale up/down.
REST doesn’t give any guidelines on how one may architect servers to match demands, furthermore, what server ‘types’ to power on/off according to SLA.
What do you think ?
Ch4
Mark Griffin & Chuyen – I should have wrote a “clause” in the entry. I’m speaking from the perspective of the software that runs in the cloud. REST is by far one of the cleanest architectural approaches one can take for services (and hypermedia in general) when using the cloud.
Mark Griffin – As for the REST being an example of the web, it IS the web. I’m not sure why you state that it isn’t a good example. Could you elaborate? REST is also more than just merely services, it defines the way hypermedia is utilized in a stateless manner throughout the web. It allows for the resiliency in the fact that parts can fail (just like the TCP/IP) but other parts don’t fall over solely because one service isn’t available at a particular time. i.e. REST offers significant loose coupling for software using it as an architectural basis. SOAP tightly couples one to implementation, and other architectural elements that have been used to try to meet the demands of the web & services in the past just haven’t held up over time.
I’d be happy to elaborate further pending time & if you’re interested in reading a break down of the overall architectural ideas. (They’re also in available in Roy’s Dissertation if you have that kind of time http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
Adron,
I agree with your first point about REST and the cloud. My beef with the web as an example of REST architecture is that it oversimplifies the problem space. Some of the “web” applications you speak of are actually Web Services(SOAP based) providing the actual service. I don’t consider the ability to open a web browser and display a web page an example of REST, maybe it is in simple terms but I don’t think that’s a valid comparison when speaking about REST based services and SOAP based services.
“SOAP tightly couples one to implementation”. When you say implementation I’m assuming you mean to the fact that you are using SOAP as the implementation otherwise a SOAP based service does not bind you anymore to an implementation than a REST service does.
I’m a fan of both REST and SOAP based services used in the right places. I just think the web as an example conjures up the wrong image. I get what you are saying about the nature of the http protocol, tcp/ip and all that but to me that’s just a part of the problem space.
markg
I read the blog and responses with interest.
I work for a company which has a traditional client/server premise based product. Its a classic 3-tier design in J2EE. App content delivered in through the browser (thin client), app logic held in an XML repository (configured using desktop installed developer tools), and a zero-business logic session runs with J2EE container to execute the application logic in runtime, in concert with the client. The XML definitions loaded into the session at run time.
The architecture uses lot of integration techniques to aggregate data in the end-user application.
Moving this ‘traditional’ application to a cloud architecture is causing masses of internal debate.
Its worth noting that the application integrates to telephony platforms to deliver a CTI-enabled application. This seems to me, unless you can correct me, to be an area where REST may not help?
Any high level comments are welcome!
Paul.