Building The Fact Of Network Cloud Computing


Mike Kavis Posted by Mike Kavis

I have found that with cloud computing there seems to be a ton of “expert” advice but it is not coming from people who are actually building solutions in the cloud.  Many giving “expert” advice are seasoned veterans and talented people, but they are simply stating opinions not backed by any facts.  Most have simply read about the cloud’s pros and cons, formed their own opinions, and now claim their opinions as facts.  Where are all the architects and engineers that have actually designed and implemented real solutions in the cloud?  Shouldn’t we be listening to their opinions (and I am not talking about the vendors’ engineers)?


Funny Pictures

So here are some of the generic statements (aka “facts”) that I see daily:

  • Cloud is not secure
  • Application  XYZ failed therefore the cloud is a failure
  • You are crazy if you put mission critical applications in the cloud

I could go on and on but you get the point.  So let’s discuss these “facts” one at a time.

Cloud is not secure

This one drives me nuts!  I heard a well respected industry analyst at a well respected conference declare “I just don’t understand how you can put customer data in the cloud.  When you buy Amazon, you don’t buy security”.  I raised my hand and asked, “When you buy a rack of servers from IBM, are you buying security?”.  The point is, you don’t buy security, you architect for it.  Whether you are using a SaaS, IaaS, or PaaS provider, you must understand what security features are addressed, what isn’t, and what the risks are.  Then you must design to mitigate those risks.  It is not different than what you should be doing on-premise.  Understand your requirements, and build (or buy) the appropriate solution.  So to sum it up, the cloud by itself is often not secure enough.  You may outsource your infrastructure but don’t outsource your brain.  There are still things you must do to secure your systems and services in the cloud.

Application XYZ failed therefore the cloud is a failure

Whether it is GMail, Tmobile losing Sidekick data, Ma.gnolia database crashes, or Coghead going out of business, any failure of an off-premise solution seems to feed the myth cloud computing is too risky.  However, we continue to fail miserably each day with our on-premise solutions but we can keep it from the press because it is behind our firewall!  In each one of the above mentioned failures, the issue lies with operational issues on the side of the provider and not issues with the cloud infrastructure itself.  I would argue that GMail, which is free, is at least as reliable than most corporate Microsoft Exchange implementations (at least for the companies that I have worked for in the past).  Also, if you are using SaaS solutions, you should have a mitigation strategy in place for lost data.  Outsource the business processes but not your brain!  You still need business continuity, disaster recovery, record retention policies, etc.  And when did on-premise become so perfect? How many companies do you know keep the lights on by having employees run around with duck tape and bailing wire plugging up the holes in the bottom of the boat.  Let’s face it, most failures are due to issues in architecture, design flaws, missed requirements, human error, weak controls, or poor implementations.

You are crazy if you put mission critical applications in the cloud

This one really drives me nuts.  The problem here is semantics and we really should be careful what we say.  It is one thing to say mission critical apps don’t belong in the public cloud and another to say it doesn’t belong in any cloud (which is how it often gets interpreted).  But even the term mission critical means different things to different businesses.  Even though you and I might not see Twitter as a mission critical application to our business, it is for others.  Some companies exist solely because they leverage Twitter’s APIs to deliver their products and services.  Now we all know Twitter’s track record of reliability.  But their performance and up-time was failing miserably before they moved to the cloud.  It improved once they migrated to Amazon.  Twitter’s problem is a flawed architecture, it is not a cloud computing issue.  I have written in the past about our secure hybrid cloud solution for processing micro-payments.  As a startup, I would argue that I would be crazy not to build this in the cloud.  In an era where it is difficult to raise money, my costs would increase ten-fold had I opted for an on-premise solution.  I would have to build or lease at least two data-centers and staff them accordingly.  Instead I can use a combination of cloud vendors coupled with a sound architecture to secure these transactions and meet all regulatory requirements.  If I already had an existing data-center, I would not have been forced to look beyond the opinions of others and try to solve the security and compliance requirements that my business required.  I just think that many people’s opinions about the cloud are focused primarily on their specific business models or domains.  So what may be true for their world does not necessarily apply across the board. We tend to generalize too much.

Summary

There are many opinions out there about cloud computing and there are many smart people offering them.  Unfortunately, many of these these smart people have not rolled up their sleeves and tried to solve real business problems in the cloud (nor do they need to).  In my case, as a matter of survival, we had to find out for ourself.  By no means, do I consider myself an expert in cloud computing.  But I do believe that spending a year actually working on delivering enterprise solutions in the cloud from scratch does entitle me to challenge the opinions that are deemed facts.  At the end of the day, it all comes down to knowing your business and technical requirements and applying sound architectural practices to provide a secure and compliant solution, whether it is in the cloud, on-premise, or both.

Comments

About the Author: Mike Kavis is a veteran Chief Architect with over 23 years of IT experience including distributed computing, SOA, BPM, data warehouse, business intelligence, and enterprise architecture. Read Mike's blog at Enterprise Initiatives.

Leave a Reply