Cloud Foundry: Brazen Opinions And Easy Extensions

September 21, 2016 Jared Ruckle

 

36525-opinionated-platforms-sfeatureSoftware is still eating the world, five years after it started.

As companies scramble to become digital businesses, the challenge invariably boils down to how well you build software, and more specifically how rapidly you can iterate on that software.

This is where platforms come in. You need a platform to run and operate all this custom software you’re now building. So, do you want an opinionated platform, or an unopinionated platform?

IMO, You Should Go For An Opinionated Platform

The Cloud Foundry community often proudly proclaims a key part of its current success and future lies in the fact that it is an opinionated platform. But what is an “opinionated” platform? The existential questions of how to deploy to the platform and run apps on the platform are answered in a specific, if not rigid, way. To boost productivity along a prescribed path, fewer options are exposed to developers and operators.

Less opinionated platforms optimize flexibility in the guts of the system, offering more freedom for “do-it-yourself” implementations that feature custom components. More opinionated platforms provide structure and abstraction—“the platform does it for you.” Users are then free to focus on writing apps on top of said platform. And free to rapidly iterate on their apps, and reducing time-to-value for new features.

Cloud Foundry is one such highly opinionated platform. Those opinions are formed and codified with the belief that platform decisions should help customers deliver new, high-quality software to production as fast as possible.

"If you’re building apps that matter, deploy to a platform that puts the attention on developer productivity" <-great advice from @rseroter

— James Watters (@wattersjames) September 9, 2016

 

Other opinions matter of course. Application portability across clouds, and a vibrant, open source community shape our strategy too.

But it’s important to be flexible where you can, especially when your platform serves the most demanding (and highly regulated) market segment, the Forbes Global 2000. That means you need clear opinions on how to extend the platform to meet a long tail of business challenges.

Under that backdrop of extensibility, here’s a look at the opinions that shape Cloud Foundry, and how they are realized in the platform.

Opinion: Developers shouldn’t be responsible for configuring middleware and maintaining app dependencies.

Why we have it: Two reasons. First, developer productivity goes down. It’s plumbing that the engineer now has to think about. Second, systems get less secure. Each developer has to make their own decision on how to manage these dependencies, since it’s not enforced by the platform. This introduces variation and risk.

How this opinion is represented in the platform: Buildpacks.

Buildpacks manage the language/framework dependencies for an application in Cloud Foundry. When an app is deployed via cf push, Cloud Foundry associates the app with the right buildpack (Java, Node.js, Go, whatever is needed). Developers don’t have to think about dependencies, middleware or runtime components—the platform does it for them at deploy-time.

Buildpacks boost security as well, since they are easy to audit and control. IT knows what’s running in a production environment at any given time because applications and their buildpacks are deployed (and logged) in a consistent, repeatable way with each cf push command. When a CVE hits, or there’s some other concern, buildpacks make it easy to assess risk. And once a buildpack is approved by a security team, developers just have to make sure their actual application code meets the requisite standards before they can deploy to prod.

Does your app require a buildpack that’s not yet supported by Pivotal Cloud Foundry? No problem! Use a community supported buildpack (including this one for .NET Core!), check out the Heroku community, or build your own. This is a great example of a how our strongly held opinions can be easily extended.

.NET Core buildpack is live on https://t.co/c3ylQUOA88 … w00t. pic.twitter.com/g4Yvfcd8w4

— Mike Dalessio (@flavorjones) September 13, 2016

 

By contrast, an unopinionated platform allows for more customization of the layers in an app. It’s now up to the developer to think about the run-time layer, as well as the OS image. Since this isn’t packaged up systematically, variation is now introduced into the platform.

This is variation has major consequences when you’re running at scale. When the next Heartbleed happens – or the next security audit, for that matter – it’s much harder to find the vulnerable applications, let alone fix them.

Reduce your risk, keep developers happy. Use Buildpack and get on with coding great apps.

Opinion: A unified, structured way of connecting applications to other services makes life easier.

Why we have it: Applications connect to other services to function properly, and to ultimately deliver value. And without a standard way to bind apps to services, developers end up writing and maintaining custom code across an endless number of components. That’s a distraction from modernizing the business.

How this opinion is represented in the platform: Service Brokers.

Cloud Foundry is a structured platform with a clear philosophy on how developers integrate apps with other services: use a Service Broker!

Chip Childers explains the concept in a recent piece for The New Stack:

“So what exactly is the Cloud Foundry Service Broker API? Think of it as a clean abstraction that allows “services” to expose a catalog of capabilities, as well as the ability to create, use and delete those services. For this to make sense, the word “services” needs a bit more of a definition. We consider services to be any software or system that applications depend on for various capabilities, either as external dependencies or platform-level capabilities provided to the application.”

