What is a Cloud Platform? What is a Platform as a Service?

Introduction

I am Katrina Bakas, I am a Senior Product Manager at Pivotal where we are transforming the way the world builds software. We do this by using a holistic approach combining Consultation, Education, and Software.

Agile Practice Leadership Enablement, App Transformations, our Labs consultancies help customers use Agile Extreme Programming to develop cutting-edge, cloud-native applications and containerised workloads. Our software solutions including Greenplum, GemFire, Pivotal Application Services (PAS), and Pivotal Container Services (PKS) enable software engineers to reduce toil and focus on building and integrating value-add software.

Here I will attempt to demystify what a platform, as in a Cloud Platform as a Service, is and how people are using them every day.

Let’s make sense of the chaos, together.

What is a platform?

A platform, in the sense of a Platform as a Service, is a system that supports putting software onto it and running that software. The “as a Service” portion of this title comes into play when considering how to manage that platform. Platforms have existed for a long time, originating with individual computers (that hosted and ran software), up to coordinating those computers to harness the power of scale to run software as a shared task, to more powerful computers (servers), being not only harnessed together but also sharing software on more than one. Platform as a Service, like Pivotal Cloud Foundry, provide a layer of abstraction to the wiring that happens between a lot of different components to harness the power of shared resources (a cloud). This abstraction is useful because it lowers the knowledge burden otherwise required for a customer to put together their own cloud and ensure they can operate it as one entity, versus many discrete pieces that require independent management.

Depiction of our value, allowing customers to focus on Applications and Data by reducing toil.

Indulge me an analogy, if you will. A Platform is a highly complex distributed system. A Platform as a Service aims to make that highly complex distributed system easier to understand and to operate. I offer you, as an analogy, a modern car as a highly complex distributed system.

People (customers) use cars (platforms) to get from point A to point B as efficiently as possible. Customers use Platforms to meet the needs of their customers as efficiently as possible. A car is a (high) number of independent components that are forged together to form a more powerful machine. A platform is… well you get the idea. The jump from a car to a modern car comes in when you introduce abstractions for a customer to be able to focus on their objective (to get from Point A to Point B). It was a huge leap to go from horses (that previously got someone from Point A to Point B) to the Ford Model T and a similarly huge leap to go from the Ford Model T to, say, a modern day Toyota Camry. Imagine all of the individual parts that comprise a car (about 30,000!), and how considering this, it’s really a miracle that we as humans can rely on them for so many things each day. Imagine if you, as a person who needs to get somewhere (Point B) from where you currently are (Point A), a person who is trying to use the power of a car (much more power than say, walking or even riding a horse) to your advantage to get to your destination more quickly, were required to know what each part of your car did, which ones mattered most, and what to do about it if any one of them broke. Instead, this complexity is largely abstracted away from you as a driver and distilled down into very simple solutions that all come together to form the straight-forward way of driving your car you know today. As a Platform as a Service provider, we abstract away a lot of the underlying complexity from our customers. Instead of explaining the intricacies of a combustible engine, cars offer us an ignition switch or button and take care of firing it up for, instead. This is the same experience we aim to offer our customers — simplify down the highly complex nature of wiring up computers to create a powerful distributed system into an experience that is easy.

Image borrowed from Chegg.

I’ll carry this analogy throughout this writing.

Why do customers buy platforms?

For the purposes of this writing, a customer is the group of people that buy a platform. Customers buy a platform because they have several needs.

1. Run software
2. Write software
3. Support both of the above reliably

Running software

Their primary need is to run software. I postulate that running software is a need before writing software is a need, because one could buy software that is already written and run it. Customers need software to run because software provides something to them — perhaps it gives them the ability to charge a customer of their for a service, or provides the ability to communicate to another piece of software. The purpose of the software is of little relevance to us, it is just important to know that the software carries a lot of value to our customers. Said another way, customers care a great deal about the things (software) they are putting onto what we provide them (platform). Some examples of this business critical software include: HR systems (a failure here could cause people to experience delays in getting paid, or health care claims to be delayed, etc.), health monitors in hospitals (failure here could be catastrophic — imagine a telemetry machine unable to communicate with a central station), internal messaging software (loss of productivity — perhaps gain in productivity) , down to smaller packages, yet still crucial software, like APIs to effectively communicate between software.

