Cloud is probably one of the most used term in IT industry of this decade; but what does the cloud actually mean? From its very beginnings, the "Internet" network has been represented visually, through diagrams, by a cloud, thus showing the fact that it is offered as a service, without revealing information about its technical implementation, offering only an interface for communicating with other networks.
The adjoining image shows an example of such a diagram: there are several elements that we are familiar with (the firewall, the web server, the users - see Figure 1) and then an element that is offered as a service, just like described above.
This element is the Internet, represented by a cloud. Most users are not aware of the details of how the Internet works as a network. They know that an interface for accessing it is available to them (a wireless network, a data cable, etc.) and they can use it in their everyday activities. Obviously this is the way in which the Cloud services are useful for home users.
On the other hand, there are other types of users. One of our partners developed an application for local governments, which is called "Government as a Service". The sales of this application are based, naturally, on the magic word "Cloud".
A web application is available to the employees of local administrations (because they are the target of the application), which they will use intensively in their daily activity, an application which makes available all the instruments they need for the services they are offering to the citizens (such as: recording births, deaths, marriages and others alike).
The application will be hosted by the software"s producers - all the local administrations need is a computer for each employee, connected to the network. Can we say that this is a Cloud type of service, from their point of view? Surely! They do not care what sort of firewall the connections pass through, where and how the data is stored (at least not the front-line employees), they do not have to carry out any sort of maintenance for any sort of systems, they do not have any sort of interaction with anything but what they need: the instruments for processing civil status data and events. In short, they connect to the Cloud and get their job done! Can we say the same about the company producing the software? What does the Cloud mean for them? The application is, obviously, one of their products; they offer support, carry out maintenance, they know exactly how each little piece works, and the architecture diagram is a complex one. However, if we look at diagrams, we should nevertheless see a cloud. There should be a specialised service of platforms as a service (PaaS). One arrow goes, on the diagram, from the company"s development environment (and why not, maybe even from the programmers" computers) straight to the "Cloud". The code written by the developers arrives directly in an already prepared environment. Neither the programmers, nor the testers, nor the business analysts, nor anyone else are/is dependent on the manner in which this platform works, but only on the interface made available by the service provider offering the platform (usually a set of APIs). In a similar manner, the platform distributor may have an infrastructure distributor (IaaS) and so on.
Moreover, this entire chain does not have to be an external one; it may be that these services are offered by a different department of the same company. For instance, "the IT guys" offer the infrastructure part, a team of "devops" offer the platform part, and the programmers are tending to their own business.
When we talk about the "Cloud" type of services we think, from the supplier"s perspective, of attributes such as:
An interesting situation arises when we have software that has a similar functionality with that of a Cloud but runs on an infrastructure that is not "cloud-like", many of the attributes described above being emulated through various auxiliary solutions, within the application. Can we speak, in this case, of a "Cloud"? Is it enough for an application to be drawn in the service beneficiary"s diagram as a cloud to become "cloud-based"? I think it is not! Yes, it is offered "as a service", but if the scalability part is missing (and it has to be implemented at all levels!), then the application will not be able to support unexpected periods of intense traffic, we won"t be able to talk about a reduction in cost if we cannot automatically scale resources to current needs, etc. The same goes for the other attributes that help define that a "cloud" is. Thus, according to the perspective from which we look at things (beneficiary versus service provider) and according to the specifics of a project, this word may mean several things. So let us not be fooled by false clouds that do not bring the much-needed rain of functionality that our crop needs!