Please welcome Joshua McKenty, Head of Global
Ecosystem Engineering at Pivotal.>>[APPLAUSE]>>Thank you, really happy to
be here. I put this talk together as a bit of a mix
tape which Belle and Sebastian have helped to organize the All Tomorrow’s Parties events.
And I was a child in the 80s and I loved this feeling that you get where you listen to all
these different songs on a mix tape and you don’t really understand how they’re related
to each other but you get to the end and you kind of know what the story was about.
And sometimes I feel that way about Cloud Foundry, like it is the mix tape of cloud
native software. And certainly our journey at Pivotal, working
with large enterprises has been a bit like that.
They know when they start the tape they’re going on some kind of ride, and they’re not
really sure where they’re going to get to, but they kind of commit themselves to that
process. So I’m really excited to be at Open Dev today,
and really I want to talk about something that happened recently that was pretty big
moment in the cloud native community really which is that Microsoft joined the Cloud Foundry
Foundation. And we’ve been involved obviously with Cloud
Foundry since the very beginning at Pivotal, since we spin out of the End-ware where it
was born. But Microsoft getting involved really is taking
our relationship with them and our partnership with them to the next level.
So I thought I would cover sort of how we think about openness at Pivotal.
And how we think about openness in our partnership with Microsoft and the idea of open with security,
right? So open is often conflated with just well
anyone can do anything that want or we’re all sort of socialists, and I’m Canadian,
and this can go wrong in all these different ways.
But what does open mean when it’s a positive thing, without getting overly permissive?
So in software, and particularly in IT, I think we’ve opened in terms of sort of three
axes, right? What language am I allowed to use?
As an enterprise developer, historically we were told hey, you shall write in Java, or
you shall write in .NET, or you shall write in COBOL, and that’s all you get.
And only having COBOL at your disposal is really limiting.
And so a lot of what’s happened in the last ten years, but really particularly in the
last five has been around this move towards polyglot of the openness of languages.
We can write now in Python or in Node.js or in GO or in a mix of Java and .NET and have
those applications not really care, have the application architecture elevated above the
language choice, that’s really important. The second idea of openness is really where
is my app running? I wanna be able to run it on my laptop when
I’m working on it. I wanna be able to run it in a dev environment
dedicated maybe to my team or my line of business. And I wanna be able to run it in the public
cloud of my choice, as well as in production data centers possibly all over the world.
So having freedom to run my application in different locations regardless of where I
built it is really an important separation. This last sense of openness is, what services
can I use? And again, traditional at a large enterprise,
we’re pinned to maybe a single database or a single queue system.
Thou shalt use the rack of databases in the basement.
Thou shalt use the mainframe and the services that go along with it.
And we’ve really grown beyond that now, to say hey I want flavors of SQL and flavors
of NoSQL. I want Q Services, I want In-memory, Cache.
And maybe it’s Redis today and GemFire tomorrow and Mongo.
And Cassandra and what ever service I want. I want to able bring my application to those
services without thinking about, hey if I am running it in this place, what services
do I have available to me? Decouple those things.
So, there’s a challenge with this much openness, which is you can get lost in the details.
You can say, well I sort of thought that SQL would work this way and it did, except that
I went to this other database and those SQL functions didn’t work.
Or I was using this queue and then I switched and I was using the same technology.
Why is it when I was using Redis on my laptop it worked and then when I started using Redis
off in the cloud it failed? All right, so this principle if you want to
be formal about it is called the principle of least astonishment.
Things should work for people the way that the people that use them expect them to work.
And I’m gonna come back to principle as we go, all right?
Developers are not a single class of human, right?
This is not a uniformed thing like saying fish, all fish are similar.
Well there are big fish and small fish, there are vegetarian fish, there are carnivorous
fish, there are fish that don’t even have fins.
Developers are a bit like fish. So if you take that to it’s logical extreme
there are developers that love operating systems, right?
Typically they write operating systems. Maybe they work for Microsoft or they work
for some Linux vendor. But large organizations don’t want to pay
developers to work on things they find fun. They wanna pay developers to work on things
that provide value, which is typically closer to the customer.
We want to get as close to the pain that our users are experiencing as possible.
And we do that by embracing opinions. So rather than building using every possible
operating system or every possible cloud we’re just gonna not care.
And we’re gonna say we embrace certain services. There are cases where we wanna be opinionated
and we care deeply and there are cases where we wanna be agnostic and care not at all.
And so it’s important to give developers a set of choices, and not say everyone has to
write it at the same level of abstraction. You all have to write serverless from now
on. So at Pivotal we embrace what we call the
4 Abstractions. We think about writing kind of serverless
code, where you’re just caring about your function and you don’t even care about the
rest of the application. Or maybe a layer down from that we’re writing
applications, and we care about sets of services or microservices that talk to each other but
not where they run and the specific topology. Now we do see use cases where even developers
wanna be at one level more detail, and they wanna define the set of containers and where
they’ll be placed in relationship to each other.
And we expose that as well. And then even one step further, where you
wanna deal with Virtual Machines, key infrastructure, kind of define your own services that have
persistent storage and complex life cycle for state.
And so all four of those abstractions are really important but, as I said before, developers
are like fish. So if we wanna keep our developers happy and
they’re not all unique, and they’re working towards different abstractions.
We have to expose them different tools and different technologies.
Let’s start with Spring. We have a long history of working in the Java
community, and we came up with this technology a few years ago called Spring Boot, which
has now become wildly successful. I think the estimate is 85% of all new Java
projects are started in Spring Boot. And it gives a very specific framework for
building applications in Java. It’s a set of opinions if you like.
If you’re a Java developer and you don’t wanna think about the details of well, how do I
wanna concatenate two strings? Great, Springs got a way to do that.
It’s got a way to deal with Having different services in your application, talk to each
other. It’s got a way to deal with scaling out and
balancing and service discovery and it makes a set of opinionated choices.
You don’t have to use Spring, but it’s one of the ways we address that and the sense
of openness is, if you want this language, here’s a framework.
We’re not working together with other partners in the SQL system including Microsoft to make
the same approach as work well with .NET. So you can have your best of class .NET applications
also be open source, also be taking advantage of micro services and still run them anywhere.
Let’s talk about opinions one layer deeper, let’s talk about that abstraction of infrastructure.
So Bosh has always been a part of Pivotal’s technology stack, we think of it as sort of
the secret sauce behind Cloud Foundry. And if you think of what we all used to do
years ago with Bosh scripting or Perl scripting or Python or whatever to orchestrate infrastructure,
Puppet, Chef, Ansible, Salt, Juju, that’s the opposite of Bosh.
It solves the same problem, works the opposite way.
So it really says here is a set of steps run this script get to some state.
Bosh says ignore the steps, define the state that you want and I will figure how to get
you there and keep you there forever. So these are state transitions.
This is what I like to call a narrow AI for deterministic infrastructure.
So this is our opinion and this is how we say hey whatever Bosh is running above, it
could be Microsoft Azure, it could be another public cloud, it could be a private cloud
powered by Open Stack, powered by V Sphere. Bosh doesn’t care it’s gonna get your system
into a desired state and keep it there. Now that doesn’t mean you don’t care about
the services provided by those underlying infrastructures.
And that takes us to this last piece, Open Service Broker API.
This was started originally by Pivotal. And turned into an open source, open community
project now embraced by the Kubernetes community, by Google, by other partners.
And it really says, hey, here’s a standard way of connecting applications to services.
Connecting the stateless world to the state full world.
The cool thing about this is it still embraces all three of those opens, it embraces any
language, any location, any services, and this is kind of a crazy picture but I wanted
to sort of spell this out. You’ve got some app running in Cloud Foundry
somewhere, it actually doesn’t have to be running in Cloud Foundry it could be running
in Kubernetes and it wants to bind to let’s say a Redis cache.
Well, that could just be running as a, sort of, platform service operated by somebody,
as a Redis endpoint. Could be operated by Azure, so you’ve got
Azure Redis. It could be spun up as a VM, and brokered
by Bosh for you, on demand. It could be a single tenant, or mult tenant.
The app doesn’t have to care. And that’s really the important abstraction
we’re seeing, is the Principle of Least Astonishment. Your developer wants to say, hey, my app needs
Redis, if my app is running in dev it should just be using Redis on my laptop.
If it’s running in this pre-prod environment, it should be using the Redis provided and
the VM next to it. If it’s off in production it should be using
Azure Redis. That separation of binding and brokering is
so critical to providing that kind of freedom. Now I’ve been talking a lot about the open
side of this, but I want to emphasize the other side of the coin, which is security.
And I’m going to bring a customer up for a second here a little fireside chat to talk
about Why staying secure while being open is so important.
But I wanted to make a Monty Python reference because that’s sort of what I do.
So when I think of security I kind of think of castles and moats and what was the secret
to the castle and the moat in Monty Python? Does any one remember?
He was like, we’ve already got one. The secret was multi-tenancy.
They don’t have to share their holy grail. We don’t need to go with you to find your
holy grail, we have our own holy grail. And in fact, everyone’s got their own holy
grail in this movie although you never get to see it.
It’s perfectly secure. All joking aside, the hard parts about security
in an open world is usually addressed best by just fixing the multi tenancy model.
If this data service does not protect users well from each other, just run multiple copies.
I don’t want to share Radius with you. Sorry, we’re friends but we’re not that good
friends. I’ll have my own Radius, you have your own
radius, that seems just fine, right? The technical term for this, and I think it
was Snap came up with this, I should double check that, is the limited blast Radius.
Things are going to go wrong. They’re going to go wrong in prod, they’re
going to go wrong in pre-prod, they’re going to go wrong every day somewhere in the world.
And maybe it’s a failure, and maybe it’s a security compromise.
The best position you can have is that the Blast Radius of that failure is really small.
Almost infinitesimal and that there’s other key infrastructure that can step in and take
up the slack and say okay well that reticence is gone,do we care?
Not really, it’ll be back in sixty seconds or so and in the mean time there’s other reticence
and other versions of the out burning else where.
So that separation of tenancy from configuration is really an important part of this architecture,
and I’m just talking about architecture here, I’m not really talking about individual projects.
All right, I went over a bunch of technologies, and I talked a little bit about architecture
and I talked a little bit about OpenSource but what I skipped was, how do you make decisions?
This all starts feeling really complicated. I have all of these choices, any language
I want, any location I want, any service I want.
How do I pick? And since all of this open source, how do
I pick which things I build for myself? Which things I just download from GitHub.
And which things I actually buy and get real support for.
Parker Thompson used to work at Pivotal and this was kind of his framework to say whether
or not you should really have the wisdom to know the difference.
That’s funny but not very helpful as a piece of advice.
So I was inclined to go back to an old colleague of mine, Clayton Stark and this is not, obviously
he didn’t say this to me, he said this first but in God we trust, all others bring data.
Use the data look, the data tells you when you should be building something yourself
and typically that’s when it’s as close to your customers as possible right you don’t
wanna be the best in the world at what you do you wanna be the only one in the world
at what you do so. If you’re in the business of building distributed
systems, you should be in a distributed system software company.
You should probably come work for us. If you’re in the business of building video
games, you should go and build video games, which is what Clayton does, right?
He does not build his own distributed system. And if you’re in the business of dealing with
millions or tens of millions or hundreds of millions, I have no idea how many transactions
a day of real valuable financial information. You should probably go work for MasterCard,
which is what my good friend, Rick Clark did, recently.
Rick, can you come up here? Let’s have a bit of a chat.
>>[APPLAUSE]>>[LAUGH]>>So, yeah, take a seat.
I’m actually gonna grab my water. I don’t know if you brought yours.
>>I did not.>>All right, well I haven’t opened that one
so here you go.>>Thank you.
Here you can have it I’m fine.>>Thank you, all right->>[LAUGH]>>So
just for context, I introduced you you know you’re the SVP at MasterCard.
I think you own everything related to cloud, which is->>Digital transformation, I’d say.
Cloud is part of it.>>Okay.
>>Very much.>>I think, I got to know you when we were
both involved in OpenStack back in the very early days.
So, maybe we can start with this transition, MasterCard involved in an open source.
Is that new? Is that a real thing?
How do you think about that?>>Well it’s not new, I’ve only been there
six months and it predated me.>>So it’s at least six months old.
>>It’s at least six months old, I mean we have backed up contributors to Apache so we
actively use open source. I think now it’s becoming a larger part of
the choice when we’re making decisions. It’s a bigger and bigger criteria and it’s
not just a check box. The way open source is done matters to us
So with that as a backdrop, why did you pick Club Foundry?
What was the thinking there to say hey, this could be good for MasterCard?
>>Well, there are many, many reasons which we don’t have time to go into.
[LAUGH] But the primary reason is that the abstraction layer works for us.
That when you’re going through digital transformation, there are a bunch of things that have to happen.
One of which is you have to retrain all the people who are working on brown field to eventually
work on the new green field stuff. And The abstraction layer, provided by Cloud
Foundry gives us the breathing room as we start moving applications so that we can do
that. So we can start increasing the knowledge
of our staff so that we can start working on, Other things.
>>Right.>>And then sort of move down the stack of
the different abstraction layers.>>Right.
I’m a parent and I always tell my daughters you can do anything, but not everything.
And I sort of feel like that’s true for your team when you’re going into any sort of transformation.
You can learn to do anything, you can’t learn to do everything so you have to pick those
abstractions.>>Well, starting with something that you
can actually do. [LAUGH] I’ve seen a lot of companies start
with we’re going to build our own platform and they’ve never done anything in the cloud
before. This was their first thing, so they were going
to do the most complicated thing possible because they know best.
We didn’t start that way.>>So there’s obviously a lot of players in
the public cloud and they’ve all been quoting, all Cloud Foundry users, in fact all of the
Fortune 500. What is it about Azure that’s exciting to
you?>>Well, I would say that, I know this isn’t
their slogan, but it’s kinda cloud for grown ups right?
At Mastercard we’re a big company and this is our first foray in the cloud.
And we needed someone that could provide us the support that we needed.
And was building something that was more caveat for us.
They’ve done a lot of hand holding, they were there when we needed them, so the support
I tell you, just number one.>>So Azure is cloud for grown ups, and Pivotal
gives you breathing room while you change.>>[LAUGH]>>This makes sense.
I guess the Cloud Foundry has a number of vendors I would love to know other than the
fact that I’m also personally. What was it about Pivotal as a Cloud Foundry
vendor that was->>It was all you and James Waters.
So again, this is new to us, we’re new to cloud and we want to go with someone that
has done this many, many times. Let’s rely on the experience of others, rather
than iteratively failing ourselves many times or going with someone that we’re not quite
sure about. So we knew we needed help to deploy it correctly,
and we went with the people that had the most experience.
Really not much to think about for us.>>Right,>>I do want to talk briefly about
OpenStack, but really in the context of a lot of what I am emphasizing here is these
buy versus build decisions. You can download things from GitHub and run
them or you can figure out how to build a team and assemble stuff yourself.
You can say, hey, we are going to build our own platform.
And we saw a lot of people d that with OpenStack, for a depressing number of years.
Do you think there’s a general principle for these sorts of decisions when you’re talking
to your peers, executives, and other financial companies.
Say hey here’s how you think about what do you buy and what do you build I do [LAUGH].
>>I think that everything that you build, developers are a precious resource in your
organization, right? Every line of code that you write should benefit
your customers or shareholders. So you shouldn’t be writing things that don’t
benefit them. If you go back to that, it makes the decision
easier. Also, I’d like to ask two questions.
Should we before can we? So, should we do this?
>>Right.>>Developers would want to do a lot because
everyone thinks I can do this 10% better. But should we?
>>Right.>>Even if you can, should we?
So I asked that question a lot to both my team at MasterCard and I discuss that with
other people in the industry.>>Right, right.
There’s a lot of false attribution error in the developer mindset I think.
Which is like, well, other people have written bad code because they’re bad people.
I write bad code because it’s technical debt and I was under pressure.
>>[LAUGH]>>And so when we imagine writing code in the future, we imagine it’s going
to be flawless. And therefore better than everyone else’s
code. And so there’s a lot of accidental hubris
in these buy versus build decisions.>>And I think open source communities are
a fun way to watch that play out. But let’s look at the Cloud Foundry Foundation
for a second. What signal do you think it sends to have
Microsoft joining the foundation so publicly?>>Well, I think I sense a very strong signal
to us, because we consider both Microsoft and Cloud Foundry to be important partners
for us moving forward. So the huge buy-in to the foundation, which
is extremely important and a big part of our decision to go with Cloud Foundry.
I mean that gives us some confidence and security.>>You also mention it’s not just that it’s
open source, but how is it open source and how is it built that it’s more and more a
factor. And you see that across our whole customer
base. Do you wanna elaborate on that a bit?
What is it about the community that’s important to you and to MasterCard?
Well, it’s that it can be collaborative and you can participate in the roadmap.
So if there are open source projects out there that are really just code escrow, right?
I mean, as you and I both know from before the days of OpenStack there were cloud projects
out there that didn’t allow you to contribute patches.
And if I can’t fix patches, if I can influence a direction then it’s just like closed source
to me.>>Right, right.
>>So having not only the ability to submit by patches and influence direction, but a
foundation that is separate from any one company is an important thing.
And I would say that if I’m looking at any project, that I’m going to go for the one
in the foundation before I go for one that’s not regardless of the project and the company.
>>When we think about you know, what happened with open stack for sure was this notion of
hey private cloud, public cloud are still important and what does hybrid look like in
the future and now we see>>Azure Stack on the horizon and we see certainly on the container
side things like OCI, and Run C, and even kubernetes which Pivotal has adopted with
Kubo and directly with Run C. Do you? Are you thinking carefully about the kind
of hybrid story to what goes into public cloud, what goes into private?
How do you mix those? Or is it still a question of preserving optionality
and be able to move it later? Well, so for us it’s about preserving optionality.
But that’s because regulatory requirements going to drive that for us.
>>Right>>If I was at a different company, where I didn’t have regulatory requirements
or could only be in one country, I would just chose public, personally.
>>Right. Yeah, we see only a small number of Pivotal’s
customers and because we again deal basically with the Fortune 500.
Most of them have some kind of hybrid story>>What about myths?
I feel like open source 20 years ago, 30 years ago was simple because there was so little
going on and now it’s beyond the point of so much going on that everyone is confused
and now it’s even more than that and people believe there are simple patterns.
They believe, so are there cases where you say well I had a vendor come to me and say
X and they thought it was really important and it’s not a thing I really care about.
>>Yeah I would say that we have a lot of misinformation that comes.
>>In terms of fake news, #fakenews and open source?
>>Yeah and some of it comes from open source vendor about another, and I don’t want to
call out vendors.>>Sure.
>>But yeah. There’s been quite a bit and I, you know,
I’ve worked hard to make sure that we get outside information.
Make sure that we don’t fall for those sorts of myths.
>>Right, right, that’s interesting. I I think it’s easiest in open source to see
the personalities at work, and to see the way the sort of culture of the community forms
around the early contributors. So that notion to your point of like if it’s
just code escrow. It’s just a way to be public about your source
code but not be collaborative. It doesn’t really help anyone.
the, you know, the other fake news thing I see, or I guess the question I would have
is, what about standards? You know?
Because it used to be everything was about the standards body, the RFCs and the DMTF
and the Whatever but now it seems like where the community consensus is is the standard.
>>Yeah, the market sort of defines the standard, and rather than chasing it.
So I firmly believe that. That the standard bodies, especially in there
a many you’ve probably noticed, but many of the large vendors are involved in standard
organizations just to slow them down [LAUGH].>>[LAUGH] Yeah.
>>So they tend to lag, while people try to get their products, the companies try to get
their products right. So, whatever is out there works.
>>Right.>>Ends up becoming the standard.
>>Right>>Just, let me take this one step even weirder, right?
So, you’re saying, look, we work with the open source community because we can collaborate,
we can influence the roadmap. We know that, over time, it’s going to be
more and more exactly what we need. And then, you think about, okay, also we’re
working in a>>Competitive world where we have other companies that want to get close
to us in our market. And I think in particular in the Fintech startup
space. Do you make decisions inside MasterCard now
on hey these things we are going to do in the open.
And these things we are going to just keep to ourselves.
Because we think they are a competitive differentiator or is the goal always to out execute, go faster?
And is it open first as a policy?>>I don’t know if it’s open first as a policy.
I mean, I think that there are reasons in our industry to not do that separate from
competition. That there’s a huge volume of finance information
that flows across our network>>So I think we are open when it’s best and not open when
it’s best.>>Right>>[LAUGH]>>Yeah, Sam Ramgy, when
he was running the Club Foundry Foundation was famous for having coined this idea of
Club Foundry as a place of practice. And I think he was taking in certain terms
of sort of a Buddhist framing of practice but I actually like the idea of deliberate
iteration as kind of the hallmark of a healthy open source community.
But something that a really healthy community does well is to define when is it ready for
use and when is it still experimental. And I guess, something we’ve been trying to
be very deliberate about in the Cloud Foundry community is say, hey, every subproject releases
whenever they want which is sometimes every day, sometimes every week, but Cloud Foundry,
Pivotal Cloud Foundry overall is released every quarter on a steady cadence and then
once a month there’s a dot release. We’re trying to find that sweet spot between
the rapid agile delivery of an open source community and what any big enterprise can
rationally consume. Right, because CD is amazing.
You don’t want to CD everything every day, right.
I don’t want to go up to the terminal, point of sale terminal with my MasterCard and go
to pay a bill. And have all the buttons in a different place
every day. I’d be like, how do I tip?
I guess the tip options today are in Greek numerals or something.
>>[LAUGH]>>Where do you see that sweet spot between like go fast, and go slow, or
go fast and be safe?>>So I guess it depends on where you are
in the stack. The way I like to think of things is you release
quickly with version. Services and then you let your customers decide
when they accept them.>>Right.
>>So that’s kind of my view of things and hopefully everything works.
>>So that what you just said there is that this key idea is that you have customers,
that the internal service has customers therefore you have your product.
Each service is a product. The larger application of the product that
has those as vendors. And then you have your eventual end user customers.
Do you think product management thinking is actually common yet?
Because I guess what we see in digital transformation is that it’s the hardest thing to go teach
companies. It’s to have a product mindset and say I guess
this is a Product, not just an internal service. It’s the real world thing.
How do you foster that or are you just hiring a lot of people?
>>Well, you know some of it comes from, culture comes from the top.
So I think we, at MasterCard, have fostered that kind of culture and that’s how we look
at things. The, in the internal service we build, it’s
It’s gonna be a product and we’re gonna treat the users like customers.
>>Right.>>Like we should.
>>Right, yeah. On the public cloud landscape, right, you
mentioned, I mean, rationally, if you were a small startup you’d probably just go all
in on public cloud. Would you go all in on a single vendor, or
would you still look for multiple vendors, and how do you think about?
>>So it depends, it depends on where I need to be.
If you look at someone like. Netflix, that single vendors work for them.
I think that no matter who you are, I think I can guarantee the resiliency of any public
cloud provider is better than your resiliency now.
>>[LAUGH]>>[LAUGH] So all of the mental anguish, it’s really just fake.
>>Right.>>I mean, they’re already better than you.
>>Right.>>So>>So, you could just pick one and go
>>Now they’re not all in all the same places. There is some ease once you get used to writing
to the services of one.>>Mm-hm.
>>So, if I only needed to be in the US.>>RIght.
>>I would probably go with one cloud provider.>>Right.
>>And stay with them and develop a good partnership with them.
>>Right.>>Cuz I’m not really worried about>>Any
cloud going down.>>Right.
>>I’m not worried about it.>>Yeah, I still see differentiation.
Kind of pretty interesting tech differentiation, and the focus, and the talent.
And when you think about a company like Microsoft, with tens of thousands of developers who’ve
worked for decades on Things like SQL Server. They know SQL really well and you’ve obviously
worked on SQL Technologies.>>Mm-hm.
>>Back in the day.>>[LAUGH]>>How would you counsel other
Enterprises, other ones of pivotal’s customers for when you make those decisions of saying
>>Just let your developers use whatever they want, or give them a pick list or?
>>I don’t think you can let them use whatever they want.
[LAUGH] I mean yeah that’d be great if you could but that ends up being unmanageable
and there’s no governance around it. So you have to be able to.
Those developers. If everyone does whatever they want, when
one of them gets hit by a bus, then you’re just out of luck.
So things have to be done with some sort of governance so that someone else can pick up.
And so I wouldn’t just say, take out your credit card.
Use whatever technologies you want. I think that that would probably be a mistake.
The first day of I built it is the easy part. It’s day two and day seven and day 400.
It’s like, I need to patch it and it’s already a legacy.
Every green field system turns into legacy eventually if it doesn’t die.
Last thoughts? Parting thoughts on these themes of enterprise
decisions around OpenSource and around the way that Old vendors are reinventing themselves,
new foundations, new technologies.>>So I will say about build versus buy, if
you’re not sure, don’t build it.>>[LAUGH]>>If there’s any doubt than you
are making the wrong decision. Yeah, there was no ambiguity in your previous
of should I and can I, but now you’re like if you’re not sure don’t.
>>I’ll tell you what I didn’t say is that the answer to should I is almost always no
unless it’s the thing that you do. Unless it’s what your company does.
You know, what pivotal does Is make a platform, a cloud platform, so you should do that>>Yes
>>That’s not what MasterCard does.>>Right>>We should do the things we’re
good at.>>Right, yeah.
It’s also why we don’t do billing systems at all.
You know, it’s like, we have not tried, and should not try.
>>Other people would try. You know, somewhere there’s a startup saying,
“You know what? None of these billing systems work for us,
let’s build our own.”, but it’s really complicated.>>Right.
>>Yes. Yeah, the reason they’re hard to build is
because there’s a lot of details that are not obvious.
And actually that abstraction thing, if you do a really good job of delivering the abstraction,
people will assume your software is trivial, because using it should be trivial.
But actually, what it’s doing behind is not.>>Very cool.
Hey, I really appreciate you coming over for this.
It’s been fantastic having you here.>>Any time, John.