Writing software

Being able to write software is also important to our customers. The more efficiently and effectively that they can write software that can run reliably, the more things they can accomplish. Please note that writing software does not necessarily mean writing from new, but also integrating with other software, improving existing software, or any number of additional possibilities.

Supporting writing and running software reliably is, you guessed it, also important. A quick Google search of `reliable` provides this definition: consistently good in quality or performance; able to be trusted. As stated above, the software that customers want to write to then run on their platform is important to them, so it naturally follows logic that they want to know the platform can run reliably, so that software may run reliably on top of it. Customers count on our platform to run reliably because they aren’t writing software for funsies, they’re writing software that accomplishes their goals, and that software must be able to function predictably and reliably to the extent possible.

The people aspect

The people aspect is the least commonly discussed but perhaps one of the most prevalent factors for why customers (companies) buy platforms. A company is comprised of people, and in this case we’ll discuss people who operate and utilise the platform. While a company’s main goal is to produce a service (that needs software) to earn money, the people who work for a company often have many different goals. One of those goals is to gain expertise. In this way, a platform not only provides its core services (hosting and running software), but also an opportunity. If the platform provider can additionally offer the maintainers of the platform the ability to operate it well, then the platform provider offers that operator a marketable skill. The user of the platform gets the same benefit — being able to use a new or different place to run their software. This expertise and increase of skill is a motivation for the operator and the user, of course. It’s also a huge asset to the company because having people do better at their jobs allows the company to do better work more often. Another opportunity that presents itself is not only is there value in enabling people to become experts, but in also providing them the chance to contribute their expertise to the platform as well.

What do customers need to run platforms?

Now would be a good time to remember customer goals. Customer goals are all centred on the principle that they have business-critical software that must run reliably. If it doesn’t, their business is on the line. To that end, what matters most is that their software can run and run reliably. Keep in mind that businesses are focused on two things — solving problems and making money while doing so. Therefore, one can imagine, their goals are to be enabled to solve problems as quickly and robustly as possible and to spend as little money as possible to do so. We’ll keep these motivations in mind as we continue.

In order to run platforms customers need to know what success looks like: success for running a platform looks like being able to host and run software reliably over time, and to be able to improve that software over time while continuing to have it run, in order to meet the needs the software is meant to address.

Enabling customers to write good software quickly

Folks who are writing software generally have the goals of writing the best software they can, in the fastest way possible. This often means reusing existing software where possible, and understanding how to integrate it with other software to achieve their objective. The more quickly they can do this with the best understanding possible, the more they can build and maintain. This means that the person writing the software needs to be able to easily discover what already exists and what it does to be able to evaluate if they might use it. It’s a great perk if it’s easily integratable.

Here’s where we’ll dive into a little more of the specifics about how we enable customers to write good software quickly here at Pivotal.

Good software is: software that has a purpose, fulfills that purpose, and runs reliably so that a user can count on it to fulfill its purpose. There are many ways that we support those goals at Pivotal. An incomplete list includes: buildpacks (code compilation, reducing the toil of packaging and deploying software), consulting, Spring acquisition (Spring Boot is a powerful development framework that speeds software development for engineers who utilise it), and our open source software contributions so that others need not duplicate work when possible. Additionally, by providing a platform that communicates about successes and failures (and is self-reporting), we enable customers to write good software by helping them answer the second half of the good software questions: is their software is running reliably? We do this by supporting functional tests, metric emissions, and logging emissions for software on our platform. This means that we provide customers with immediate feedback about whether or not their software is able to run reliably.

We now understand the appeal of platforms and some of the ways in which we (Pivots) enable customers to write good software quickly. Let’s dive into the platform itself side of things.

So, you want a platform…

Customers want platforms because platforms will enable them to write good software quickly, then to run that software reliably over time. Pretty impressive opportunity, I’d say! To get to that goal, customers need an efficient and reliable way to set up that platform even before they buy it. Why? So that we can show them the value of what it would be like.

This breaks down into a pretty simple objective: Get a platform up and running as quickly as possible and get software onto that platform as quickly as possible. In Onsi’s famous words, this boils down to:

