In the IASA’s August “Special Double Issue: TOGAF 9 and The Cloud”, Julian Keith Loren, introduced as a programmer, CTO and Chief Executive Trouble-maker, published an article with the title very well matching his introduction: “Cloud Software Architecture: The Quest of Zero-Delta, No-Lock-In, Hybrid-Deployment-Ready Applications” (ouff!). I hope I’ve not missed any other accolades of such applications.
Mr. Loren places Microsoft’s Azure in one line with “Cloud server instances from Amazon’s EC2, Terremark’s Enterprise Cloud, Rackspace’s Mosso Cloud Server” when noticing simultaneously that “Final pricing for Microsoft’s Azure is not yet available”. It seems we have a new ‘black cat in the sack’ comparable to Amazon’s EC2 only because the “Made in Microsoft” label is on the sack. This is not all, listed providers, according to Mr. Loren, “are provisioned on a no-lead-time, no-contract, pay-only-for-what-you-use basis”. Of cause, we all are dreaming to send our business applications to Cloud with no contracts, i.e. without any obligations from the Cloud providers. Some IT people think that business people are not that smart, but, believe me in this case, business people are not that stupid to work without contracts…
With regard to the cloud’s feature of “No-Lock-In” single SW vendor, Mr. Loren says: “It turns out that inconsistencies between offerings, requirements for application modification, and fundamental differences between cloud server instances and datacenter service instances may prompt you to alter your software architecture. This is where the trouble can start. Without employing exceptional care, you can end up altering your software architecture to match the requirements of the specific provider.” I share this alarm and very thankful to Mr. Loren for it; I see it happens in my present project and I do not hesitate using strong words to those who even think about a possibility of altering architecture on these grounds. If people are in their mind, they will not buy new shoes one size smaller than they wearer only because these shoes are in the store. I can understand only one case – people do this because they do not have money for the right size and another store. Well, this means they will pay three times (if not more) – for the wrong size, for the feet healing in wrong shoes and for fixing the wrong shoes where possible.
Well, let’s return to Azure. Mr. Loren references to Mr. Yousef Khalidi, Distinguished Engineer at Microsoft, saying “[Yousef Khalidi] insists that cloud server instances are fundamentally different from their traditional counterparts. He recommends that applications deployed to the cloud be ‘as stateless as possible’ and incorporate excellent failure handling. This advice is not surprising in the cloud environment where failure is expected to occur frequently”. Further in the article Mr. Loren outlines: “Fail-Safety: expect high rates of failure. Design your application to anticipate regular failure and handle it…. Stateless: your service should be as stateless as possible. If ’statefulness’ is necessary, it should be abstracted from the service.”
It is a great set of tips, Mr. Khalidi. Now we know that in Azure we should “anticipate regular failure” and handle it somehow. Why somehow? Because when regular (probably, non-Microsoft) architects design their applications they make them with as low as possible rate of failure, i.e. mentioned “high rates of failure” come from the cloud environment, not from the applications. We also thankful to Mr. Khalidi for the advice of never placing our SOA services into the cloud (I think, it was Azure meant in this case). As we know, any SOA service may be implemented as a process but processes, I hope that Mr. Khalidi is with me in this, are statefull by definition. I would never ask architects, designers or developers to screw SOA services only because someone cannot support them properly. Why? Because competition for the consumer is the one of the fundamental principles of service orientation – if you cannot meet consumer’s needs, you loos the consumer and eventually get off the market while we will go with another service provider.
Let me join Mr. Khalidi’s stream of advices and notice that a Microsoft’s service is not a SOA service in OASIS SOA definition ( BTW, OASIS reference architecture for SOA is recognised in 2009 by the OMG and The Open Group, but not its TOGAF(!) team, as the reference architecture foundation for all Standards Bodies’ SOA standards). In Microsoft, a service is ‘out of process’ and ‘local’ programme entity, i.e. if an implementation of particular business function requires a distribution over more than one server, it cannot be handled by one Microsoft service. Now, can you imagine a scale of the problem for cloud deployment where the designer of SOA solution does not know where and how the business services may be deployed by the cloud provider? This appears similarly to a well-known picture where a creature bites its own tail. So, in Microsoft cloud, forget about SOA deployment; use RPC instead and Azure guarantees no troubles (if you handle regular failures, of cause).
At the end, Mr. Loren propose a “Possible Cloud Software Architecture Approach” based on tight-references and symmetrical scalability. He says: ” Because the sizing of Cloud Server Instances is ‘bigger than absolutely needed’ it is likely that there will be space to deploy multiple services in one instance”, which makes sense to the cloud provider but also may be a reason for frequent failures predicted by Mr. Khalidi. I have recognised this uncontrolled co-location as one of the major potential business problems a year ago in my BLOG. Then, “In your internal server instances, it usually makes sense to deploy one service per instance, keep those service loosely coupled, and scale them asymmetrically based on load.” Yes, this is what has been identified as the Best Practice by millions developers. However, taking advantage of our economic problems like cost and absence of professional skills for clustered environment with effective fail-over, state and transaction management, Mr. Loren suggest using “cheaper” cloud but “in fashion that is tightly-referenced and … scaling those services [deployed on the cloud server instances] combinations symmetrically. This sounds like heresy in SOA world… but giving the set of constraints…it may be a valuable option”. Oh, yes, I’ve just ordered a Cadillac but have to be happy with a Mini because it has a moon-roof.
Source:-http://www.ebizq.net/blogs/service_oriented/2010/09/how_microsoft_saves_cloud_computing_with_microsoft_soa.php
