Definitions of technology that are clearly understood by a few early adopters are quickly thrown into disarray as soon as they become mainstream. Marketers feel the need to become buzzword compliant and take to using the name of the technology to build new products or repackage old rope – and as soon as they are let loose things become confusing for the market and the users of the technology.
As ‘cloud’ is being talked about more, there are conflicting opinions flitting around ranging from ‘the next big thing’ to ‘we’ve been doing this for years’ to ‘it doesn’t matter’. Regardless of where the use or overuse of the term lands up it is important, at least for technical people and architects to come up with their own view of the cloud – so that they can fit it into their own mental model of how systems work and are built.
So for purposes of coming up with an understanding that is comfortable for me I’ll throw my views on the definition out there… starting with the base characteristics of any ‘cloud’ solution.
- It is cheaper : It seems obvious but without being cheaper there is no point in using someone else's infrastructure. The whole idea is to leverage the economies of scale and new technologies that take administration out of the loop in order to make it cheaper than what you can do in your own datacentre.
- It is not on your network : Historically the cloud was used on network diagrams to refer to the big bad and unsafe Internet and was always depicted outside the DMZ. Packets in the cloud cannot be controlled by your routers, firewalls or adminstrators. My opinion, which is not universally shared, is that servers ‘in the cloud’ that are accessible by VPN doesn’t make it a cloud – the VPN makes it part of your network.
- It belongs to someone else : Having a server than you own and administer in some rack in an ISP doesn’t make it part of a cloud architecture. It is only when it is owned by someone else, who can sell the infrastructure to lots of people (multi-tenancy) , that it becomes possible to do cloud things on the architecture
- It provides for on-demand scaling and allocation : In order for your system to personally get some advantage out of the cloud it needs to be able to scale quickly. Quickly does not mean a few hours of administrators’ time to mount a new virtual machine onto your hosted server – quickly means changing some configuration, pressing a button or filling in credit card details and ta-da… your system has scaled.
- It is simple to administer : The pain of acquiring hardware, installing, setting up and keeping it going should not be your problem. No team of server administrators, no trucks arriving to take offsite backups away, no backup power supply systems, no testing and scheduling of patch installation, no 24x7 operators – that should be done somewhere else, by someone else where all you get is a simple interface and an affordable invoice.
- It is reliable : You should never have to worry about architecting differently because you are worried that a disk may fail, or a server, or a switch. You can choose the number of nines of reliability and uptime that you want depending on how much you want to spend.
- It is sustainable : Although not in vogue during the current economic climate we will, whether through legislation, spiralling costs or the fact that your existing data centre may land up below sea level, have to deal with the fact that the cost of providing the processing that we are consuming, in terms of harm to the environment, will need to be managed. Cloud resources need to be located and provided in a manner that is energy efficient and tending towards carbon neutral in order to be sustainable. A central London data centre will simply become too costly for the bottom line and the planet to consider running.
The problem with definitions of the cloud is that the hardware people see the cloud differently from the software people – and their own definitions of the cloud create short-circuts in the message. There is, for example, a huge, well established business in ‘cloud storage’ which apparently has been going on for a long time. I, personally and as a software architect, don’t really know enough about that business to have a real, defensible opinion on the matter. So for my own purposes I have defined two clouds which map (more or less) to hardware and software (or infrastructure and applications). Some technologies available straddle the two but generally the available technologies seem to have a bias towards one group.
Infrastructure Cloud
The infrastructure cloud is an area which I know little about – everything that is not understood by my picture of the cloud in terms of software services gets lumped in this category, so a disclaimer “Don’t take infrastructure advice from a software person” applies. The infrastructure cloud is largely concerned with the provision of fairly raw computing resources by taking advantage of bulk co-located commodity hardware and (mostly) automated virtualization technology. So if more resources are needed a button is pressed and a new configured VM spins up and becomes available. The notion of a private cloud, which I feel is in violation of the base characteristics, comes from – the idea being that all the virtualization automation should be available and accessible in your own data centre.
Software Services Cloud
For me, the exiting things are happening in the software cloud which is sometimes referred to as the platform cloud (as in Azure as a platform). Over an above the characteristics above, the software cloud adds the following:
- The services are accessible : Services need to be accessible from a variety of devices, operating systems and locations without anything in the way. Even the data storage should be accessible via an easily addressable endpoint. One could also add that they are discoverable through some mechanism such as a service bus which relays the request to the actual service.
- The services operate at layer 7 (on the OSI Model) : Services that need a VPN connection as a prerequisite cannot be considered to be cloud based services.
- The service consumer uses one endpoint : Regardless of the load on the system, the user, or other system consuming the service points to one endpoint and the request is serviced by the optimal resource.
- The programmer has no knowledge of the host machine : No writing to local disk, no assumptions about available memory, no knowledge about open ports on the server. The programmer should make the system work in a very generic sandbox.
- Security is embedded : There should be no option to build a system that has obvious security flaws. Authentication, authorization, encryption, no-repudiation and other security elements must be part of the platform.
That is my first cut of what makes up the cloud and I am sure it will change over time. I urge you all to spend some time thinking what your definition is, rather than using someone else’s. After all, if you don’t have a clear technical picture in your own mind as to what the cloud is , then how can you build a cloud based system? In which case you should join the marketing department.
Simon Munro