here is my source code

run it on the cloud for me

i do not care how

We do this today with a variety of solutions including our flagship products — PAS and PKS. It takes a village, though. As mentioned earlier, a platform is a complex distributed system and a Platform as a Service is a set of abstractions that simplifies that complex system. So setting up that complex distributed system in a way that is simple to a user is the ultimate goal here and includes: provisioning computers — either by tying them together with networking (on premise) or by buying a prepackaged bundle (public cloud), managing access to those computers, giving that access to users (people writing software), and ensuring that those computers perform the way they’re expected once strung together. In today’s complex technical world this involves many different layers of technology and permissioning, though our aim is to continue to make that set up as efficient and reliable as possible.

Though it’s easy to think of the components that we provide to do this (Diego, Routing, and even PAS or PKS), it’s important to note that customers’ requirements of platforms vary widely. Some customers have relatively simple software that doesn’t require a lot of additional setup to run, other customers have complex software or many different pieces of software that require other components that we call Services as well. These are not optional add ons for our customers, because they need them in order for their software to run — a primary goal.

This combination of things that enable our customers to run their software is what we refer to internally as our One Platform. For some customers, that includes a combination of PAS, PKS, and many service tiles to truly meet their goals. I’d venture to guess, however, that they are not particularly concerned about what all of the discrete components are, and instead care most of all about their primary objective — to run software to meet the needs of users.

As much as technology is at the core of what we do, it’s not the most important thing we do. Software without the knowledge of how to use it is useless. That means the most important thing we do is create solutions to customers’ problems and enable them to use those solutions. This takes many forms and includes, but is not limited to the following:

• Simple, sensible solutions
• Documentation
• Integratable solutions
• Hands-on enablement

To sum all of this up, let’s rely on our car example. As a driver, if my goal is to get from Point A to Point B as quickly and safely as possible, and while previously I had been cycling everywhere (can accomplish the same task with not as much power), I now reach for my car keys. I understand the value of having a car and have chosen to invest in one myself over say only having a bicycle because I know it enables me to go further, faster, and with more safety than I can go on my bicycle. I could have, theoretically, gone out and purchased the 30,000 parts that comprise a car and assembled it myself having tuned various pieces to make it exactly how I wanted it but I didn’t. That would have deterred me from my objective of getting from Point A to Point B as quickly and safely as possible. On the other hand, I bought a fully formed car and had very little set up to do — I adjusted my seat, aligned my mirrors, put fuel in it, and took off. Furthermore, I am assured that the maker of my car compiled the bits together properly, safety tested it to a level of my comfort, and provides me with enough information (a car dashboard, in this case) to know that I can operate my vehicle.

So you have a platform…

Now it’s time to run that platform and keep it running! As with all technology, one of the most important components of running a reliable platform is to keep it up to date. This could be a huge tangent, instead we’ll keep it short. In order to keep a platform up to date, a user must know how to do so and have confidence in doing so. Additionally, if their platform is working just fine, they must have a compelling reason to upgrade, therefore those compelling reasons must be discoverable to the user.

One of the biggest challenges that customers face is being assured that their platform is running. Sure, that sounds silly and simple, and it can be, yet is often made overly complex. We’ll call on our car analogy for this explanation. How do you know your car is still working since the last time you operated it? Typically you turn the key (or press the button), have it fire up, and glance at your dashboard before driving away. If you don’t glance at the dashboard it’s because you are so confident that your car does work, it’s like because you don’t need the reassurance. Wouldn’t it be great if we could give customers this level of confidence?

Next, while you’re driving your car surely you assume that all is well unless told otherwise (usually by a dashboard icon, or in severe cases, a dashboard icon and a noisy reminder). As a driver, it’s unlikely that you want to constantly be told how your car is performing. Sure, most cars have dials you can turn so that you may reveal more information (currently miles or kilometers per gallon, engine temperature, distance worth of fuel left, etc.), though usually those require some user intervention to reveal. This is because you want to assume everything is fine until it’s not. Furthermore, when things are not fine, you probably want to know what you can resolve and what you might need help with. For example, most of us are not trained mechanics so the number of things we can do to keep our cars running is pretty limited. If a low-fuel indicator comes on, then most of us know how to fuel or charge up in our own vehicles. However, if a grave “check engine light” comes on, most of us would rely on a trained mechanic or at least a computer scanner to let us know what the problem is.

