Agility is considered as a major advantage of SOA, Virtualization and Cloud Computing.
By using Abstraction we create an Agile less complex model for Business people and IT experts.
In this new Agile world it is easy to Change, Adapt and Build new entities.
In this new Agile world it is easy to Change, Adapt and Build new entities.
Sometimes it could be too easy.
With too much Agility it may be a chaotic Enterprise rather than Elastic, Flexible and Easy to change enterprise or Virtual Enterprise.
If we would like to enjoy the Bright side of Agility we have to take into consideration the possible Dark side of Agility and by Planning and Managing the Architecture and Infrastructure avoid of too much Agility.
If we would like to enjoy the Bright side of Agility we have to take into consideration the possible Dark side of Agility and by Planning and Managing the Architecture and Infrastructure avoid of too much Agility.
Virtualization as an example
The following section is an example illustrating the problems caused by too much Agility in Virtualization. It should be remembered that not necessarily Virtualization implies too much Agility. Without too much Agility it is a valuable technology both in the Data Center context and the Public Cloud context.
It should also be remembered that the following section is only illustration. It is not an exhaustive list of all challenges derived from Virtualization ease of change.
Lack of Life Cycle Management
It is so easy to define a new instance of Virtualized Operating System, so in some Enterprises and Public Clouds people forget to delete unused instances.
The results could be waste of Hardware Resources, aimless Backups and unnecessary Management Overhead.
Too much usage of Hardware Resources
Enterprises which use about 10% of Intel based Servers CPU ,easily build Virtual Server after Virtual Server on a single Physical Server. The CPU usage could be about 110%. As well as high Memory usage rate.
After defining too much instances the CPU usage rate is too high in most cases and instead of improved Performance the Performance is less optimal than before. In case of a Physical Server downtime it may be impossible to find another server to run the Virtual Operating Systems instances of the overloaded server.
The Best Practice Rule of Thumb is to use about 60% or 70% of the CPU in peak times. 60% is a lot better than 10% to 15% used before virtualizing the Servers.
A upper threshold for CPU usage is not new: back in the 1970s a maximum threshold for Mainframe CPU usage was defined in case of Online Transactions workloads.
No planning of Virtual instances distribution on Physical Servers
Too much Usage of Resources is one of the scenarios of lack of planning.
Other scenarios examples are: placing CPU Bound instances on the same physical server causing Performance degradation, Placing all instances of an Application on a single server so no Business Continuity is possible in case of Physical Server failure.
No Network traffic optimization
If two Virtual Machines which are communicating often with each other and transforming huge amount of data, are placed easily, on different Physical Servers the result is a lot of Physical Network traffic.
By locating them on the same physical server and transmitting the data using internal server resources instead of physical network resources could save Network resources.
The result of placing them on differnet Physical Servers is degraded communication Response Time due to usage of the physical network which is a lot slower than memory to memory data transition on the same server and due to higher network contention.
Is it possible to move the Storage together with the Virtual Operating System Instance?
It is possible to move easily a Virtual Machine from one physical server to other using technologies such as VMware's VMotion. CPU and Memory resources movement is a part of this process. However, Storage movement or reallocation is not part of this process, therefore it may function less optimally in the new server environment.
Conclusions
The Value Proposition of Agility is ease of Change and ease of building new entities. However, when it is too easy to make changes, many enterprises will not resist the temptation of too much, quick and unplanned changes or additions.
The consequences could be no Value at all or even worse results than traditional non-Agile architectures and systems.
I used Virtualization as an example to illustrate the damage of too much Agility.
Cloud Computing is based upon Virtualization and therefore the conclusions about Virtualization could be applicable to Cloud Computing as well.
I could also use SOA as another illustration of the same issue. For example by describing very Agile implementation based on large number of fine grained Services. In that case Change is easy but Management is a nightmare.
The following section is an example illustrating the problems caused by too much Agility in Virtualization. It should be remembered that not necessarily Virtualization implies too much Agility. Without too much Agility it is a valuable technology both in the Data Center context and the Public Cloud context.
It should also be remembered that the following section is only illustration. It is not an exhaustive list of all challenges derived from Virtualization ease of change.
Lack of Life Cycle Management
It is so easy to define a new instance of Virtualized Operating System, so in some Enterprises and Public Clouds people forget to delete unused instances.
The results could be waste of Hardware Resources, aimless Backups and unnecessary Management Overhead.
Too much usage of Hardware Resources
Enterprises which use about 10% of Intel based Servers CPU ,easily build Virtual Server after Virtual Server on a single Physical Server. The CPU usage could be about 110%. As well as high Memory usage rate.
After defining too much instances the CPU usage rate is too high in most cases and instead of improved Performance the Performance is less optimal than before. In case of a Physical Server downtime it may be impossible to find another server to run the Virtual Operating Systems instances of the overloaded server.
The Best Practice Rule of Thumb is to use about 60% or 70% of the CPU in peak times. 60% is a lot better than 10% to 15% used before virtualizing the Servers.
A upper threshold for CPU usage is not new: back in the 1970s a maximum threshold for Mainframe CPU usage was defined in case of Online Transactions workloads.
No planning of Virtual instances distribution on Physical Servers
Too much Usage of Resources is one of the scenarios of lack of planning.
Other scenarios examples are: placing CPU Bound instances on the same physical server causing Performance degradation, Placing all instances of an Application on a single server so no Business Continuity is possible in case of Physical Server failure.
No Network traffic optimization
If two Virtual Machines which are communicating often with each other and transforming huge amount of data, are placed easily, on different Physical Servers the result is a lot of Physical Network traffic.
By locating them on the same physical server and transmitting the data using internal server resources instead of physical network resources could save Network resources.
The result of placing them on differnet Physical Servers is degraded communication Response Time due to usage of the physical network which is a lot slower than memory to memory data transition on the same server and due to higher network contention.
Is it possible to move the Storage together with the Virtual Operating System Instance?
It is possible to move easily a Virtual Machine from one physical server to other using technologies such as VMware's VMotion. CPU and Memory resources movement is a part of this process. However, Storage movement or reallocation is not part of this process, therefore it may function less optimally in the new server environment.
Conclusions
The Value Proposition of Agility is ease of Change and ease of building new entities. However, when it is too easy to make changes, many enterprises will not resist the temptation of too much, quick and unplanned changes or additions.
The consequences could be no Value at all or even worse results than traditional non-Agile architectures and systems.
I used Virtualization as an example to illustrate the damage of too much Agility.
Cloud Computing is based upon Virtualization and therefore the conclusions about Virtualization could be applicable to Cloud Computing as well.
I could also use SOA as another illustration of the same issue. For example by describing very Agile implementation based on large number of fine grained Services. In that case Change is easy but Management is a nightmare.
Comments