In part 1 we saw how the changing strategy of many public IaaS clouds has been to increasingly offer PaaS style services on top of their core product offering. It is easy to see why public IaaS cloud vendors might wish to do this in order to increase their revenues but is it in customers’ real interests?
One impact is to have a lock-in effect on the customer base (using PaaS) to the particular cloud which is something customers might want to think about carefully. There are some even more worrying problems associated with the move to PaaS as the IaaS provider increasingly widens their role and comes into conflict with users of their own cloud. As I outlined below, a IaaS cloud vendor offering PaaS has a significant long term impact on choice for customers and the role of a cloud vendor as an independent provider of computing resources.
One of the primary motivations for IaaS cloud vendors to offer their own in-house PaaS services is that they feel they have a captive audience. Integrating PaaS services into their existing web portal is relatively straightforward and with little or no marketing the cloud vendor can add additional high margin revenue from their existing customers. The more customers use different software level services from the cloud, the more locked in they are which is problematic for customers. If you are using a cloud for both your cloud infrastructure and other related services from email to DNS to databases, if for whatever reason you wish to move to another vendor, this is going to be a wholesale move of your entire operation. As such, using services provided by your cloud vendor whilst looking convenient up front, in fact creates a very entrenched situation for the customer which is difficult to escape from.
Vendor lock-in is not something that is desirable for customers and should be avoided if possible. The effect over time is to allow the vendor to raise average prices to locked-in customers which is achieved in many well known ways. Companies can and do change over time so even if you think your current cloud vendor is great now, that might not be the case in the future, especially if they get taken over for example. Maintaining a level of vendor independence pays dividends over the medium term. This allows you as the customer to migrate or focus your infrastructure away from a vendor that you are experiencing deteriorated quality of service and/or performance from. The way PaaS is purchased and from whom should form part of that strategy.
A cloud like CloudSigma’s does not require a customer to relinquish control of their technological vision and choices over time. That’s because our customers have full control over the software and networking layers so they can form infrastructure in a flexible way, effectively installing whatever operating systems and applications they like. A move to a PaaS offering effectively ties the customer’s cart the the horse of the vendor so again this is important to appreciate the implications of such a move.
This comes down to fundamentally whether you feel technology will keep re-inventing itself and evolving through creative destruction or if we’ll see convergence and some abstraction from computing processes. The technologies companies employ today look very different to the set-ups they had just five years never mind ten years ago. Moving to a PaaS offering relinquishes control to the vendor and often creates significant lock-in issues. A good example of this is database as a service. I like many database as a service offerings that I’ve looked at and they have a very interesting role to play in many customer cloud infrastructure however it is important to appreciate the trade-offs when moving from a database system managed in-house (albeit on IaaS) to a fully fledged PaaS offering. What happens if a new style database comes along offering significant benefits over your existing PaaS offering? Would you have to wait for the vendor to offer something similar if ever? If you had to migrate off the PaaS system, how would that work in practice? The answers to these questions might not change your decision to use a PaaS offering or not but the process is useful in itself and helpful in setting things up in the correct, most flexible way for you up front.
One of the main reasons why we would never ‘cross the Rubicon’ and offer in-house PaaS services is that doing so would put us potentially into competition with our own customers. Our open and flexible approach to IaaS has attracted many PaaS vendors who run their services from within our cloud. We are ideally suited for that purpose. The moment we start adding our own services that may compete with theirs, we fundamentally change our relationship with them and create conflicts of interest with the operation of our company that just don’t exist today because of our pure IaaS approach.
Every time Amazon Web Services (AWS) offers a new PaaS product in conjunction with their EC2 offerings they are competing directly with some of their customer base that was previously using their cloud to offer a similar service. If you were a PaaS vendor, when choosing a cloud vendor, would you like to run your service from a cloud that is offering or might offer in the future a directly competing product to your own?
The issue is more significant than simply ending up hosting your PaaS service with your competitor. Running a competing PaaS service with an in-house vendor service is like playing away in sports; the home team has a huge advantage. For example, when AWS launched their email service, at that time many leading email service providers were utilising EC2 for mailing services. What are the incentives of the vendor versus customer when the customer is trying to compete with the vendor? It is a mess!
Coming back to the database as a service example, if I were to launch such a service on AWS, it would compete directly with their own in-house service. What kind of SLA does the in-house service of AWS effectively get compared to the one that I could achieve as a customer running my own PaaS offering with AWS? Worse, their in-house services are able to deploy in a highly flexible manner without the same restrictions on standard server instance sizes, networking restrictions and the many other standard boundaries imposed on a customer of the cloud. As such, it is likely that I would not be able to build an equivalent level of performance or flexibility for customers which when combined with the unified billing and product placement of the cloud vendor pretty much dooms the service to failure. This is a general problem with any cloud offering its own PaaS service and by no means specific or limited to AWS.
In the US Netflix, the leading movie streaming service, is estimated to account for some 20% of peak internet traffic! Although operating a couple of data centres themselves, the company chose to migrate to the cloud and now largely uses Amazon’s EC2 service. As a result, EC2 benefits from the bulk purchasing of data traffic that Netflix necessarily purchases from them in the course of its operations in their cloud.
Netflix are known to be happy with their cloud experience and Amazon clearly aren’t complaining so what’s the problem? Well, Amazon just launched a video streaming service which is a direct competitor to Netflix and their strongest competition currently. Netflix are hosting much of their infrastructure with their biggest competitor. Not only this but Amazon will likely be benefiting from lower data transfer costs over their whole operation as a result of the additional traffic that Netflix puts through their cloud! It is a neat trick but how do Netflix shareholders feel about it? 🙂
Many services related to cloud infrastructure for performance reasons need to be run at the same location to be usable in the real world in terms of latency etc. Again database as a service is a good example here. As we’ve seen, a cloud vendor that keeps rolling out it’s own PaaS services in-house will discourage other third party PaaS providers from running such a service within their cloud. As a customer of that cloud I am poorer for it as it is likely that I’ll have less choice of PaaS services in such a cloud over the medium term. The net effect of a cloud vendor offering their own PaaS is that it reduces the effective choice of these services for customers using that cloud. Additionally, unless you think your cloud vendor will be the best at everything they do in relation to services, it is likely that you’ll have to settle for offerings that aren’t best of breed and miss out on potential competitive advantage.
So, what might seem like a pretty innocuous decision for a cloud vendor to offer some PaaS alongside its core offering can actually mean less choice and innovation for customers using that cloud vendor.
We offer an alternative vision of IaaS. We want to encourage as many PaaS and SaaS providers to run offerings from within our own infrastructure. You could say this is purely self serving of course however the other side of the coin is that we have no intentions to start offering competing services ourselves. The result of this policy is a growing choice of services running within our cloud, offering excellent performance to all our regular IaaS cloud customers and an open choice of providers. Our approach means as and when innovation happens, it is easy to deploy new software and technological advances within our cloud and create new PaaS offerings from them as well.
Customers of CloudSigma can feel confident that they will have continued access to best of breed services from within our cloud infrastructure set-up by themselves or provided by leading companies in each respective technology area. We encourage all our customers to employ a multi-cloud vendor strategy giving strategic independence and we provide the free, convenient tools in order to achieve this easily.