We’re moving back… on prem – but with what?

(originally published in December 2019)

IT is all about cycles. Let me illustrate that from my own experience. I’m in the business now for over twenty years. When I started off, the big thing was – really – mainframes or a-like systems. Big iron that could contain multiple workloads. One of the first big projects was moving two HP Superdomes to one of the datacenters of my employer at that time. Both machines – really loved the superdomes, fantastic piece of technology – hosted around fifteen mission critical applications for the client. The machines were in our datacenter, client connected to the applications from all over Western-Europe and Asia. For the US-region we had exactly the same set-up in our Texas datacenters.

We did not call it cloud, but in fact it was what we call cloud today. ‘Using someone else’s computer’. Once we had LPARS. Now we have vm’s and containers.

Today, most companies are planning or are actually in the midst of getting all of their workloads to the cloud. We have a selected number of major platforms that we use to host the workloads: Microsoft Azure, AWS, Google Cloud Platform and that’s about it. I know: there are more platforms, but let’s be frank here: the three mentioned are the dominating ones and will be in the forthcoming decades. Yes: I will take the bet on that statement.

But there’s a funny thing going on right now. In planning and migrating workloads to these platforms, we also find out that it does get complex and, even more important, there are more and more regulations in terms of compliancy, security and privacy that force us to think twice before we bring our data to these platforms. And it’s all about the data, in the end. It’s the most valuable asset in any company – next to people.

The solution: instead of bringing data to the cloud, we’re taking the cloud to the data – again. In fact, we are in a sense getting back to where IT started: on premises. We’re seeing a new movement where the major cloud providers start stepping into the domains where other companies still were dominant; companies like storage providers and system integrators. The new reality is that public cloud providers are shifting more and more into the on prem domain.

A couple of weeks ago I published a blog on the Azure Stack portfolio with Stack HCI, Hub and Edge, the on premises and private cloud solution of Microsoft Azure. Naturally, there’s more to come from the other major players. The two most important, sort of recently announced ‘products’ are AWS Outposts and Google Anthos. Both really differ from Azure Stack. So, one of the first questions is: how should business get to the right choice in these different technology stacks.

Let’s have a deeper look at Outposts and Anthos. Basically, both are appliances, extending the public clouds of AWS and GCP into the ‘privately owned’ datacenter.

AWS Outposts

Everything you run in AWS public, you can now run it on an appliance, including EC2, EBS, databases and the Kubernetes-clusters with EKS. It all seamlessly integrates with the VPC that you would have deployed in the public cloud, using the same API’s and controls. The logical use case is that an enterprise that for compliance reasons has to have certain environments on premises whilst applying a public cloud-unless principle, can have it now using Outposts.

However, they might want to hold their breath for just a second. S3 storage – the product that started off AWS – is yet not available on Outposts. According to Amazon it is planned for some time in 2020.

Another question might be what this means for the VMC on AWS proposition that both VMWare and AWS have in their portfolio (you can buy VMConAWS through VMWare or through AWS). VMConAWS actually extends the private cloud to public cloud, based on HCX by VMWare. Under the hood VMWare gets bare metal in AWS to which vSphere, vSAN and NSX is deployed. Next, you can use AWS services on top of the configuration. Outposts works exactly the other way around: bringing AWS to private.

Confusing? It gets worse. Read this on the AWS product site: ,, Coming soon in 2020, a VMware variant of AWS Outposts will be available. VMware Cloud on AWS Outposts delivers a fully managed VMware Software-Defined Data Center (SDDC) running on AWS Outposts infrastructure on premises.” To put it very simple: you can get VMWare on fully managed appliances by AWS. Are we looking at a game changer here? We just might, yes. It certainly means that AWS is broadening its portfolio big time, shifting into on prem, even with VMWare – still the number one virtualization platform: most enterprises have their servers and storage virtualized with vSphere and vSAN.

Google Anthos

Fair enough: Anthos brings Google Cloud to the on premises datacenter like Stack does for Azure and Outposts for AWS, but it focuses on the use of Kubernetes as landing platform, moving and converting workloads directly into containers using the Google Kubernetes Engine (GKE). Anthos really accelerates transformation of applications to more cloud native environments, using open source technology including Istio (microservices) and Knative (scaling and deployment of cloud native apps on Kubernetes).

Geek stuff, right? Not really. This week I attended a tech meeting of developers who mainly work for governmental institutions in the Netherlands and, honestly, I was seriously surprised by the speed in which all of these guys have adopted cloud native, container and serverless using open source tech. Might be geeky, but it’s also the new reality. It’s there and it’s being used, intensively.

Multi-cloud Integration

The best part of the story is yet to come: we are really heading for multi-cloud. All of the platforms that I’ve described have advantages, disadvantages, dependencies and even specific use cases. Hence we see enterprises experimenting with and deploying workloads in more than one cloud. That’s not just to avoid cloud vendor lock-in: it’s mainly because it’s not an ‘one size fits all’. Some features, application code, API’s or integration perform better on cloud X then in cloud Y. There might be security (risk mitigation) reasons to have workloads spread in different clouds.

And here’s where the system integrators come back into the play – as long as these system integrators also really understand how all these different stacks work, what the different characteristics are and what benefits they bring to their customers.