Somewhere back in the mists of time the term SOA (standing for Service Oriented Architecture) was hijacked by the likes of IBM, Sun Microsystems, Oracle, BEA and others to mean a Java Web services implementation of a SOA solution and now you can't mention the term SOA without everyone assuming that is what you mean. While these implementations of SOA are a perfectly valid implementation are they the only possible implementation? Well NO! Can the approach be applied elsewhere to other implementations? Well YES but only if you get yourself out of the rut of thinking that SOA mandates a Java Web Services implementation. So just for a few moments suspend your preconceptions of what you think SOA is and approach what follows with an open mind.
In the rapidly emerging world of cloud computing everything is viewed as a service. The clue is in the naming - Software as a Service, Platform as a Service, IT as a Service, Infrastructure as a Service, Database as a Service, Storage as a Service, etc, etc, etc, in fact everyone seems to be rushing around trying to define their own as a service acronym. So what do these services look like. Well if done properly as well as the service itself there should be a clearly defined interface specification on how to access and consume the service. There will be one or more service level agreements defining the level of service that you can expect including such things as response times, permitted consumption levels, costs, up-times, recovery times, etc. Finally you will need a mechanism whereby each service can publish it's self and it capabilities for consumers to discover the service and attach to it. Typically this is via a service repository. New services can then be defined as unique entities or by building on or adding to an existing service or services - a composite service. These composite services will have their own unique service definition and SLA(s).
Now these services can be grouped into layers of abstraction as we build from base IT or infrastructure services through data and knowledge services to business services with each layer building on the layers below and adding functionality.
Hang on a minute this sounds exactly like a Services Oriented Architecture but as yet no use of the works Java or Web Services. So can Java Web Services exist in the new Cloud SOA world? Of Course they can but this Cloud SOA world is not dependant on Java Web Services for it's existence.
Time I think for the enterprise or cloud architects to go and dust off this SOA reference architectures and governance from the past from the likes of BEA and IBM and give them a refresh for the new world of clouds. The only question that remains is do we need to come up with a new acronym for it or do we reclaim the SOA acronym for what it originally meant before it was hijacked.
Thursday 26 April 2012
Thursday 19 April 2012
Cloudbusting - Dispelling the myths of cloud computing
All new technologies and approach generate hype and excitement in the industry, particularly those with any merit or likely to trigger significant change. Cloud computing is no exception. In that hype myths and rumors develop often encouraged by the vendors of the technologies to help generate what they hope will be a frenzy of buying of their products. Again cloud computing is no exception. While I have no doubt that cloud computing is already in the process of revolutionising the way we will consume IT resources and is critical to reducing the environmental impacts of our ever increasing ravenous appetite for computing resources in this, and following posts, I will aim to identify some of the myths I believe have grown up around cloud computing and why I believe they are myths. This in turn to should help you to make more effective use of the technology within your business.
Myth 1 - Cloud Computing Reduces Complexity
Absolutely NOT. In fact the opposite is try. In order to add virtualisation (network, server, storage, middleware, database), self service, automation and billing requires adding considerable complexity to the data centre, and remember all of this needs to be managed adding further complexity. The point is that through self service and automation of the data centre the goal of cloud computing is to hide that complexity from the consumer of the service. In his book "Does IT Matter" Nicholas Carr makes the comparison between the history of electricity generation and distribution to utility computing, a concept which has developed into what we now refer to as cloud computing. In the early years of electricity individuals would put a generator in their yard to power their house. What could be simpler? Now we have a massively complex generation and distribution system involving multiple ways to generate power, multiple locations for power generation and a distribution system that can manage national and international distribution, respond to the ebb and flow of demand and heal itself. How much more complex is this than a simple generator in the yard? Yet the modern approach hides all this complexity from the consumer as well as delivering levels of resilience and continuity of service that we could never have been able to achieve with a generator in the yard.
Myth 2 - Cloud Computing Reduces Cost
As mentioned above cloud computing adds complexity and with that complexity comes cost. Cloud computing on it's own will not deliver cost reduction in fact it has the potential to significantly increase costs. What delivers the majority of the cost saving in a cloud environment is the increase utilisation of resources so allowing the data centre to do more with less. This comes from consolidation and more intelligent use of resources (eg. If my workload falls and I can migrate workload onto a smaller number of servers I can power down the currently un used servers and run the remaining servers at full capacity). The other part of the cloud approach that helps to reduce cost is the standardisation and automation. If you have many repeated tasks that are the same or similar then automating them will remove the need for human intervention and associated cost. If however you have a large number of bespoke tasks then the overhead of automating them will typically be higher than doing them manual and so costs increase. For this reason it is essential that you have in place the framework for standardisation, governance, policy and process. This is often the Achilles heal of private clouds.
Myth 3 - Cloud Computing requires virtualisation
No where in the NIST definition of cloud does it state this. It talks about on demand self service, broad network access, resource pooling, rapid elasticity and measured service as well as talking about multi-tenancy, resource re-allocation, abstraction and dynamic assignment and the fact the the user can not dictate the exact location of the resources he consumes but NONE of this requires virtualisation. With the addition of self service provisioning and metering this can be achieved with a good old fashioned cluster! I often see, particularly in the world or development test, QA and support, users pushing back on cloud based solutions because they need to run and test their applications on "bare metal" rather than on virtual machines which often leads to machines dedicate to a task lying idol of much of their life. Using self service and automated provisioning these machines can be added to a pool that can be shared over time with multiple projects hence improving their utilisation and becoming part of the cloud with no virtualisation in play.
Myth 4 - ITaaS cloud computing will reduce server sprawl
Many of you will have heard of the term virtual server sprawl. The effect of making the provisioning of virtual servers quicker, easier and self service without the correct process, policy and governance in place will result in the rapid explosion of virtual server creation, far more rapid than an environment based on physical servers could support. While for the successful adoption of cloud computing within an organisation it is important that the consumer can fully benefit from the agility that the cloud can bring it is also important to ensure that the mechanisms ar ein place to ensure that there is not an uncontrolled proliferation of virtual servers.
I hope that this taster and the more detailed posts that are to follow will help you to see your way through the fog and mist that have become trapped under the cloud and allow you to navigate your way to a more successful deployment and or use of the technology for your business.
Myth 1 - Cloud Computing Reduces Complexity
Absolutely NOT. In fact the opposite is try. In order to add virtualisation (network, server, storage, middleware, database), self service, automation and billing requires adding considerable complexity to the data centre, and remember all of this needs to be managed adding further complexity. The point is that through self service and automation of the data centre the goal of cloud computing is to hide that complexity from the consumer of the service. In his book "Does IT Matter" Nicholas Carr makes the comparison between the history of electricity generation and distribution to utility computing, a concept which has developed into what we now refer to as cloud computing. In the early years of electricity individuals would put a generator in their yard to power their house. What could be simpler? Now we have a massively complex generation and distribution system involving multiple ways to generate power, multiple locations for power generation and a distribution system that can manage national and international distribution, respond to the ebb and flow of demand and heal itself. How much more complex is this than a simple generator in the yard? Yet the modern approach hides all this complexity from the consumer as well as delivering levels of resilience and continuity of service that we could never have been able to achieve with a generator in the yard.
Myth 2 - Cloud Computing Reduces Cost
As mentioned above cloud computing adds complexity and with that complexity comes cost. Cloud computing on it's own will not deliver cost reduction in fact it has the potential to significantly increase costs. What delivers the majority of the cost saving in a cloud environment is the increase utilisation of resources so allowing the data centre to do more with less. This comes from consolidation and more intelligent use of resources (eg. If my workload falls and I can migrate workload onto a smaller number of servers I can power down the currently un used servers and run the remaining servers at full capacity). The other part of the cloud approach that helps to reduce cost is the standardisation and automation. If you have many repeated tasks that are the same or similar then automating them will remove the need for human intervention and associated cost. If however you have a large number of bespoke tasks then the overhead of automating them will typically be higher than doing them manual and so costs increase. For this reason it is essential that you have in place the framework for standardisation, governance, policy and process. This is often the Achilles heal of private clouds.
Myth 3 - Cloud Computing requires virtualisation
No where in the NIST definition of cloud does it state this. It talks about on demand self service, broad network access, resource pooling, rapid elasticity and measured service as well as talking about multi-tenancy, resource re-allocation, abstraction and dynamic assignment and the fact the the user can not dictate the exact location of the resources he consumes but NONE of this requires virtualisation. With the addition of self service provisioning and metering this can be achieved with a good old fashioned cluster! I often see, particularly in the world or development test, QA and support, users pushing back on cloud based solutions because they need to run and test their applications on "bare metal" rather than on virtual machines which often leads to machines dedicate to a task lying idol of much of their life. Using self service and automated provisioning these machines can be added to a pool that can be shared over time with multiple projects hence improving their utilisation and becoming part of the cloud with no virtualisation in play.
Myth 4 - ITaaS cloud computing will reduce server sprawl
Many of you will have heard of the term virtual server sprawl. The effect of making the provisioning of virtual servers quicker, easier and self service without the correct process, policy and governance in place will result in the rapid explosion of virtual server creation, far more rapid than an environment based on physical servers could support. While for the successful adoption of cloud computing within an organisation it is important that the consumer can fully benefit from the agility that the cloud can bring it is also important to ensure that the mechanisms ar ein place to ensure that there is not an uncontrolled proliferation of virtual servers.
I hope that this taster and the more detailed posts that are to follow will help you to see your way through the fog and mist that have become trapped under the cloud and allow you to navigate your way to a more successful deployment and or use of the technology for your business.
Who am I?
I have spent the vast majority of my career working in customer facing technical roles within leading edge hi-tech companies with the last 12 years spent in Pre-Sales management and leadership within a major IT product and technology vendor. Full details can be found in my linkedin profile. My interest in technology stems from always asking the question "well that is very clever but what can it do for us and how can someone make a business from that". Looking at Douglas Adams three ages of technology I seem to have become stuck in the 2nd age. My approach to technology has lead to to work with a variety of products and technologies in a range of vertical markets with customer and partners from small start-ups to major global corporations but also from the view point of how can we combine products and technologies to build a solution that will provide business value and so benefit the consumer of the technology, the deployer of the technology and the vendor. In some cases this has meant building complete eco-systems from scratch in others it has meant simply changing the way we look at a problem to develop a new solution.
Subscribe to:
Posts (Atom)