The Service Broker API is an interface between PCF and the service provider. It acts as a translation layer that the service provider implements, for which PCF is the client, that abstracts PCF from having to know how to talk to different service providers. Once PCF delivers credentials to an application that it obtains from a service provider via the broker API, an application may communication directly with the provisioned service. And since each request is authenticated via HTTP or HTTPS, this design is useful for common enterprise security requirements as well.

Here’s a deeper look at the Service Broker interaction flow:

managed-services

Services Brokers can work with any outside services as Chip notes—a database, object storage, Github repo, API management solution, or CI pipeline tool.

Services Brokers are our opinion on how to extend the platform, and adoption continues to grow. Big companies and startups alike are adding new services to the ecosystem all the time, and now Microsoft and Google are developing their own Service Brokers!

“We have even begun to see large cloud providers like Google and Microsoft expose their native platform capabilities via the API. This growing ecosystem of service providers has quickly become one of the major attractions for organizations considering adopting a platform like Cloud Foundry.”

These new additions extend Pivotal Cloud Foundry to their respective native cloud services. This gives customers more choice in where to run their mission-critical workloads on PCF.

Great opinions spread. This is evident in the world of open source, and it’s awesome when other communities know a good opinion when they see one.

I wrote a thing > https://t.co/AhvrNEWkK5

— Chip Childers (@chipchilders) September 19, 2016

 

We’re jazzed that the Service Broker pattern is finding its way into other open source projects and even other platforms. As these patterns become the norm, life gets that much easier for developers and operators. Put an end to yak shaving!

Opinion: Containers are at their best when they are boring.

Why we have it: From the very beginning (2011), Cloud Foundry has run containers under the covers. The original rationale, which still holds true today, was two-fold:

  • Containers can better utilize the underlying infrastructure
  • Containers can provide consistent, production-ready, resilient environments for developers in a highly productive and easy-to-use manner

But containers, like all technology, are at their best when they just work.

How this opinion is represented in the platform: Garden runC

The recent hubbub over the future of containers is a good reminder that technology is at its best when it is invisible. Or as my colleague Richard puts it:

“The infrastructure that your application depends on should be stable and reliable—dare I say, boring!—so that you can spend all your time delivering innovative cloud apps.”

This is the approach Cloud Foundry has taken for a few years now, as he details in a wonderful blog post. Containers are a fundamental part of transforming application development. But it’s a place to start, not a destination. You can use Docker with Cloud Foundry, an example of the extensibility into the platform based on a shared heritage of Linux tooling.

Opinion: We should run everything “as a service” first, before releasing to customers.

Why we have it:You build it, you run it” is a proven way to help companies deliver high-quality software rapidly and repeatedly. This is just part of being a responsible partner to our customers. We want to be the first ones to uncover an issue with our code, and running our software at scale is the best way to do that.

How this opinion is represented in the platform: Pivotal Web Services.

How do opinions and extensibility work in practice today? And how do they work as the platform evolves? Public cloud providers and the top SaaS companies run their new features first as a best practice. With platform products, though, it’s murkier.

At Pivotal, we have Pivotal Web Services (PWS), a commercial multi-tenant instance of our latest bits that we run before releasing the single-tenant version to our customers. This process ensures stability of new features and compatibility with how customers have extended PWS. Releases are then hardened based on real-world usage and feedback. (Timely example: our .NET Core Buildpack BETAS for PWS announced earlier this month).

Systems are more reliable when internal teams are consumers of the system too.

FACT: In the software economy, Rapid Iteration is how you win.

This fact comes from our VP of Cloud R&D Onsi Fakhouri during Spring One Platform. Opinionated platforms like Pivotal Cloud Foundry can help you win faster than unopinionated ones, because you get a proven platform that does so much for you ‘out of the box’. Rapid iteration and time to value are so much easier to achieve.

If these opinions resonate with you, what’s the next step? Acknowledge another fact espoused by Pivotal’s own Casey West:

“When working with cloud native software, you don’t have the luxury of picking just two items from the trio of microservices, DevOps, and continuous delivery; you need all three. Microservices is the architecture, DevOps—specifically CALMS (collaboration, automation, learning, measuring, and sharing)—is the culture, and continuous delivery is the process. All three aspects are required to achieve consistent throughput with low risk in your software-delivery process.”

Accelerate your digital transformation with the conviction of Cloud Foundry’s opinions, and extend them to suit your business. Let’s start the conversation!

 

About the Author

Jared Ruckle

Jared works in product marketing at VMware.

Follow on Twitter Follow on Linkedin More Content by Jared Ruckle
Previous
GoGaRuCo Tracker demo
GoGaRuCo Tracker demo

We had fun during lunch at GoGaRuCo talking to people about Tracker and demoing the app. Especially cool w...

Next
GoGaRuCo '09 – Sarah Allen is live-blogging
GoGaRuCo '09 – Sarah Allen is live-blogging

Sarah Allen is also live-blogging the conference at www.ultrasaurus.com Thanks Sarah!