A couple of weeks ago I was asked to do a presentation to a number of mainly (project) managers on the topic of "The Cloud". I think one of the reasons I was asked had to do with the fact that I usually tend to be (a bit) iconoclastic and another reason might be that I have been a huge proponent of The Cloud. Look at previous posts of Arc-E-Tect and you should be able to find a number of posts on the topic. In any case, I obliged.
While preparing the slides, digging into my archive of presentations as I remembered a presentation I did on the topic a couple of years ago to a group of mainly lawyers and auditors I decided that it was the perfect time to not talk about The Cloud as an IT phenomenon but as a business phenomenon. As you might have gathered when reading my posts on this blog, I do tend to see IT from a business perspective. Pure simple logic dictates that we apply IT in organisations to strengthen our businesses. The decision was made, I was going to talk about Cloud Native Enterprises.
The Cloud According to NIST
What are Cloud Native Enterprises? First of all you need to know what The Cloud is, and I always use the NIST definition of Cloud. NIST made it easy to define The Cloud by naming 5 essential characteristics of cloud:
- On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
- Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
- Resource pooling. 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. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
- Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
- Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
(source: The NIST Definition of Cloud Computing)
There's not really an order in these characteristics, but they are essential. You have to keep in mind that these are related to IT systems, typically infrastructure hosting services.
I'm not going to re-iterate these characteristics and explain what The Cloud is, instead I'll go over these essential characteristics to explain what a Cloud Native Enterprise is.
Cloud Native Applications
But before I do this, let me explain what a cloud native application is, because it is important to understand this. First of all; Every cloud native application can run in a traditional data center. Second of all; From a NIST characteristics perspective there is no difference between public and private and hybrid clouds. As long as all 5 essential characteristics are met, we can talk about a cloud environment.
Back to the cloud native application. This is an application that thrives on the cloud. It is one that uses the 5 characteristics to the fullest and doesn't compromise. Let me go over them one by one.
- On-demand self-service. A cloud native application is accessible by a user, which could be another application, but often it is a person. But it is not only accessible by a user, but everything pertaining that user can be done by the user, whenever the user pleases. So the user can sign-up herself, configure her environments herself and do whatever she needs to do, all by herself. Irrespective of the role of the user. So an administrator of the application can do whatever needs to be done, as can a business user. This is hugely different from traditional applications, where you would need to request an account at some service-desk in order to gain access.
- Broad network access. Cloud native applications are network accessible and not only that, they're accessible through standard mechanisms and through common devices. Typically we see that these applications are accessible via the internet, or at least through internet protocols. Often we use http or https to access the applications. Originally through a browser, but with the advent of mobile devices we see that the generic web-browser is replaced by a specialised browser, the client application, that accesses the application's logic via web- and internet-protocols and presents a user experience fully embracing the client device's capabilities.
- Resource pooling. This for applications means that the applications are multi-user applications and the users are not aware nor impacted by each other, unless of course, business logic demands interaction.
- Rapid elasticity. Probably the most unique selling point of the cloud is elasticity. The amount of resources needed to perform a specific task consistently independent of the load on the systems is expanding or retracting as needed. Elastic. No wonder Amazon calls their virtual server environment Elastic Cloud Compute (EC2). For cloud native applications the same goes. The application scales up and down as needed by the load on it. Typically this is done using the underlying infrastructure's elasticity, but mind that the cloud 'nativeness' of the application is that we're talking about functional elasticity. The responsiveness of the application is consistent across many workloads. This can mean that the application's functionality scales down when load increases (e.g. loading only the first 3 review comments for an item in a web-shop instead of 10) and scales up when the load decreases.
- Measured service. Here we run into the situation where the usage of the application is metered. At any time it is known what the application's utilisation is. Which user is using what functionality at what time with which guarantees. The idea here is, obviously, that the user will be billed based on her usage (of resources) of the application in contrast to some flat fee or a compute-power based fee. An example is that a free-tier account can access a certain function only once every two seconds, where a pro-tier account can access the function 5 times a second. The key here is metering and billing.
Every time I use the word 'user' above, I want to reiterate, it can be a person, but also another system. Especially in the current API economy, the user mentioned will very likely be another application.
Applications that are cloud native adhere to these 5 characteristics, and they do this from a business functional perspective. There are all kinds of technical implications like a transition from ACID transactions we typically see in traditional applications, towards BASE transactions we see in cloud native applications. Same goes for in depth security in the cloud and more of a focus on perimeter security in traditional data center hosted applications.
Cloud Native Enterprises
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.
- On-demand self-service. When online services and core systems really seamlessly integrate.
- Broad network access. When customers, partners and users are distinct groups treated equal.
- Resource pooling. When synergy across value chains makes the difference.
- Rapid elasticity. When business is extremely unpredictable.
- Measured service. When business resources are limited.
Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.
The text very explicitly communicates my own personal views, experiences and practices. Any similarities with the views, experiences and practices of any of my previous or current clients, customers or employers are strictly coincidental. This post is therefore my own, and I am the sole author of it and am the sole copyright holder of it.