These days, a number of keywords flood our lives as techies: Cloud computing, anything as a Service (*aaS), virtualisation, … . The whole world seems to be embraced by these buzz words but, what happens when our daily work relies on them? Uncertainty.
My post today is devoted to highlight the importance of always keeping a critical mood (as information consumers) and a minimal conciseness in our tech talks, documents, emails, tweets, etc. (as information producers). In all our communications. The rule is simple, make sure the audience understand what you mean. The implementation is utterly difficult, specially in the context of Cloud, services and virtuality 😉
Let’s come into terms, for instance, with Cloud computing. The Wikipedia has a good and complete article on this topic, straight definition, good references. However, the reader is influenced by its background and not everyone does take enough time to think about the topic. Even more, key references are missed, which actually could provide the reader a critical perspective. I’m referring to Cloud Computing and Grid Computing 360-Degree Compared by I. Foster et al. Wait, I’m not going to argue for or against Cloud here, it’s just a matter of viewpoints. A services’ person loves the Cloud. These people simply concentrate on the users, the service and the workflows, and impose requirements on what’s supporting them, typically shaped as a cloud in their minds. But the supporting cloud is made of hardware and software, it’s definitely not a simple abstraction. Let’s talk about it.
The three main layers in Cloud computing model are Application, Platform and Infrastructure (top-down). Based on them, three generic business models are well-known: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS), respectively. Now I will let my background alter the rest if this post. I’m a “network guy”; SaaS and PaaS are familiar to me but not the main scope in my daily work. What about IaaS? Yes, there it is: Infrastructure resources. Network is there, as well as computing and storage (IT) resources (cf. EU FP7 GEYSERS project and its developments). Unfortunately, a vast part of the documentation about IaaS forgets the network devices. Or even worse, it limits ‘network’ to ‘IP address’ or ‘connectivity’, which is completely inaccurate and unfair. The whole IT world seems to have forgotten the ‘C’ for Communications (ICT), which in the end is what adds real value to IT services. Nevertheless, this is understandable. Inside a local Cloud domain, and inside data centres, bandwidth is considered to be cheap. Low latency and jitter are assured, capacity is over-provisioned and monitoring is available. Hence, network/bandwidth reservations are pointless. Why worrying about the network? Outside the local Cloud domain things change. MAN/WAN are controlled by network operators. Network services are the core business for them and this is translated to inflexible services, strict SLAs and lack of performance information. Again, worrying about the network is pointless.
At this point, the reader may think the context presented above has scarce chances to change. Wrong. Let’s recall SaaS and PaaS. The good things about them are their cloud-shaped substrate and the amount of potential end consumers they have. And many engineers around the globe have definitely understood that. Think of Google, Amazon, Rackspace and many others. What is the point here? The ubiquity and scale of SaaS/PaaS. Now think back in the infrastructure. Right, how can one provide ubiquitous services over fixed-location Cloud domains? Simple answer, distribute the Cloud. Problem: remote Cloud domains most probably are interconnected by rigid (?), over-provisioned (?) network services? Who’s going to pay for that net services? Google does its own way, by building their infrastructure in the USA, but their CapEx costs are high, and increasing (cf. this article in GigaOM). But Google or Amazon models do not allow modest capital competitors. Why don’t we define flexible network services that are mappable and complementary to Cloud infrastructure services? Let’s think in the Network as a Service (NaaS), but be careful about the perspective. Remember the original goal of this post 😉
Some networkers (including me) have tried to use the concept of Network as a Service (NaaS) but, what’s this exactly? Do I get a topology when I request a network as a service? What are the protocols installed in the nodes? I miss a real effort in defining the concept. It seems we’re rushing to use the concept in the context of Cloud, due to *aaS, but it is not really clear. NaaS is a term that was used in the ATM ages, but did not gain enough momentum up to our cloudy days, where anything can be serviced. But my reflection here is about the viewpoint. Networkers are not happy with NaaS because it lacks of technical details. ‘Network’ is generally used to designate a domain or and administrative domain. Thus, this entity cannot be serviced. By contrast, if one adopts the IT’s perspective, NaaS gains meaning: flexible network services, monitorable performance, enhanced connectivity, regardless of the technology layer. Control and management functions must be coordinated together with high-level service constraints. In some cases, that functions must be handed out to Cloud management platforms, in order to elastically re-shape the execution environment for the software platforms and, hence, for the apps. And this leads to the last keyword I stated in my first paragraph (long post here, huh!): virtualisation.
Virtualisation is one of my favourite keywords. It is controversial. Many see virtualisation as the solution for every single problem in the ICT R&D. Others negate the applicability of the term in computer science. In fact, all the resources we’re used to deal with are virtual. Storage, computing or forwarding are performed logically, via software controllers for hardware. From panacea to negation. Sticking to a dictionary definition, something virtual is so that appears to be real, but not physically existing as such. In my view, this is applicable to networks, further than VPNs. For instance, one can have a switching device, with 4 input and 4 output ports. Commutations are defined by a grade-4 switching matrix. If we logically slice the box into 2 switching devices of 2×2 ports and let two different users control each sub-switch independently, without noticing about the other slice, a virtualisation process has occurred. Each user has the feeling he/she operates a switch of 2×2 ports, with a grade-2 switching matrix. Of course, this process requires an obfuscation tool (each user must see only its slice, as unique) and strict security and isolation techniques. Similar examples can be thought of by assuming resource aggregation, rather than slicing. Basing on this assumptions, we can build the NaaS for Cloud infrastructure services. Part of this is driving discussions in OGF’s ISOD research group.
For further discussion, don’t hesitate to contact me (jage AT i2cat.net) or follow discussions in our DANA blog!