Consumers of cloud computing have clamored for a more unified approach to the services they use, be it IaaS, SaaS, PaaS or some other cloud based service. The knee jerk response is to federate services. While the approach is sound, allows seamless access across services and would in theory provide some modicum of security, this does not necessarily mean that they are provided by the same cloud services provider (CSP) leaving the consumer to manage relationships and SLAs with multiple CSPs. One possible solution is for CSPs to be a one-stop-shop that allows customers to create value by building up the stack, so to speak.
Pause------------------------------------------
Before we get any further, let's keep in mind the classic pyramid diagram of cloud computing:
OK, it's a cheesy graphic, but we all understand that software (SaaS) is built on programming platforms (PaaS) which are run on infrastructure (IaaS). Clearly the graphic is not drawn to proportions because the SaaS market has outstripped the IaaS market. An inverted pyramid wouldn't cut it either because PaaS is a smaller market than IaaS. (Maybe an hourglass shape... But I digress.) A variant would be a more Application Service Provider (ASP) model where software is installed on an IaaS-based instance and offered for the use of customers. This latter variation is not strictly speaking SaaS but is a reasonable hand drawn facsimile.
Unpause----------------------------------------
Let's say one such CSP has launched a cloud computing service that offers these services to customers (say IaaS, PaaS, and SaaS to keep it simple and avoid getting into any sticky discussions about cloudwashing).
So now we have a stack based on software created by software vendors or by the open source community on which value can be created. CSPs add value by tying the three service models together and offering them transparently to customers; CSP customers add value by using the tools to write apps and programs that their customers in turn use. Hence a cloud value chain. This, of course, does not take into account value added by cloud brokers or aggregators.
The interesting bit is what happens when the app is written and then launched. The current typical development cycle sees a dev team working to create an app and then making the architecture fit the app. This is backwards and I have lived it firsthand through cloud RFPs. This is because there is a gap in the knowledge and understanding of cloud computing among developers and their management. Schools generally don't teach students to write programs with cloud computing in mind. They teach them to write stand alone apps and programs that can be run on individual servers or, more often than not, in VMware-based virtual machines--AKA, the application service provider model.
The ASP model is inefficient because it relies on individual servers (whether virtual--no this is not cloud computing--or physical) to deliver the service and defeats the purpose of cloud computing: the flexibility to acquire only those resources necessary to meet demand.
In a perfect world, customers would acquire a SaaS seat via some self-service portal; the app or program would automatically create an instance or partition for that customer; and the app or program would be written on a PaaS to make it somewhat self-aware: that is, capable of making use of APIs to scale IaaS according to demand without mucking about with middleware. This raises the ugly spectre of vendor lock-in, but then, if you like the service, it meets your needs, and is flexible as you need it to be, why would you move?
There are three things that I've been thinking about lately:
- Performance management for cloud computing,
- Cloud computing and carriers (i.e., telecom companies such as telephony and cable), and
- The connection between the two.
The level of interest in what carriers are doing has been sufficient to warrant the attention of industry analysts and entire conference tracks devoted to discussion of the impact carriers are having on cloud computing. Depending on your perspective, you're probably in one of two camps: those who think carriers are too large, slow, and generally old school to offer cloud computing solutions, and those who think carriers are well placed to run them. For simplicity, let's call them cloud carriers. I know, a bit cheesy.
Carriers are typically thought of as large organizations that are not as agile as smaller organizations. The common analogy is that of trying to turn the Titanic on a dime: not so easy. Yet, here are organizations that have a wide ranging clientele that includes the likes of governments (federal, state, provincial, municipal), educational institutions and large enterprise, as well customers in the the mid and mass market segments. Not to mention that they have the scale available to fund and staff product development projects of the scale required to develop and launch cloud based services. This puts them in a unique situation with respect to offering end-to-end services ranging from customer premise equipment, connectivity, data centre, hosted servers, and all manner of cloud based services. Cloud computing, is not a huge stretch when taking this into consideration.
For many organizations, performance management forms a core part of their service delivery strategy. However, these same organizations don't typically control much of the infrastructure that is used to deliver their services beyond the edge of their network; non-core services are offered by various vendors such as ISPs, data centre providers, etc., which makes resolving problems more challenging because there are more intermediaries that affect the service. Throw in the various SLAs that are contracted, and the effective SLA drops to below the lowest contracted SLA.
Since carriers are able to offer a range of services, they are in the unique position of being able to address performance problems globally making it easier for customers to obtain assistance and becoming the proverbial "one throat to choke". Several carriers have already made bets that their customers will buy cloud based services from them and have either acquired smaller service providers or invested in the technologies and infrastructure required to deliver those services.
Despite the fact that AWS has clearly claimed the lead in the cloud service provider market, it is too early to count out carriers: they have the hallmarks of an integrated service provider as well as the means to deploy services and support them. Look to carriers to make an even bigger push into cloud services in the next few years.
