Cloud Insanity – Focusing on all the wrong things, again
popping..I small number of bloggers keep reminding the industry of the lessons learned from SOA. We keep reminding people that to succeed in the cloud there must be a focus on architecture. Well it doesn’t sound like many people are listening. The same patterns of destruction that caused so many SOA failures are apparent once again as organizations look to the cloud as their next savior. Here are the patterns that I am referring to:
- People arguing semantics
- Vendors rebranding everything as the cloud
- People taking a technology first approach instead of a business first approach
- IT talking to the business in technical terms
- Resistance to change
- Ignoring organizational change management, thus not addressing the resistance properly
I could go on but you get the point. Each of the patterns I mentioned above were issues that made SOA Initiatives very challenging or flat out fail. I have been seeing so much chatter on Twitter about cloud definitions that I have one definition of my own to offer.
Cloud Insanity – To repeat the same behaviors that caused SOA to fail and expect a different result.
Let’s get back to the basics folks. Public clouds are off premise infrastructure in a shared environment. Your stuff is running on computing resources with other people’s stuff. Private clouds can be on or off-premise but are not shared. In other words, you know what servers your stuff runs on. There is no need to get more granular than that. There are a variety of “as-a-Service” terms. Just remember that PaaS (Platform as-a-Service) is infrastructure on a proprietary platform which forces you to code in a certain language. Infrastructure as-a-Service is infrastructure that allows you to build your stuff in any language that you choose. Software as-a-Service is exactly that, software that you pay for that runs somewhere else written by somebody else.
The definitions do not need to be more complicated than that. What we should be focusing on is business drivers, risks and issues, standards, case studies, and other productive conversations that might help somebody actually deploy something in the cloud.
The other issue I see is many people are looking at the cloud because of the hype, not because they have business justification. If you are thinking about moving your complex legacy systems to the cloud, you might want to rethink that strategy. Any value that a business may gain from moving old stuff to the cloud will likely not be realized because of the huge costs and complexities of trying to migrate something built for on-premise to off-premise. It is best to deploy new systems or services to the cloud. They can be architected for the cloud and do not require IT to spend tons of money converting things that already work. Instead, IT can add value by spending time on new things and deploying them in a more efficient manner.
So let’s get back to the basics. Lay off the semantic discussions and start encouraging discussions that benefit those that are trying to deliver. Share the lessons learned, both the good and the bad. Talk rationally about risks such as security and compliance. Don’t make blanket statements like “the cloud is too insecure” or “never put anything mission critical in the cloud”. Instead, highlight the reasons why you believe those statements may be true and let’s collaborate about it. There are companies that are 100% in the cloud; mine will be one of them. Most of these companies are startups and don’t have a data center. They are motivated to use the clouds for reasons such as speed, limited capital, and no politics. So it is obvious that these blanket statements don’t apply to all. If you are like most companies and you have a data center, it is usually wise to keep your sensitive data behind your firewall. If you did succeed with SOA, you can access the data via data services outside your firewall and leverage a hybrid public/private cloud solution that gives you the best of both worlds: low cost and high scale in the public cloud, security and compliance on-premise.
These are the discussions that need to be taking place. Let’s debate how to tackle security and compliance, how to manage hybrid solutions, how to provide reliability and scalability, how to prevent latency, and many other important topics. But enough of the Cloud Insanity. IT has been banging it’s head on the wall for too many years. Let’s try a different approach.
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
I think the issue pretty much comes down to organizations doing “science experiments” rather than architecture when it comes to doing these things. There’s no specific governance driving the behavior so the technology is being miss applied — under applied (risk adverse) or over applied (hammer looking for a nail) or mal-applied (round peg in a square hole).
Like you said, get back to basics of business drivers and architecture — quite frankly it doesn’t matter whether it’s on premise or off… a service or not… what matters is “Why’s” and “What’s” and “How’s”…
Why this path vs. that path? Under What conditions is it acceptable to do this vs. that? How is it going to measured in terms of success?
And then not play favorites… if the architecture principles say that X requires a specific level or type of security and that generally Q sort of service level, then you shouldn’t dismiss doing it on the “cloud” or as an outside service if it meets the requirements… too many times I see the implement first because it’s “cool” and then back into the requirements later…
Let’s start with the business drivers and requirements first. {sigh}
You are really onto something Mike – we’ll see where this goes next. I have always been of the mind that the future of the cloud is the past of SOA and Virtualization for that matter – one of proliferating a bunch of services, or VMs, or cloud-based services/software/environments for short-term gain.
It is easy to start, and then it becomes evident that some real architectural thought, validation and mitigation of unexpected issues and use-based cost has to take place if we are going to trust it for enterprise use. SOA overcame a generation of half-baked services and is now working responsibly for companies, no matter what they call it.
The same will apply to services thrown into the cloud without an architectural plan and business justification. Hopefully this time we’ll be able to keep perspective.