We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

How Microsoft saves Cloud Computing with Microsoft SOA

Vote 0 Votes

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 where people do this because they do not have money for the right size and another store. Well, this also 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.

Why would anybody think about altering working SW architecture, especially if offered platform is wrong (from the architecture perspective)? Is this for pleasing the Cloud provider? We are the clients; we have to be served with what we want, not with what somebody can provide.

If Cloud Computing is that immature to demand changes in our working SW architecture, its place is somewhere in the garage or backyard until it grows up to the market level.

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 proposes 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 of developers. However, taking advantage of our economic problems like cost and absence of professional skills for the clustered environment where effective fail-over, state and transaction management are available, Mr. Loren suggests 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.

Really, has anybody performed any numeric estimation on financial benefits of moving IT into cloud versus financial losses resulted from frequent and "regular failures", lost customer trust, lost competitive advantage because of slow reaction to the market changes, passive instead of proactive IT contribution into corporate business values, loses in reputation because of collocation with 'wrong' neighbours (I am not event talking about additional security risks that consumers do not tolerate)? If IT that builds the cloud does not know how to do such estimation, ask Business and be ready for "regular failures"; common wisdom tells us: "do not be penny-wise and pound foolish".

Again, WE are the consumers, we do not care and should not care about convenience and benefits of those who provide service to us; this is their job. If I design loose-coupled services, they must run as loose-coupled on any platform and in any environment. If an environment cannot provide for it, this is the wrong environment and results of my application may be unpredictable. Is this the reason why some cloud vendors offer a contract-free "service"?

I'd like to complete this observation with a question:
what do you think your business prefers:

a 'non-locked' to vendor and uncontrolled environment for your business' applications
a partially-locked (considering how many different vendors presented in the corporate IT anyway) and controlled environment or your business' applications?

When you figure it out, please, let me know.


1 Comment

| Leave a comment

Nice post with a strong summarization in the end: "WE are the consumers, we do not care and should not care about convenience and benefits of those who provide service to us; this is their job. If I design loose-coupled services, they must run as loose-coupled on any platform and in any environment. If an environment cannot provide for it, this is the wrong environment"

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives