Sure. Absolutely. Thanks for having me, Chris. So at Pivotal, I'm working on Andrew Clay Shafer's tech advocacy team for Cloud Foundry. I'm mostly focused on open source Cloud Foundry. The community around it are getting people talking, possibly me, possibly other people on the team or just general community members, users, talking about Cloud Foundry at meetups, helping people see what they can do with Cloud Foundry. I think a lot of people -- the hype cycle is such that a lot of people hear words like Docker and they think that they need to docker all of the Dockers.
Well, I definitely have dockered a great deal of the Dockers, taking, for example, those images and running them on the Cloud Foundry platform is something that people maybe haven’t even considered or don’t realize they can do. So a co-worker, Casey West, and I who's also on the tech advocacy team are actually going to be doing a little bit of a meetup tour where we're speaking at a meetup in Minneapolis where I live, December 1st, about running Docker images on Cloud Foundry and orchestrating workloads with Lattice which is another Pivotal-developed open source tool. Then we're taking that same meetup on the road to New York City, December 15th. We're going to be in D.C. a couple of days later doing a workshop and may do some meetup stuff there as well.
Getting out there in the community and talking to people about this stuff and then also hearing from them like what they're trying to do, what sort of problems they're trying to solve is what I have been into, along with the typical working on blog posts, doing a bunch of podcasting. I actually co-host a podcast Arrested DevOps and I've had a few people on talking about this and that. We just had some folks talking. Matt Curry from Allstate which does use Cloud Foundry and then Rob Cummings from Nordstrom. Matt Curry also used to run scaling stuff at PayPal for eight years. We just had a “'Tis the Season to be Scaling” episode where we talked about scaling for the holidays. Got to get those seasonal podcast episodes when you can. But then also we have been planning to get Andrew Clay Shafer from Pivotal of course and Kelsey Hightower now with Google on to talk about structured versus unstructured platforms cage match on Arrested DevOps probably in the next month or so. We're scheduling that one.
There's a lot of awareness stuff like that and it's kind of fun that I've been working on.
Chris' full question: Kelsey is obviously now really behind Kubernetes and Kubernetes has become a bit of a huge phenomenon and people are talking about running their Docker containers in that. You're obviously advocating for Cloud Foundry and Cloud Foundry has kind of moved from being opinionated about languages and frameworks to allowing you to run anything you like because you can run your Docker containers in there. But obviously, it's opinionated about operations and how you run your platform. Where do you see the differentiators between a Kubernetes style approach and a Cloud Foundry style approach? Which sort of communities do you think those appeal to?
Sure. Absolutely. So I think Kelsey put it best when he said on Twitter that Kubernetes is not a platform; it's a framework that you can use as a component to build things. So for people who would like to build things, if they would like to upend the entire Lego tub and start assembling components, Kubernetes is one of those components that they can start building things with. Because Cloud Foundry comes with a lot more in a way of opinionated, structured, complete platform, people who would like to have a more appcentric view of the universe, they have their apps, they would like to run them, they would like to scale them, they do not want to spend all of their time, all of their innovation tokens on their infrastructure, on their platform, will tend to gravitate toward something like Cloud Foundry where building the platform is not the point. Building the apps that you want to run on the platform is the point.
I think that's one touch point of differentiation that it comes down to intent. What do you intend to do? What do you want to spend your energies and time on? So while building stuff is fun, I mean I've spent a lot of time building stuff. Building stuff is definitely fun. It's not what every single org wants to have, every single operational team work on. So for people who are more appcentric, Cloud Foundry is a pretty good choice.
4. What is the jumping off point?
So if you go to CloudFoundry.org, there is a “Getting started”. We had actually a Cloud Foundry open source, the foundation ran a documentation sprint about a month ago now. And one of the things we discovered was that it feels more difficult to get started. So when you look at something like, say, Docker or Cube Control you get it and go, assuming you've set up your GC and everything else. So Shafer likes to put it as the mean time to dopamine is a lot smaller or something like that.
Cloud Foundry feels really big and one of the ways we can make it more accessible to people is Casey West and I walked through and figured out that using the BOSH Lite and using Cloud Foundry locally, like you don’t have to have a bunch of hardware or you don’t have to have “How much of my Amazon bill this month but I like to spend playing with this”. It is possible to actually run it locally on your laptop. Cautionary, it does take about six and a half gig of available ram. So when I tried this on my MacBook Air with 8 GB RAM like that was not a good show. I couldn’t run Chrome at the same time. But on my MacBook Pro with 16 GB, it works fine.
You can set it up and play with the whole thing locally that way. You don’t necessarily need to. That's more of a if you want to actually play with BOSH look at the YAML, put a manifest, that sort of thing, that's one way to approach it. It's also possible to try, if you want to try more from the developer point of view, you can try on run.pivotal.io. There's a 60-day free trial. No credit card required. Just try the 'cf push' experience on the hosted Pivotal web services that is run and operated by Pivotal.
And then another option, if you want to see some of the touch points that make Cloud Foundry kind of cool without again trying the entire thing, Lattice is a good entry point. So people can try orchestrating workloads with that. So that's on lattice.cf.
Chris' full question: You've touched upon documentation and Kelsey actually did a tweet that I loved the other day that I think generally in our industry we give people far too much credit for cutting source in communities and maybe not enough helpful samples and examples and tutorials and things like that. If I reflect back to the kind of app server wars, it felt to me like WebLogic won because it had better samples and examples. If you look at any J2EE app, you'll find a WebLogic sample or example at the middle of it, even great big banking apps. What are you trying to do in the Cloud Foundry space to bring on the samples and examples and tutorials and to make life easy for people?
Absolutely. I think again because we take a very appcentric view of the universe where a lot of people come into this is wanting to try writing and pushing apps to a platform, not everybody, some people but not everybody wants to try running a platform. So if you look at start.spring.io, it's very, very simple to -- it's all dropdowns and autofills and getting started writing a spring cloud project is incredibly easy. I know nothing about Java. I was walking through at the workshop prep stuff with my co-worker Josh Langham -- I'm going to be giving a workshop with here at QCon tomorrow -- and I was blown away by how easy that is.
There's documentation and there's copy/paste code from the internet which we've all heard the horror stories about what could be in that thing that you're copying and pasting. And then there's a tool that actually holds your hand through trying it which is what you get at start.spring.io. I think that that's a really good approach for people who want to try building a spring boot project like that. And then I take the Cloud Foundry CLI signup for Pivotal web services account and just do CF Push. That's kind of our happy path for taking people through and trying it pretty easily. That's what we're going to be doing in the workshop tomorrow.
BOSH is -- one way to put it is it's kind of a narrow AI. BOSH is your infrastructure automation layer. Imagine if you saw the blog post a while ago that says what version is your infrastructure? One of the things we were doing at DramaFever is having version deployable artifacts of Docker images so we knew what version of our code was out there. Knowing what version of your infrastructure is out there is a little bit of a trickier problem. BOSH solves that by packaging up everything for your infrastructure in a BOSH release.
So you basically have YAML that says, this is how I define my infrastructure at this given moment. Control that through YAML and through having BOSH do things like spin up VMs for you, attach storage, anything that you would do. If you're running Cloud Foundry on top of your public or private cloud whether it be OpenStack, Vsphere, AWS, Azure, wherever you want to run it, all of those hooks into the API for the infrastructure. You don’t necessarily want to be doing a 'run instance' here if somewhere else in your infrastructure you want to be doing something else. BOSH handles all of that, like all the automation of talking to your infrastructure.
'cf push' on the other hand is the thing that the developers would use to give themselves a very Heroku-like experience because and it's one of those things where as an ops person we cringe because relying on cwd, the current working directory, is terrifying. But from a development point of view, if you're in a directory and you say CF Push with no arguments, you're pushing everything in this directory and recursively on down as your application to the platform. At that point, if you have no arguments, the platform is going to take a build pack and try to guess. If you haven’t specified a build pack, it will look at your code and say, "Hmm, this looks like PHP. All right, you're writing PHP. Everything is probably fine," or whatever and package it up that way.
You also can say CF Push and then give a Docker image like say something on Docker Hub and then at that point, it's going to take the thing from Docker Hub and push it to whatever you've set as your -- you've done a 'cf login' in probably to Pivotal web services or wherever it is that you're running your Cloud Foundry instance. And then if you say 'cf push' and then link to the Docker image, you push and start -- unless you say no start -- you push and start running the image for whatever presumably webpage and application you've decided to start. So it's that simple.
I think that there's a lot going on in the ecosystem. There's a lot going on in the space. Certainly, Docker and many other companies in the space are attempting to set forth their ideas for how one could run things. What we're looking at at Cloud Foundry is that there's a lot of pieces that you need to cover those Day 2 operational concerns. Again, I've spent a bunch of time building infrastructure that does things like scaling, that was all very AWS specific. It wouldn’t be easily translatable to someplace else but things like scaling, blue-green deployments, exactly how you run the deploys, the automated health checks and remediation for failure.
All of those pieces the entire control plane, all of those pieces are something that everyone is moving in one direction or another to try to have answers for that and our answer for it in Cloud Foundry world is that this has been around since 2011. There's a lot of production workloads actually running on it. So with all respect to all of the exciting innovative things people are doing in this space, we're pretty excited about the fact that this actually works in actual customers who pay us money and also make money on the platforms that they're running with this are having success with it in production. Because I think those production concerns are -- there is -- you ever hear the one where people call that staging infrastructure theory as in "This works in theory."
There's a lot of stuff that works in theory and our stuff actually works in production which is pretty cool.
Chris: So if Cloud Foundry is giving people the ability to have their own Herokus and not necessarily even mini-Herokus, if they're operating at scale.
They don’t have to be mini. That's for sure.
It is certainly possible and something that people actually do to attach storage in the platform. Like I mean BOSH with attach storage that will handle that. The pattern that we see a lot of people do and the pattern that's emerging which is pretty popular is to talk to either through a service broker or just like natively in the platform to something like RDS or any other database. I mean of course Pivotal has a number of open source databases ourselves, but any of the databases ourselves. But any of the databases people want to talk to like the people are usually not keeping state in their containers, just because -- that's kind of one of those sticky situations that you don’t necessarily want to get into. It makes a lot of sense to have your state not be something that's scaling up and down at all times. So people are often using externally managed state through service brokers through the platform which talks directly to whatever database you want to connect or whatever -- again, whatever session store -- I mean Redis, whatever it is that you want to actually store stuff in.
It really depends because a huge amount -- again from the Pivotal point of view, for the people who are our customers, a huge amount of them are writing Java. They want to be writing Java and this isn’t like super crusty scary Java where you're like, "It's 20 years old. Why?" This is modern exciting Java that they're writing. The fast-moving Java that you see out of things like the Netflix open source projects. So there's a lot of that. There's a lot of Java. There's a lot of .NET. It might surprising but while people may be writing .NET, they might not want to be pushing just right to Azure and just hoping. They want a more opinionated platform that actually handles their scaling, metrics, et cetera. What's going on with the log firehose? That sort of thing, those concerns.
A bunch of our New York team actually didn’t make it to Cloud Foundry Summit in Berlin because they were down visiting Humana who put out some kind of tweet or blog post or something about helping them get all of their .NET workloads that they were moving into the platform, just taking them through the process of moving a bunch of stuff. So yes, it's kind of interesting. We see a huge amount of growth in the spring projects specifically. Well, the people certainly can and do write code in a multitude of languages and push it into the platform. Like you pointed out, we're pretty language agnostic at this point. That's where we're actually seeing a lot of people writing stuff.
In terms of the opinionated, we're opinionated about making sure that you can scale and operate, deploy or remediate problems, et cetera with the platform, we're not opinionated about what language you want to write in. I mean if you want write everything in Haskell or Erlang or whatever, that's not the reality of what most large enterprises want to write in. So that's where we see a lot of the cloud native Java.
Apparently, what we're seeing is that a lot of people may be using Windows in their local development environments, but that doesn’t necessarily mean that that translates to them planning to run the stuff on Windows in the cloud. It's more that they don’t -- and this is like an haiku of “Here's my app. Please run it in the cloud for me. I don’t care where.” Like there's a lot of people who don’t particularly want to care or think about the details of how their app will run. They want to have that contract, that promise from the platform that their app will run. So you brought up 12-factor app and one thing that Shafer has been talking about that is resonating with me is this idea of 12-factor ops, that if 12-factor app has a lot of expectations, 12-factor ops needs to fulfill them. So that means, say, 12-factor app says, well, we will log in this way. Well, great. There's this implied promise that the logs will go somewhere and probably be viewable. It's like carrying out that handshake is part of what the platform does for people.
I think that I have to be careful of promising people that there is any sort of magic 12-factor/container/microservices/DevOps/ insert your buzzword here. There isn’t something magic you can buy or download because, for example, if you want the health checks and if you want the scaling in the Cloud Foundry platform to work correctly, then your developers, there's this implicit promise that your developers will write applications that they will not return a lie of 200 okay when things are not okay.
So there's this human component that I think we often don’t talk about but maybe need to where we are trusting one another. We're trusting that we're going to be delivering apps that are behaving like it says on the tin in order for the platform to actually work. So I can't promise that the -- I said in my talk yesterday, containers will not fix your broken culture. The platform is not magic. It will not fix the fact that your Devs and Ops don’t talk to each other and disagree fundamentally about everything. People do have to put the work in to actually use the tools instead of having the tools just magically fix everything for them.
I mean that said, I think that the tools enable people to do the right thing. This is kind of that point that comes out of Netflix's whole simple patterns automated by tooling. It's like good automation goes a long way towards doing the right thing, the easy thing.
If you start using Cloud Foundry, built into Cloud Foundry is the Loggregator, what the Loggregator does is it's basically a log's firehose that you can point wherever you want. So say you have a preferred SaaS logging, monitoring metrics platform that you want to point it at, cool, sure. We have integrations with a number of them. We do a bunch of stuff with ELK. If you would prefer to use an open source solution in the commercial version of Cloud Foundry there is an ELK, ElasticSearch/Logstash/Kibana tile. It's like one click. Okay. You have the okay. For anyone who's actually set ELK up, that's a bloody revelation. It's like you don’t spend a lot of time agonizing over your ElasticSearch indexes or installing Curator to do the cleanup. All of those things that you end up having to do with running the stuff yourself in the bespoke artisanal hand whittled Portlandia sort of way; been there, done that, got paged by that at 3:00 in the morning. It's kind of freaking exciting not to think about that.
Sure. Absolutely. The open source Cloud Foundry gives people the core. It gives people what they need to get started. The great thing is because Cloud Foundry, we have a foundation and we have a number of other commercial vendors who are building on top of Cloud Foundry. Pivotal Cloud Foundry's commercial offering specifically offers ops manager which if you prefer not to write really long YAML files, ops manager provides a GUI, a very opinionated yet you can fiddle the dials however you like way to configure and view everything. It also provides all of these built-in integrations.
So we have a number of partners that we're working on have integrations for whatever, like you mentioned, state like a plethora of different databases, again all the SaaS providers, CI solutions, the kinds of things people would like to plug into their platform we've configured and we'll manage all of these integrations. It's super simple. Just click to add them. That's the biggest -- aside from the commercial support and then there is -- you have a number of choices whether -- there's an entire spectrum from the completely hosted Pivotal web services. We run it on AWS for you and you just treat it as a completely SaaS sort of thing. We have that all the way to PCF, Pivotal Cloud Foundry that we will install for you and run. Perhaps we will just license it if you would like to run it.
For people who have -- a lot of our corporate customers are in their own data centers. They have OpenStack, Vsphere, whatever. They're casting an eye on the public cloud and they really want to be in there and that transition is kind of a pain sometimes. So we facilitate that transition like help them set it up on AWS and then help them so that it's a completely transparent transition for their developers who just keep on CF pushing and don’t even have to think about where the platform is targeted.
14. So you're leveling that playing field?
Infrastructure is increasingly commoditized. This just makes it so much easier for people who again they want to focus, many corporations and organizations of all sorts, want to focus on where the value add for their business is and they don’t necessarily -- again, some people get a lot of value from building innovative infrastructure. A lot of people don’t. So they want to focus their efforts on where they're actually going to build value and differentiate their organization. And we help people do that.
Chris: Perfect. Well, thank you very much for stopping by.
Absolutely. Thank you.