When defining what is a cloud service, we need to know that it is not a technology per se, but its an architectural and operational paradigm. It is a self-service computing environment offering the ability to create, consume and pay for services. In this architecture, computing resources are elastically supplied from a shared pool and charged based on metered use and it uses service catalogs to provide a menu of options and service levels.
According to the IDC «total cloud IT infrastructure spending (server, disk storage, and ethernet switch) will grow by 21% year over year to $32 billion in 2015, accounting for approximately 33% of all IT infrastructure spending, which will be up from about 28% in 2014. Private cloud IT infrastructure spending will grow by 16% year over year to $12 billion, while public cloud IT infrastructure spending will grow by 25% in 2015 to $21 billion.»
Meaning that the growth for this architecture (Private,Public or Hybrid) will not stop for the foreseeable future, so we first need to understand what drives it and how to translate your current architecture into a 3rd platform architecture .
The principles of a cloud architecture supports the following necessary capabilities:
- Resource pooling. – Services can be adjusted to suit each client’s needs without any changes being apparent to the client or end user.
- Rapid elasticity. – The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.
- On-demand self-service. – Provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider
- Measured service. – Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer
- Broad network access. – Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms
We need to understand that cloud is an architecture that will not be a true fit for everybody or for every case, we need to determine what are the business drivers for us to implement a cloud architecture
- Increment our agility within our enterprise by providing:
- The ability to remove certain human procedures and have the end user be a Self-Service consumer
- A well defined service catalog
- Capability to adapt to workload changes by provisioning or deprovisioning system resources
- Reduce enterprise costs by
- Using shared system resources for our different applications and internal business divisions
- Being capable of determining the actual usage of system resources to show the benefit of our architecture
- Capable of automating mundane and routine tasks
- Reduce enterprise risks
- By having greater control of the resources we have and how they are being used
- Have a more unified security across our business
- Providing different levels of high availability to our enterprise
The most critical part when defining any type of service, is defining what is it that we are going to provide, take McDonalds for example, when we get to a counter there is a well defined catalog of what products we can consume in that establishment, it will be a certain type of hamburgers and junk food. To define it more clearly, we can’t go into McDonalds and order a pizza or Italian food, as that is not in their business or service catalog.
When defining our business enterprise service catalog, we need to define the What, as to what type of service we want to provide, what service levels we want to provide, what policies are we going to apply to the service and what are our capabilities to provide it.
The business service catalog will translate into a technical enterprise catalog, defining every detail of how are we going to provide our business services, in here we need to define the How, how are we going to deploy the service, how are we going to provide the service levels, how are we going to apply the business policies and how are we going to manage our services.
As mentioned, this is not a technology, but it is an architecture, and as any , we first must understand where we stand to know where we are going , so we in our current organisation we first need to capture our existing assets, skills, and processes so that we can then validate the future state of our architecture.
Meter, Charge and Optimize
Business consumers want to know what they are consuming and what it costs, even if they don’t actually want to pay for the service. Additionally, from an operational perspective, as different tenants start sharing the same piece of platform or infrastructure, there needs to be accountability on the usage, or else resources may be over-allocated. To mitigate this, we often meter the usage and optionally chargeback [or show back] the tenants. Though an IT organisation may not actually charge back its LOBs, this provides a transparent mechanism to budget resources and optimize the cloud platform on an ongoing basis.
These are just a few points to be aware if you want to become a private cloud provider, but this is also helpful for any cloud architecture , as we need to understand what drives the change, what is it that we are going provide, how is it that we are going to do it and the way to measure the services that we are providing.