Click on any box below to read more about its position in the broader vision

SaaS

SaaS is the software interfaces you're sharing with a customer. Either internal, or external. This is your product.

Data Services

Data services is tricky especially if you're going to build your own. Since the open service broker can be built in any language, you could front it with path based routing and split your team into capabilities based on language and service understanding. You need conversations around persistence (aws volumes not crossing zones etc). Do you even need to broker services if you're just doing cloud native? Ultimately even if you're just going to broker a cloud native data service, I think it's worth your time to put it into a central kubernetes cluster, and then even if that cluster is just using something like crossplane it's still the central point of visibility for who has what services.

The open service broker is simply a contract between a service provider and a platform on what the platform will provide when it requests a service and what will be handed back from the service provider. It can be written in any language and there's examples out there to get you started.

PaaS

Kubernetes has emerged as the leading container orchestration platform. You could explore google anthos, eks anywhere, or vmware tanzu. In my experience though rancher has been in the space longer and leads the pack in providing a unified interface and rbac to clusters spanning multiple IaaS providers. Building a central platform gives you enhanced operational visibility and an increase in organizational velocity.

IaaS

In my opinion IaaS is the easiest. Not that there can't be nuances, but it's still just everything you've already done through a new interface. I need a server, load balancer, disk, a network etc. It's still the same thing at its core it's been over the last decade. The biggest challenge tends to be vsphere because of organizational hurdles. Kubernetes often represents a paradigm shift that many teams are ill equipped to handle. Things like shifting away from traditional firewall models to dynamic network policies with something like istio/envoy can be a hard sell with traditional security teams.

Edit: A chrome update has broken the face visibility of the cards. Browser support for this functionality is always tenuous at best as it is. As of now, the page is best viewed via safari or firefox

First note that this is not plugins, site builders, copy paste. This is a pure html/css/js diagram that I incepted and built from scratch. It’s my vision on a broader platform architecture articulated through code.

This post is a culmination of 10 years experience across some of the largest companies on the planet into a vision that provides a cloud agnostic roadmap for application deployments. It’s geared more to organizations that have disparate business units functioning across multiple infrastructure providers seeking a single pane of glass from an operations perspective.

A simplified take on what you need for an application is usually a data service, and somewhere to run your code. Most enterprises are running their code in some sort of platform (Cloud Foundry, Kubernetes). That or they’re realizing that the traditional method of having an infrastructure team stand up VMs, networking setting up vlans, and negotiating red tape from security isn’t working. It’s not scalable or hinders velocity. It’s possible that they’re running shared databases and feeling the fallout from noisy neighbors or they’ve given developers free rein and are feeling the heat from ballooning costs of cloud provided data services.

The solution to these problems is to build a platform that spans multiple cloud providers. This should in theory allow you to migrate nimbly across providers barring some esoteric data service in niche spaces, in turn giving you an ability to organically reduce cloud spend, or negotiate lower costs depending on your account spend (I’ve been at companies spending hundreds of thousands a month).

There’s multiple Kubernetes aggregate providers out there. Rancher, Google Anthos, EKS anywhere, VMware Tanzu. Google Anthos at least used to have requirements for an F5 coming into your on prem installations, VMware products are always obnoxious because they’re closed source and even the tooling is hidden behind login and marketing walls, EKS anywhere (and the others) are newer products and it never feels good feeling as if you’re using a beta product. Rancher has a few small hiccups, but I can tell you it works in a production environment and solves the need of an central pane of glass for Kubernetes operations. Whether your developers are on prem or any cloud provider, its one location for all your clusters.

The Open Service Broker is a specification for brokering a data service in any language. Essentially it’s code that says:

OSB: “This is a catalog of services I provide”
Platform: “I’ll take service x”
OSB: Generates a service based on how ever you’ve chosen to write your code. You could go ask aws/gcp/azure etc for a data service and simply hand it back to the cluster. You could create a data services cluster and manage those via helm etc. Then hand those data services back once they’re provisioned. It’s literally anything you want it to be.
OSB: “Here’s the IP/URL and connection credentials for the service you requested”

Even if you’re just brokering a cloud native data service, I think there’s a lot of value in it. I’ve not yet seen anyone handle infrastructure tagging properly in a way that it can’t be bypassed or ignored. With the OSB you always know which services exist and who requested them. It also gives a similar interface to the developer for requesting a service across any provider.

The data services conversation is one that’s difficult to have agnostically. On prem you need storage providers if you’re going to build that out. I’ve seen situations where hardware is too old to upgrade the esxi hosts so then you have to look at third party storage layers like PortWorx. Now you need a few engineers to manage just that. Maybe you have them run this in the cloud too because AWS volumes cannot span AZs so you have to set up affinities for those volumes and it just gets muddy. If we’re going to have this magic platform where nodes come up and down, I want my storage to be able to move with that. Then the question is what are replication times across the az’s and can you build latency sensitive data services on top of that etc.

It’s a lot of work and you can lose time in the nuances, but if your cloud spend is a 50k+ a month, I think it’s a viable strategy to shift that over to labor and explore building these layers yourself. Then you touch down in any cloud, you’re going to lay down a storage layer, services layer and kubernetes. From here your developers have a unified interface to any environment.

For smaller enterprises, even if you’re pursuing this in one provider, I think it’s still a good value proposition. Chances are you’re going to continue to grow and it will set a strong foundation for that. You might leave the service broker on the back burner and just use cross plane.