The second blogpost in this series on cloud computing from a portfolio manager's view.
In my last blog I proposed to adopt a cluster-based cloud migration strategy. This way, I argued, cloud migrations could become economical even though there is no business case on the level of individual applications.
This is hard to do without some guidance, without some tool. Here I propose one - called the cloud matrix - that might help to get a better overview and to communicate portfolio decisons better.
There are two dimensions to be taken into account:
(1) Deployment options, of which three are important:
(Classical) on premises: Application runs in a data center that you control
“private”: Applications run in a dedicated data center that someone else controls
“public”: Applications run in a data center that someone else controls, and you share it with other tenants – the technical details of how this works are beyond your control
(2) The Technology (stack) dimension:
Non-standard / custom: Applications that are tied to a specific technology stack or on an enterprise-proprietary stack
Standard platform: Application runs on an industry-standard platform
Vendor-specific platform: Applications run on a platform which is maintained by one vendor, typically a big cloud provider exclusively, and does not comply to industry standards
“legacy” / “speciality”: So, you run a custom technology stack in your own DC. Pretty much the standard case before cloud computing.
Outsourced IT: You gave operational responsibility for your legacy / speciality application to some provider who runs it for you
“?” : A rare case, you run a custom technology stack in a public cloud. This does of course not work for every technology, but for some it’s a least possible.
Own “private cloud”: You run an industry standard cloud-technology platform (e.g. OpenShift) in your own DC. This happens a lot nowadays as companies try to move to new technologies but don’t want to give up control yet.
Provider “private cloud”: A provider runs a industry standard platform for you. You’ll have dedicated elements, e.g. your own servers. Monitoring / control and platform maintenance will probably be shared with multiple tenants.
Platform in the cloud: You use a standard platform offered as part of a public cloud offering. A good example would be OpenShift on Azure.
Cloud vendor native: You use a service / platform specific to a cloud-provider, such as AWS Lambda, Sage Maker, Azure Cosmos DB. The platform might be for specific use cases only or general purpose.
“*”: Well, I’m not so sure about this one. A bit a paradox. Some vendor-specific platform, but deployed outside of the vendors’ cloud? Azure Stack might be an example. This is a move of the cloud providers to get the use cases that for some reason (e.g. regulation) can’t go to the public cloud.
The portofolio manager now could create two instances of this matrix, one for the current situation, and one for the target. Every company must have a plan about where to go, which cells to fill and which to deliberately keep empty. The less different variants to support, the easier it is to achieve cost-efficiency.
Once you go down this road, it will quickly become obnvious which (big) decisions must be taken.