Platforms are similar. Our users generally want to know that things are working and in an ideal case, want to trust the platform so much that they do not want to have to check every knob and dial in order to be able to make that assumption. Imagine if, in order to be assured that your car was running and safe, you had to review an indicator for each and every component of your car. None of us would go anywhere. It is imperative that only give customers the information they need to know their platform and software are running and reliable. Over information is defeating, actionable information is powerful. Furthermore, empowering customers with the information about what they can control and how they can control it (what they’re likely capable of fixing and how they can go about doing so, which tool to do that in, etc.) is delightful. Giving customers tools to solve problems they are capable of solving along with frameworks for how to determine if they’re capable of solving a given problem will lead to the best outcomes. Providing customers with approachable resources for when they cannot self-resolve is, of course, also of paramount importance.

Today we do the above in a variety of ways:

1. Observability — by offering customers data about their software and their platforms, we are enabling them to know if they are working or not.
2. Platform and Software management — by offering customers ways of solving some of their problems (maybe increasing capacity by scaling or adding additional services to meet needs)
3. Health checks for customers — a check in with experts (us) to understand how they are doing and to offer tips and tricks
4. Telemetry — providing us (internally) with better tools to understand where gaps are for our customers’ enablement

So you want to grow your platform (or turbo-charge your car)…

Typically, when you like something you want more of it and want to share it with others. That’s the usual behaviour for customers who buy platforms too. When they see the value and ease of it, they want to be able to share it with more users and to use it for more things. Additionally, as we talked about long ago in the people aspect, we know that some users are likely to become super users (some car drivers will want to become mechanics — maybe hobbyists or fully knowledgeable), and we should do our part to support that. For the sake of simplicity, I’ll break down customers’ desires to grow the platform into two groups:

1. More usage
2. More features

Both of these desires certainly affect each other and I’ll weave that together after discussing each.

More usage

So you have a platform, you’ve seen the value it brings for you to have it, and you want to grow its use. In some cases this can mean adding in more software to the platform (onboarding more apps or services onto the platform), in other cases it can mean scaling the software that is already on the platform (increasing app or service instances). In many cases, it’s both!

This desire can stem from many different places ranging widely from seeing its value (oh I have a car, I can use it to do many things now!) to being told to increase its use as a mandate (maybe I’m an older sibling and my parents have told me I’m now in charge of delivering the younger ones to all of their after school activities). So the best thing that we can do for our customers is to help them increase use of the platform! We can make it easy for them to move more software onto the platform (similar to starting to use it) and to rest assured that the platform can handle this increased use. In our car analogy, this is continuing to drive more and more, and knowing when to perform maintenance and when to keep pushing the pedal to the metal.

“More” in American Sign Language.

More features

Like more usage, more features is often a great problem to have. In a healthy state, this means that a customer has seen the value of a platform and wants to do more with it. This can mean even changing the type of use of the platform. For example, a user might decide that they want to increase flexibility of the platform for their own users (say maybe offer software writers the ability to control their environment more — looking at you, k8s) or perhaps offering a variety of platform tools (say more than one type of database for users to choose from).

Maybe in this case I’m feeling really confident as a driver and I want to turbocharge up my car so I can go even faster — what might I need to know to decide if I’m ready for more power like that?

Conclusions

Our products will continue to evolve as long as the market continues to evolve and customers will arrive at a need for platforms with many different reasons, though the underlying need of running and writing software is unlikely to go away. In order to continue building great products for our customers we must continue to understand their needs in the simplest terms possible, thus providing them with the most simple solutions possible. The more we understand our customers’ motivations and their starting points, the better position we are in to be able to tell our story and propose our solutions effectively, having the confidence that we built them for the right reasons. I believe that we are armed with the information we need to make our customers’ lives better every day.

What we often see as many different products should be considered one product, of which we are all contributing to parts of- a platform that enables customers to run and write good software as efficiently as possible.