The 5 characteristics of a Cloud Service
The EBA issued its Recommendations for outsourcing to cloud service providers, but what is a Cloud Service, really?
On March 28 this year, the European Banking Authority issued Recommendations on outsourcing to cloud service providers, that apply to banks - but are of course also interesting for insurance companies to consider. It contains its own definition on what is a cloud service:
Cloud services - Services provided using cloud computing, that is, a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.[1]
Simple, eh? Maybe not. Reading it carefully a few times, it aligns pretty well with the definition I usually use, which is:
A Cloud Service is a marketing term for an IT service that typically has the following five characteristics: (1) Highly standardized, (2) "Infinitely" scalable, (3) Pay as you go, (4) Self-service and (5) "Instant" delivery.
Let's dive into each of these a bit and I'll explain what I mean.
1. Highly standardized
The same service, both technically and contractually, is delivered to many customers, to enable cost-efficient delivery. The concept of "multi-tenancy" is in my view a core characteristic of a cloud service. If it is built to your spec, it is not cloud. The same goes for the agreement. Although there may be some room for negotiation of terms and pricing, the service providers entire model builds upon them delivering the same service to multiple customers - and therefore customizing T&Cs to your liking is costly and restricts further development of the service. Instead, service providers try to create T&Cs that are acceptable to a broad range of customers and use cases. In addition they typically offer special T&Cs to some industries, like government and financial services, but that's it.
2. "Infinitely" scalable
Since each customer only consumes a small share of the total service, customers can change capacity quickly. The big cloud vendors have millions of servers in each datacenter from which the services are delivered. If you scale up by 50% in one day, it will merely be a blip in the overall capacity consumption of the large vendors.
The scale of cloud and the implications of this standardization are quite interesting. The days of having "cold spares" - pieces of infrastructure whose only role was to be used in case the primary infrastructure failed - are largely gone. Capacity planning with the service providers, meaning having discussions with them on what your forecast for infrastructure consumption is - is also a thing of the past. You just scale up or down depending on your need.
3. Pay as you go
Almost no investment is needed by the service provider to handle a new customer. As there is basically no fixed cost for the service provider, charges are almost linear to usage. From the service provider's point of view, it does not matter so much anymore if you have a thousand small customers, or a handful of really big ones. As a result, even small customers can get the cost advantages of the cloud providers' scale, while big customers can be a bit surprised that the discounts they are getting on the list pricing are smaller than they are used to.
4. Self-service
Due to standard delivery and automation, customers can provision the service for themselves through a web portal or Application Programming Interface (API). From the customer's perspective, this self-service is typically key to unlock the real value of the cloud - the increase in productivity in the engineering teams. This is a topic I'll probably return to in a future post, in case anyone is interested.
5. "Instant" delivery
Again, due to standardization enabling automation, provisioning of service is near-instantaneous. If you order it, you can spin up a cluster of thousands of servers in seconds. The automation and speed is another core concept of the cloud, but some organizations fail in this area by bringing their "old" provisioning processes into the new world when embarking on a cloud journey. If you still want to retain your old change and release processes that you had in your "on-premise" environment, you might just as well skip the cloud journey altogether.
Final thoughts
Going through the list above, I think the EBA definition is actually not that different. The reference to a "shared pool of configurable computing resources" refers to the multi-tenancy of the cloud. The "rapidly provisioned and released with minimal management effort or service provider interaction" clearly relates to automation. Those two in combination are in my view some of the core concepts of cloud computing.
What definitions do you use, and and why? Feel free to comment below, or on this article on LinkedIn.