In part 1 of this series, I introduced a list of attributes that can be used to explain Cloud Services:
- Utility & Services
What I failed to mention was the different terminology that is being used by the IT-industry for Cloud Services. Typically you will see at least two phrases: “Cloud Computing” and “SaaS” – whilst “SaaS” may also be indicated as “Software as a Service”.
Each of these 2 phrases has a whole range of variations that we will address in this series.
Most people will associate Scalability with growth or the creation of bigger things. In Cloud Services you need to think of it like a rubber band. It can expand to do more, but it may also shrink. A Cloud Service is elastic.
This attribute makes it possible for Cloud Services to easily provide the service, for example email, to more people when needed and scale down if less people are sending emails.
This elasticity is a seamless experience to the user because, apparently, the provider of the service has taken pre-cautions to easily adapt the underlying technology to these growing and shrinking usage scenarios.
Obviously, when demand for a service rises, the provider has to put in place more powerful computers, more connections and probably more electricity or staff to manage this growing environment. But when the demand is falling, the technology also has to be scaled down.
In non-Cloud services this would lead to changes in the computing environment that were very noticeable by the users; a slow reaction to demand fluctuations, possibly a need for additional contractual agreements, licensing discussions between provider and users and maybe a maximum bandwidth for scaling the service usage up and down.
Scalability is not limited to the technical tools to provide more or less of a specific service. It also points to the possibility to expand the functionality of a service.
There are two ways this type of scalability is deployed by Cloud Service providers. First, they can add new functionality to the service itself. An example is a provider of email services that adds the possibility for the users to also create and maintain an electronic agenda. The second possibility is for two service providers to interconnect their respective services with each other. When this is done seamlessly it is called a ‘mash-up’ (there are also other types of ‘mash-ups’ possible, which we will have a look at them later).
Although Scalability in itself is nothing new to IT services, the elasticity of the capacity and the seamless adding of functionality is typical for Cloud Services.
In this way Scalability is a very positive attribute of Cloud Services. The user does not need to pay for this inherent ability, there is no bumpy ride of difficult technology or purchasing changes if you need more or less capacity. It also seems to be very beneficial that new functionality is added, most of the time without paying for the change itself.
There is also a downside: because of the importance of scalability and the benefits it provides in making Cloud Services available for a large group of people, you will inevitable have to compromise. These compromises have to do with the user-specific attributes that are not enabled. The full set of services needs to be the same for all users, otherwise the scalability will not work. There is a fixed set of functionality for the user and there is a limited possibility to personalize the service itself. As a result most Cloud Services are based on very commoditized functionality such as email, calendaring, file storage or simple information sharing. They all may look differently, but the basic service is very standardized.
Most providers of Cloud Services have recognized this standardization and have started to develop Cloud Services with much more personalization or complex functionality. This expansion in the types of services provided, created the need to have a large common environment that supports multiple (non-standard) working environments for different types of customers.
This introduces the next attribute of Cloud Services: Multitenancy. This we will discuss in part three.
[See also Part 1 – Location]