Public Cloud and the Hotel California Hypothesis


In 1977 the Eagles penned the lyrics:

“Welcome to the Hotel California 
Such a lovely place (such a lovely place) 
Such a lovely face. 
Plenty of room at the Hotel California 
Any time of year (any time of year) you can find it here” 
(Credit: The Eagles)

I was having a discussion on Twitter last month and it struck me how that Eagle’s song mirrors Public Cloud. Let’s do a highly subjective (and slightly tongue in cheek) selection of some of the lyrics!

Such a lovely place

Public cloud is very attractive for businesses. Public cloud offers:

  • The opportunity to smooth out capital expenses as operational expenses
  • Plenty of room due to the virtually limitless expansion of infrastructure
  • Flexibility
  • Automation
  • Universal access, often with a global distribution to enable easier customer connections
  • High availability and very reliable service levels

Such a lovely place indeed.  Many people, including myself, advocate moving systems and solutions to the cloud to make use of these benefits.  When advocating cloud though I do caution about the implications as they need to be understood before making the move.

We are all just prisoners here, of our own device

Cloud platforms either by design or circumstance end up with some form of lock-in to the platform.  This is a natural side effect of platforms.  All platforms provide some form of lock-in.  Be that at the hardware, OS or middleware levels.

The usual advice to avoid hardware platform lock-in is to move to a standardised middleware platform (e.g. WebSphere, WebLogic, Cloud Foundry, Kubernetes, etc).  This of course just introduces a new level of lock-in but arguably a lock-in with more options; as long as that platform has some longevity in the market.

To minimise lock-in, you could take a strategy of just using raw compute, network and storage from a particular cloud platform.  Therefore, you can move your applications and data to that new vendor without radical redesign (i.e. a lift and shift approach). You will still have a migration cost and likely a service management and procurement/billing/finance change but those costs will be small compared to modifying applications.

If you are in a 100% container based deployment environment then the Kubernetes Federation solution might at least allow you to have a cloud platform independent Kubernetes deployment.


This could be Heaven or this could be Hell

There is a catch however. If you take that lowest common denominator of buying only the basic services (compute, network, storage) then you are likely missing out on the rich products and services offered by the cloud vendor.  For instance, why would you want to spend the weeks of time and effort to create a production ready database platform from scratch when you can deploy a fully productionised Amazon RDS instance in tens of minutes?  It makes sense to take advantage of the available tools available doesn't it?  In reality, it is a balancing act. Some services, such as database as a service, will be common to one or more other vendors at the point of use and therefore are safe to use.  Others will be able to be recreated from scratch on a new vendor if necessary.  Therefore, where the cost lies is moved; it moves from being an "upfront cost" to a future "cost of migration".

The point is, lock-in is inevitable and needs to be managed and, like any other solution choice,  conscious architectural decisions need to be taken to balance the competing requirements.  Lock-in can absolutely be minimised but usually with the consequence of greater build and support costs. The decision whether to add in cost now or later is one that will vex many people I am sure.

Wake you up in the middle of the night

I think the ultimate consequence of public cloud is that, exactly like any technology platform decision in the past, moving onto something else is going to be hard. This is no different to favouring one particular RDBMS or Java Application Server vendor.  Just as IT departments make strategic decisions to move between hardware and middleware platforms then, in time, they will do the same with cloud platforms.

However cloud introduces some slightly different challenges to a normal technology platform change.  For example:
  • Most cloud vendors will charge you a metered per GB fee to take your data out of the cloud
  • The richness of services utilised on the original cloud platform could have major consequences on the application design if the target cloud platform doesn’t support those same services
  • Moving cloud vendors usually means moving physical location. Partners and interfaced systems might also have moved to the same cloud for convenience and the interfaces between the systems may expect local connections.

In time, we are going to be seeing more projects coming to market for the migration of applications and data from one cloud vendor to another.  There is a lot of room in the market for specialist cloud migration services providers to take on this work.

You can check-out any time you like, but you can never leave!

In summary, cloud is a fantastic technology platform and should be the default choice for a number of different scenarios. Lock-in is inevitable and we have to make a strategic decision on where that lock-in will be and look at the risks and costs associated with the future move to a new platform.

As the song (sort of) goes:  Public cloud is a lovely place; you can check-out any time you like; but  you may not be able to afford to leave!

Comments