[lively music]
>> Man: Live from Santa Clara, in the heart of
Silicon Valley, it's theCube,
covering Cloud Foundry Summit 2017.
Brought to you by the Cloud Foundry Foundation
and Pivotal.
>> Welcome back, I'm Stu Miniman with my cohost,
John Troyer. Happy to welcome back to the program,
actually a former colleague of mine,
Cornelia Davis, Senior Director of Technology at Pivotal.
Cornelia, it's great to see you.
>> Thank you, thank you for having me.
>> All right, so why don't you fill in our audience a little
bit about your role at Pivotal, you've been involved since
before the foundation in early days of everything happening.
>> Yeah, and in fact I have been working with Cloud Foundry
for longer than the Pivotal Company's existed.
As you know, Stu, you and I used to work together
at EMC in the corporate CTO office.
>> Yeah, I remember a company named EMC.
[Laughing]
>> Yep. And I worked in the architecture group
and we did architecture in emerging tech.
And about five years ago, my boss, who you know,
Tom McGuire, said, "You know, this platform as a service
thing, I think is going to be pretty disruptive,
and I want you to start looking at it.
And so naturally we were EMC, VMware was incubating
Cloud Foundry already, so I started playing
with Cloud Foundry. So that was way back in the days
of Cloud Foundry version 1.0. I'm one of those people
who got to raise my hand and say, "Yes, I've been
to every single Cloud Foundry Summit."
[Stu Laughing]
But fast forward then we had the Pivotal spin-off,
and since the Pivotal spin-off, I joined
the Cloud Foundry team proper, and I've been in a role
working the product organization, working with James Waters,
who I know you spoke to earlier today,
and helping our customers kind of get their arms wrapped
around what this...this isn't just the next application
platform. How really, it's radically different,
and how the applications, it enables a completely different
style of application. And so really helping
customers grok the differences about that.
>> Yeah, Cornelia, I want you to help us dig into this
a little bit, because when we look at any of these massive
changes, a lot of times we say, you know, the technology
is the easy part. It's really the change in mindset,
the change in the structure, new skillsets.
What are you seeing, what's different now than it was,
say, three or five years ago, and what are those customer
discussions that you're having?
>> Yeah, and that's a great question, and I will say,
and thanks for the opportunity to say this, is that
the technology isn't always the easy part.
[Stu laughs]
So let me give you an example. So just earlier today
I was on a call where somebody was talking about some
user interviews that they had done with some programmers,
and what they concluded at the end of that was that
programmers really weren't comfortable with the "asynch"
model for this particular API, and that they really wanted
to just deal with the synchronous stuff.
And the answer there is not that we say,
"Oh, okay, we'll let you keep doing synchronous."
The answer is that yes, there's a technology thing here
that's hard, which is starting to think asynchronously and
changing the way that we design our applications.
So the technology's not always easy,
but we have to go there, because in the cloud,
where things are so extraordinarily distributed
in a way, and the cloud is constantly changing
in ways that it never did before, we have to adopt
new technology models. So that's the first thing
I'll say, is that we definitely, the technology parts
are sometimes hard. That said, certainly over the course
of the last four years, as I've worked with those customers,
in the beginning, I spent a lot of time, as you know,
I'm a technologist, so I spent a lot of time
at the whiteboard, and sketching out architectures and
talking about changes in the architecture of the platform
or changes in the architecture of the application, but then
I very quickly found myself talking to customers
about the other things that are going to need to change
around the edges. So if, for example, you want to start
deploying software multiple times a day,
you're going to have to change your processes, because
you can't have the security office have to do a full
audit of every change before it goes into production
if it's going to happen three or four times a day.
And if you do that, then does that imply organizational
changes? So I spend a great deal of my time really talking
about the whole DevOps and the people and process
side of the equation as well. So last week, I was just -
I'm part of the programming committee of the DevOps
Enterprise Summit, and we just held that last week
in London. And there we spent a lot of time talking
about those elements as well.
>> I spoke with somebody who was at that conference,
and they said it was a little bit sobering,
because there are people who have adopted a lot
of these practices, and then there are people who are trying
and then probably people who have not started yet.
>> Cornelia: Yeah.
>> As Coté calls them "the donkeys without the unicorn
horns yet.
>> Cornelia: Ah.
>> But as you go out to the customer base, obviously part
of what Pivotal is doing is really this huge Pivotal Apps
push about showing people the culture. I mean, do you
feel like it's a push or a pull, does the technology come
first, and then the culture, does the CIO yell,
or do the developers say, "We want this"?
>> So we definitely get a little bit of both. I would say
that I have had the great opportunity to work with a great
number of these customers, so Allstate, for example, we've
seen Allstate here at CF Summit year after year, and
Opal spoke about Andy Zitney talking about this three or
four years ago. Well, that was IT saying, "Hey," and
that was more from the operations side saying, "Hey, we're
going to build you a new platform," and then will they
come? Now, they of course had to couple that together with,
"Okay, we're not just going to build the platform, we have
to put things in place to enable people to use it properly.
So there's certainly- and that came a little bit more
from Andy Zitney's vision. So it was a little bit more
from the top, "Hey, we understand there's a better way,
we're going to start making this available to you,
and we'll teach you along the way."
We absolutely see the opposite as well, though.
Where we see the groundswell, which sometimes comes from
a bunch of really smart people starting to play
with the open source things. And saying, "Hey, there's got
to be a better way," or the shadow IT. They're frustrated
with the three-month cycles, and those things.
So it isn't one answer, it's really both.
It comes from both sides.
>> All right. So Cornelia, you're good at understanding
some of those next generation things. One of the terms
that we've been talking about for the last couple of years
is "cloud-native." Could you help us really kind of
tease apart what that means in your customer base,
and the way you approach and explain that?
>> Yeah. So the term "cloud-native" is brilliant
from the perspective of having a term for it
that has really taken ahold. Because I would say that
three years ago, I used to say to people, "Hey, cloud is
not about where you're computing, it's about how you're
computing." But in fact, that's not exactly accurate.
And so, now that cloud-native is a term that's taken hold,
I have modified my statement. And the statement that I like
to make now is that, cloud, in fact, is where you compute.
It could be a public cloud, it could be a private cloud,
but it is more of a location. Cloud-native is the how.
So I like to also characterize the cloud and cloud-native,
really cloud-native applications, as two fundamental things.
One is that cloud-native has reached levels of distribution
that we have not seen before. We've been dealing
with distributed systems and heck, in universities,
there have been courses on distributed systems for 40 years.
But even when I started my career 30 years ago,
I started my career in aerospace doing embedded systems,
and I remember working on a system where we had three
processors. You know, that was as distributed as we got.
And we actually mapped out on a whiteboard, okay, we're
going to run this on this process and parallel with this
on this process, and the point there is it was distributed,
but we knew exactly what we had, and we could count on that
being there. Now, it's reached a completely different, many
many orders of magnitude more, in terms of the number
of distributed components, as we go to microservices
and those types of things. So that's one of the things
that I characterize cloud and cloud-native, is highly
distributed like we've never seen before.
Couple that together with the other thing I just talked
about with the embedded systems, that's very different
from that, is constantly changing. Always changing.
And whether that change is happening because of
some catastrophe or that change is happening because we are
doing an upgrade, a planned upgrade, it's constantly
in flux. And so we have to do things differently for that.
And so that, I think really, is what cloud-native is about,
is the how, and like I said, highly distributed,
constantly changing.
>> All right. And what about the role of data, when
we talk about that? Distributed architectures, storage is
really tough in that kind of environment.
>> Cornelia: Yep.
>> And therefore, how does data play into it?
>> Cornelia: Yeah, so cloud-native apps were really,
as an industry starting, and here at CF Summit, people are
really kind of grokking what that means. Highly distributed,
small, loosely coupled components that we've put together,
we'll talk about that collective in just a moment.
But they're generally stateless and so on. So we understand
cloud-native apps, but cloud-native involves data as well,
as you said, now most of our customers that have,
as you said, some of them are a little bit further along
whether it's DevOps or it's cloud-native architectures,
they're a little further along. And those that are quite
far along, have a lot of microservices, and so you look
at them, and if you look just at the microservices,
you think, "Ah, beautiful. Loosely coupled, independent
teams, and so on," and then you pull back the curtain,
and you realize that those microservices are all tied
to a shared database. There's this monolithic Oracle
database or SQL server, something at the back end,
that they're all tied to. And so in fact, when a team
wants to make a rev on a microservice, they might still
have to go through some of that planning and lockstep
with lots of other teams, because, "Hey, I want to change
something in the data." So the data, remember we just
talked about highly distributed? Well, on the data side,
it's not so highly distributed. Yes, we've got multi data
centers, but we have, again, a predictable number of nodes.
We know what we've got deployed. We have very rigid
architectures and configurations and so on.
So when we start to apply cloud-native to data, we look
at the same goals we had with cloud-native applications,
which is autonomy, so being able to have the different
cloud-native components evolve independently, resilience,
so that we have bulkheads and air gaps between them,
all of those same goals, let's start to apply those
to data.
>> And you feel that that's not happening today yet.
We're earlier in the process yet?
>> It hasn't been happening. That's right. We're far
far far earlier in the process. And so what we want
to start to do is take that monolith that's sitting
behind the curtain and we want to start breaking it apart.
Now, the industry has definitely gotten to the point where
they're starting to tackle this. And that was, I kind of
had an epiphany about a year ago, I was working
with a customer, talking to them about DevOps,
talking about all these cloud-native patterns
and practices, and the punch line was it was the
data team of this organization. So they didn't understand
the solutions, but they were understanding that they had
pain points that were very reminiscent of the pain points
that their colleagues in the application server teams
had had, had been tackling for three or four years.
So the types of technologies that we're starting
to see emerge and the types of patterns we're starting
to see emerge are things like unified logs,
like applying Kafka to that problem of having a
unified log and that be the source of record.
And event-driven systems and those types of things.
Every microservice gets its own database, which, yeah,
we'll get some of that, but that's a kind of purist
and not pragmatic way of looking at things.
Caching plays a pretty big role in that, so caching
in the past has been all about performance,
but now when we start to look at patterns, how can
we use caches to help us create those bulkheads and
those air gaps so we get additional resilience in our
microservices architecture? If we can put caches
and there are companies like Netflix, like Twitter,
who have done that, who have embedded caching deeply
through their entire architecture.
>> Well, do you think these technologies will come
from the database or, well, let's call it the database
projects and vendors themselves, or is that something,
those patterns can get built into a platform, say,
like Cloud Foundry?
>> I think it's going to probably come more from the platform
community, which is not to say that database vendors aren't
thinking about that, but again, they are keeping
the lights on with their existing product, so they have
those quintessential business school constraints that
are holding them back.
>> A quick question on nomenclature. So a few years back
as cloud-native was being coined, you also heard about
12-Factor apps, and that was one particular manifesto,
and certainly the ops folks, I would call it at the time,
said, "Well, wait a minute, that's great for your
front end, but where are you storing your state?"
>> Cornelia: Exactly.
And so I love this conversation about
>> Yep.
cloud-native data. So that is what we're talking about here?
>> That's exactly what we're talking about, is doing that.
And so it allows us, it's interesting, because as soon as
we take a model where we say, "Okay, every microservice
gets its own microdatabase," then of course
everybody in any large enterprise says, "Wait a minute,
what about my data compliance, my data governance,
how do I keep a customer that's stored in this database
over here from diverging from the customer record
that's stored in this other database?" I mean, we've
spent decades talking about the 360 view of customers,
because we've already been somewhat more fragmented
than we wanted, and our knee-jerk reaction over the last
several decades was, let's consolidate everything
into one database. But with that comes slowness. It's the
proverbial large, large ship that's hard to turn and hard
to move. But what's different now is that we're starting
to come up with some different patterns of doing that,
what we call master data management in the past, we're
applying completely different patterns now, where those
individual microservice databases are really just seen
as a materialized view of some source of record,
and that source of record is just a time series of events,
and you can always rebuild. You know, it's very
interesting, because databases have had a log as a
part of their architecture forever. For a very, very
long time. And in fact, the log, arguably, is more important
than any of the database tables that are stored on disk,
because you can always recreate the database tables
from the log. Now take that concept and distribute it.
That's what cloud-native data is all about.
To take what has been a single fabric, and now create
a highly distributed, constantly changing fabric for data.
And figuring out what those patterns are.
>> Cornelia, I want to give you the final word. You've been
to all the Cloud Foundry Summits. Either the customers
or the event itself, what are some of the things
that are kind of new and changing, that people
that aren't at the show should know about?
>> You know, I was walking down the hallway this afternoon,
one thing I'll note that has changed, like I said,
I was walking down the hallway with a colleague
of mine, and he said, "I have 12 people from a
single one of my customers here. 12 people." I spoke
with somebody else who said, "Yep, another customer -
not a vendor, but a customer - sent 30 people here."
So we have- Cloud Foundry Summit in the beginning
was a whole bunch of people who were the hobbyists,
if you will. So I think we've reached that inflection
point where we have the users, not just the hobbyists,
but the true users that are going to leverage the
platform. That's one thing that's changed.
Some of the things- the other interesting thing I think
that is really brilliant is the touch that the
Cloud Foundry Foundation has. So I'll tell you,
I submitted several papers here three years ago,
when it was still the Pivotal Show. I could talk
about whatever I wanted. I don't always get my papers
accepted here now. And that is a good thing. That's a
really good thing, so we have really democratized the
community, so it truly is a community event. I think
that's another thing that's happened, is kind of
the democratization of Cloud Foundry, and I love that.
>> Cornelia Davis, it's a pleasure to catch up with you,
thank you so much for joining us.
And John and I will be back with a couple of customers,
actually, here at the Cloud Foundry Summit.
So stay tuned and thanks for watching theCube.
[lively music]