What’s Pivotal Cloud Foundry have to do with continuous delivery? Fresh off presenting at a recent Jenkins User Conference on that topic, I ask Karun Bakshi to go over his presentation. We discuss how Pivotal Cloud Foundry helps enable continuous delivery and also some of the “deleted scenes” from his talk.
PLAY EPISODE
SHOW NOTES
- Subscribe to the feed, or download the episode directly
- Get the slides from his presentation
- Feedback: podcast@pivotal.io
TRANSCRIPT
Coté:
You were at a continuous delivery conference recently. Which one was that?
Karun:
This was the Jenkins User Conference/Continuous Delivery, a set of 2 conferences with related topics but actually happening in parallel.
Coté:
It’s put on by the CloudBees people, right? Do I have that right? It’s sort of like the conference for them?
Karun:
Yeah. This is their main conferences.
Coté:
Then you ended up speaking at the first one. It was exciting. You were going to be all helpful, help put together the presentation and everything. Then you ended up being extremely helpful by giving it as well.
Karun:
Indeed. It was a learning experience for me, sort of a force and function to get a good grip on what is happening in the space and how we relate to it.
Coté:
Before we get in to it, why don’t you introduce yourself briefly and just, for context, go over what it is you work here in Pivotal Cloud Foundry land?
Karun:
Sure. My name is Karun Bakshi. I’m director of product marketing, working in the product marketing org. I essentially focus, certainly in generic terms, on product marketing in terms of developing position and collateral for Pivotal Cloud Foundry but also specifically we’ve recently been focusing primarily in partners, and CloudBees being one of the premier partners that we’re working with. So in terms of enabling them with our field and certainly developing collateral with them and obviously positioning our joint solution to the market.
Coté:
Basically we have our own terminology for it and everything, but we have an integration with CloudBees so that the end result of their continuous delivery pipeline integrates pretty well whether it’s Pivotal web services, or public PaaSes they’re using, or an on-premise one, but we work technologically very closely with them so that things flow well. Would you characterize what we do with them in any additional ways?
Karun:
No, I think that essentially captures it. In some sense, I could certainly dive into the features, but essentially our hope is that our joint customers will find that when they do continue this integration with CloudBees Jenkins that they can deploy those apps that have been continuously integrated onto Cloud Foundry.
Now, there are certainly some additional features where CloudBees itself runs on Pivotal Cloud Foundry, and integration specifics around how the masters and slaves are configured. But, the high-level value proposition is as you mentioned it, which is a destination for the continuous integration of apps using CloudBees Jenkins.
Coté:
That hits on one of the things that’s always a little intellectually delightful for me. Figuring out how we talk about it is that, I often think, in talking with our customers, that a lot of them, the whole that they want to buy is basically continuous delivery. This isn’t the totality of what Pivotal Cloud Foundry people talk about, but one of the things they are very much interested in is, “I want to have all those benefits of continuous delivery. Like delivering things quickly, delivering my applications faster, and everything that comes from that.”
This is the delightful part, we don’t necessarily actually sell a continuous integration or a continuous build product, but we are very much so involved and care about that conversation. It seems like … No spoilers here or anything, but I helped you work on this presentation a little bit. One of the things that was fun about this presentation is it allows us to anchor down where it is we fit in that continuous delivery world and why we care so much about it.
Rather than me soliloquizing, if that’s a word, on it, how did you tackle this issue of, “Hey, I’m at a continuous delivery conference and we don’t really sell a continuous delivery tool as you would think of it normally.”
Karun:
That’s a great question and I think the way I would characterize it in more colorful terms is that we’re sort of like long lost cousins. We essentially have the same mission. We’re related, but we don’t do the same thing. I think if you were to look at, at a very high high level, both companies and both ecosystems, if you will, around the open source technology are really oriented around helping customers develop and deliver software quickly. So, the devil’s in the details. On the one hand, you can think of development and the agility around building products quickly, but there’s a piece of it that gets lost because we’re so early on in that agility mindset. That piece is the part that comes after you’ve developed and deployed your software. All the operational issues that come up, whether it’s availability or scalability or security, etc. that really define how well you have delivered the product.
We’re living in the age where software is delivered as a service. So, it’s not just about developing software, but also deploying it and operating it at scale and at a level of quality that customers can enjoy.
Coté:
I think we’re going to put this presentation up somewhere so people can entertain themselves by flipping through it, but when you were delivering this message, sort of jumping to the end of it a little bit, what was the reception that you received from that? Did you have people come up to you afterwards and talk about the way they’re thinking about all the operational concerns, what we would call day-two concerns, as part of their whole CD process? How were people processing this idea that you need a place to deliver this stuff?
Karun:
It’s great that you mentioned day-two. Maybe I’ll just take a moment to describe what we mean by day-two and then dive into the answer.
All of us here at Pivotal, sort of see it the same way and we agree on it. We see day zero, if you will, as the day you actually start to build software. Day one is the day that you start to test and integrate it and get the software ready for deployment. Day two is really when we consider the product to be in production, and all of the issues that come up at day two, as I was mentioning earlier around scaling your application or securing it. Those are concerns that we deal with primarily with Cloud Foundry.
In terms of the response I got from a lot of folks was that it was an eye opener for them because they’d been so consumed by developing and getting their product ready for delivery that they never had a chance to really think about all the things that they will need to take care of when they do indeed deliver the software. Now that they’re delivering the software as a service, they are the ones who are actually operating it as well. They haven’t really answered the questions around how they will handle security, and availability, and scalability for their product or service.
Coté:
It seems like the usual iceberg metaphor, right? You just wanted to chip off a few pieces of ice to make a nice chilled cocktail and now you’re dealing with all the stuff underneath the water line.
Karun:
Indeed, indeed, and the silver lining, or the hope that we want to leave people with is that there are folks who’ve thought about it. In fact, they’re a significant ecosystem of well-known industry leaders that have converged on this Cloud Foundry space and they do feel that this is the right way to tackle that problem, and to do it in a deliberate and mindful fashion. So, I think the outcome from a lot of the listeners really was, “Wow, this is great. I never knew this was available and I need to go learn about it because I can see that this is coming down the road for me to handle.”
Coté:
So, you went through the operations management and security and things like that, but what are some of these day-two things in the context of continuous delivery? You ease into it in the talk, but you get to … I think you did a nice job of summarizing what’s usually a random collection of stuff into a concise set of slides. It’d be nice to hear how taking that big pile of all these operations concerns, we’ll call them, how you consolidated them down into, here’s some things you should worry about. Or put another way, here’s some things you’ll need help with when you’re managing your applications, that you need to start taking to account with when you’re thinking about the full life cycle of your application.
Karun:
I can answer that question in a couple of different ways. I think one way to think about it, as I mentioned earlier, is the operational concerns that people need to think about. How will we make sure that when somebody tweets something, then we get a significant workload coming, that we can adapt to that workload and scale as necessary? Or we can make sure that apps come back up when they’re down. Or we can secure portions of the application or the service, but I think another way, interestingly, to think about this is, if we were to solve this problem, how would we go about doing it?
The way I positioned it is, if today we knew what we wanted to build, how would we design a platform that would help us build that product in the future?
Coté:
Right, it’s like instead of being reactive to your operational needs, proactively craft what you need.
Karun:
Indeed.
Coté:
Or do your best.
Karun:
That’s right, that’s right. So, I put out what I perceive to be desirable properties that such a platform should support. Among those, for example were the following, one of the things that we wanted to make sure that customers agreed on was that we live in a cloud force world. Most of the apps that will be developed will deployed to the cloud. Most of them will need to be at scale in a certain way. So, they’re are certain practices around software development that are already out there, namely Microservices and Twelve-Factor app. So, you want to make sure that the product you develop understands these architectural philosophies and can support them, and has primitives that can map into those major tenants of these philosophies.
Another thing that might be of interest is that we live in a multi-lingual world. There’s no longer one language to rule them all. There’s PHP, there’s Java, there’s Ruby, there’s Python, and who knows many more to come. You really want to have an approach to dealing with applications that is technology agnostic, that supports all of them in a first-class manner. So that was another major tenant.
Another pillar of this philosophy was around supporting multiple clouds. It is not necessarily the case that you will host everything on Amazon or that you’ll host everything on-premise, or that you’ll host everything on Azure. You might want to do a little bit of each, and maybe who knows what other clouds yet to come. You want to be able to operate your product and your service in a way that does not necessarily have to deal with a lot of the migration friction across platforms and destinations.
Finally, I think one of the things that you want to have built into your platform is this notion that both developers and operations folks can use the same set of tools and processes because it really helps develop the DevOps culture and minimizes friction as a product moves through the pipeline to delivery.
These are some of the thoughts that we put across in that talk in terms of how people should think about what kind of framework they should seek out when they’re trying to deploy their applications for continuous delivery.
Coté:
I think that’s interesting framing. I have this somewhat odd, convenient history for stuff like this, where I used to work on systems management software. I would see process embodied in code. Here’s the way, in early 2000s, we as an IT department want to run our data center. That trickles down directly, if you trace it well enough, to how you write code for the software that helps run all of that. It is an interesting point of, if you’re in a continuous delivery, agile DevOps, all this cultural process, where we’re talking about how we want the organization to run and things like that, there’s a lot of, to use some fancy nerd-talk, compedence mismatches that happen. Where the process expects to operate this way and the technology we’re relying on doesn’t operate that way.
So I think it is … Certainly us at Pivotal want this creeping to turn into an accelerated mad-dash to realization, but there’s this creeping realizing that the way a lot of operation stuff operates has to be mapped to the way you want your process to operate as well. It’s good to make sure that the platforms you have map well between those two things so you don’t have those mismatches.
Karun:
Exactly.
Coté:
There’s one slide in here that I think that speaks directly to this, making your organizational context fit to everything. Does that encapsulate the whole notion of making sure your platform in production maps to the way you want to run your process?
Karun:
I think that’s the element that we’re trying to get across there really is around realizing that any platform that you deploy is going to work across organizational boundaries. There’s going to be folks … In a large organization it’s going to be different. For example, it might be different departments that might have different users, who have different resource requirements, who have different security requirements, and you want this platform to essentially be in some sense, and operational lingua-franca, in the sense that people who work on it in one department can really translate their skills easily across departments, the same framework, the same set of rules, the same set of tools, and same set of processes are supported and enforced because it helps create this repeatability that makes it easy to be agile. Makes it easy to be able to deploy quickly.
I think the main point there that I really wanted to get across is this notion of having a platform that is standard in the things that are common and easy, and yet flexible enough to handle the idiosyncrasies of different contexts. A great example for this would be you certainly want to support 4 or 5 languages out of the box, but you want to have a framework in place that you can support any future language that gets developed with the same elegance of the framework. That the framework is elegant enough and robust enough to extend to support new technologies, if you will.
Coté:
One thing, when we were working on this, you had one slide that you cut out from the final version, which had this great phrase in it, “the agility frontier”. I’m always a sucker for a weirdly delightful phrase like that. If I remember, the point you were making is around the expected time for delivery cycles, getting something into production has been decreasing over time, starting back with mainframes and leading all the way up to our cloud native era. Then there was this drooping slope on it, which looked very intriguing. I’m always bad at knowing the right way to read charts, so I just read in a lot of fun stuff into it.
Apart from the way it was illustrated or visualized, what was this … I like what you’re trying to develop there, this idea of an agility frontier and how’s it’s moving. What was that concept? Give us … This is like the director’s cut here.
Karun:
This was an attempt to really juxtapose the trends that have happened in the computing industry with the processes improvements that have happened over time, and marrying it to what has happened in the business landscape. When I talked about the agility frontier, I was really looking at … Businesses set the tone in terms of how fast they expect IT to deliver. That time period has been compressed over the last fifty years, if you will? It’s gotten smaller and smaller. The reason it’s gotten smaller is there’s been lots of improvement in lots of different aspects of delivery of software. I’ve broken it up into two high level concepts. There’s an development aspect of it which really relies on processing tools, like better compilers, better IDEs, maybe pair programming, for example.
Then there’s the aspect around operations which is process and platform. Like, what kinds of things can your platform do for you that automate things for you so you spend less time worrying about delivering the service? When I did this, and I put this on a slide, the realization that came to me was, “Look, we’ve had compression happen in both the development aspects as well as the operational aspects of it. The real question, when you think about it … We’ve had mainframes as a platform of deployment. We’ve had PC, then we had the web. Then we had virtualization. Now, the next frontier for us is cloud native. Can we hit the speed of delivery? Can we hit the agility that business requires of us simply by making improvements in the development aspect of it? Or, are there going to be improvements required in the platform itself?
So, what I left there was a gap. Now that we’ve improved the process for development, what do we need to improve in the platform, and can we really hit that frontier that’s expected of us without making improvements in the platform? It really speaks to the fact that Cloud Foundry can provide many of those benefits for the platform out of the box.
Coté:
That’s interesting. I didn’t even think of that when I was looking at it and imagining the story in my head. I didn’t think of that angle. Which is to say, there’s a little bit of a chicken and egg problem here, right? Does a faster moving business need faster moving IT, or because you have faster moving IT does that mean business is moved faster? Eventually, you lose where the cause was, but it’s interesting to approach it from the angle of … rather than a bottoms up approach based on the technology, here’s what technology is capable of. Therefore, here’s what business can do.
It’s interesting to approach it from an angle of, as a business, I would like to move X fast. I want to do release every week and have that actually run. I want to have all those day-two problems. Then to ask the question, is it possible? We know how fast development can run, and how fast that stuff works, but if we look at how fast operations can run, and the tools that you need to run at this required speed of putting things out weekly, how much more improvement needs to be done in operations and also in development to match this external goal that business is putting on them?
That is a interesting way of framing it, because it drives … It makes the egg, I guess, the business rather than it being what the technology is capable of.
Karun:
Yeah, I think you’re absolutely right. In some sense it’s a chicken and egg problem. In fact, it’s …Probably, I would characterize it as a symbiotic relationship, where both of them egg each other on. The business certainly eggs IT on to improve. IT then improves and then creates a new opportunity for businesses to push the agility frontier, but I think a lot of the recent trend around this you could blame on this concept of unicorns. These companies that sort of come out of nowhere and can deliver at a pace and quality that is simply unheard of. They are really the ones that set the competitive landscape. When businesses see that that is possible, even though those are one-off architectural decisions that a very smart bunch of people have done, for the rest of us it begs to question: If they can do it, why can’t we? And if we were to do it in a way that’s applicable across a broad set of scenarios, what would it look like?
Coté:
That way of looking at it hits upon another thing that’s always fun, at least in DevOps world, which is … I don’t know if it’s a rediscovery, but a discovery of end-to-end value stream mapping in nerd land. Which is to say, you have this process that’s going to fulfill this goal. You should figure out everything needed to fulfill that goal in that processes, because chances are you’re focused on only one part of that. If you focus too much on what they’ll call local optimizations, you’re optimizing one part of a four step process, when you really need to look at all of the other steps in it. Which is to say, if you’re to look at this agility frontier chart, that’s off in a graveyard somewhere, it sort of adds up all of the development things. Development can operate this fast, but also, make sure you’re aware of all the operational issues and how fast operations can work.
Just like in the development side you’re continually trying to figure out how can we optimize the development cycle and do all of our life cycle stuff to optimize it as well? You also have to start optimizing the operational side and make sure that itself doesn’t become one of these things off the chart that ends up weighing down your overall process. As you definitely glided into, you get this nice symbiotic thing where you’re egging each other on rather than worrying about if the egg comes before the foul.
Karun:
Indeed, I think that really captures it.
Speaker 1:
Well, wonderful then. To that end, if people are interested in following your stuff, are you off there in the twitters? Where do you hangout at online for people to mess around with?
Karun:
Certainly on the Pivotal blog is one destination. I haven’t made my presence known on Twitter yet, but perhaps that’s one of the next frontiers for me myself. I’d love to engage folks in conversation on this topic and many others related to Pivotal Cloud Foundry. I hope to see you there soon, but until then, you can find me at kbakshi@Pivotal.io, so it’s k-b-a-k-s-h-i @ Pivotal.io. So I look forward to our conversation.
Coté:
Yeah, that sounds great. Well thanks for going over this with us and as always this is the Pivotal Conversations Podcast. If you go to Pivotal.io/podcast, maybe there’s an S in there. I keep meaning to look this up, but it’s pretty easy to find. We’ve actually split the channels out now so that you can listen to the Pivotal Perspective one that has Simon going over various aspects of the Pivotal portfolio. Or, you can just listen in to the Pivotal Conversations one that I do, sort of the free ranging, to use another chicken metaphor, the sort of free ranging discussion that we have of what’s going on here. As always, you can also email us at podcast@Pivotal.io, if you want to give us some feedback or suggest things, or whatever you might have. We’ll see everyone next time.
About the Author
