Well, hello everybody. It's another Pivotal Conversations. I have a guest with myself this time. Why don't you introduce yourself? Hi, I'm John Faminella. I'm a platform architect with Pivotal. I'm based out of the New York City office and I like milkshakes, meta jokes, and long walks on the beach. Long walks on the beach. Very nice. You know, I'm going to a beach next week. Oh, you're not invited. Oh yeah. I'll just see if I can figure out some long walks there. You know, you're reminding me of another thing. I'm trying to like, you know, be all relaxed and laid back and wear t-shirts more as I'm doing now. Yes. And now I understand why people are always wearing like hoodies. Yes. Because if you, if you just wear a t-shirt, it's a little cold. Well, once I realized that it was acceptable, at least it was acceptable for James Watters to wear a hoodie while talking to Fortune 500 CEOs, I was like, oh, okay, it's probably okay for me to do that too. Yeah. Yeah. Yeah. I mean, you know, I live down in Austin and it's hot there. Yes. So I just can't get into like hoodie culture. Although it gets hot in New York, right? Right. I solved that by never going outside. Oh yeah. That's how I solve most problems associated. Well, I think that's a, that's a totally okay way to solve every problem just by becoming a hermit. So you, you, uh, you gave a talk here. I did. Why don't, why don't we start with, uh, with going over what that was? So what, what was the, it's like about, uh, how, how platforms have contracts and how you can't have a platform without contracts and things like that. Sure. So, um, I realized in the course of my job, uh, which is talking to customers about Pivotal in general, um, and also specifically, uh, some of Pivotal's products, one of which of course is Pivotal Cloud Foundry, um, that the, that oftentimes they were discussing the way that they built their own platforms, um, in terms of very strict cost benefit analysis that I felt weren't really a accurate description or a accurate summary of exactly what the total cost of ownership of that platform was. Yeah. Well, as, as, as they say, you said a mouthful there. Yeah. That's, that's a, uh, that's a huge thing in our collective craws, like whether it's our customers or ourselves to sort out. Right. And I think it's, I, I, you know,
2:06obviously the audience at SpringOne is not just other Pivotal people. So I wanted to kind of talk about what are some of the ways that one can evaluate a platform or platforms against each other and, you know, what, what makes sense and what doesn't make sense. And I felt like one of the things that does make sense is to think about the contract, the implicit contract that you're agreeing to when you are building a platform or agreeing to, uh, right include one in the organization. And so the, I felt that the biggest, most important thing to look at is the people that will be impacted by the choice of a platform because, you know, we can talk about technology all day long and the benefits it's going to bring, but at the end of the day, a human being is using it. So if you're not, if you're not, um, considering the people, the developers, the operators, the business owners, et cetera, that are involved in that, you're really missing a pretty critical piece that won't ever be captured in any kind of, um, P and L or, uh, it's like, it's like a, a user analysis of the users of the platform. Exactly. Right. That's a very good way of putting it. I mean, they're, they're kind of stakeholders in overcharge world word, but they're, they're the ones that you're doing this for. So it's probably a good idea to pay attention to what it, what's useful for them and what's helpful. And you'd be, you would be surprised or maybe you wouldn't be surprised at how often that seems to get ignored, um, by folks who are about who making these big technology choices. And for them, it's like, let's look at this rubric of like features that we need and not about like, how is this going to impact the way that we do work? Will it change anything? Or is it just going to be, we changed what we're deploying to, but not anything about how we do that or why we're doing it. So there's not enough opportunity for introspection in, uh, when, when you use tools that don't encourage that to begin with. Right. Right. Okay. So I mean to, I, I, I don't know, I'm starting to predict that there's like this interesting idea of like, use the, the, the word contract, which sounds all like serious,
4:10right. To, to this essentially as, as a, it's almost like a kind of a, a fake out approach of like just making sure you have good usability. Right. And, and, and, and the way you, I'm, I'm guessing you reduce it down is like, like you're saying, like if, if you have users of this platform, it's kind of like infrastructure or not kind of, I mean, it is infrastructure and you more think of like what you depend on the infrastructure for and what it's supposed to provide for you instead of like, you know, uh, what would, what would be more of like a usability thing, right? Like, Oh, it's delightful. Sure. When I like cropped this image or whatever. I don't think that's a sentence I've ever said in my life, but maybe that's because I haven't used the right tool for image copying. Exactly. Um, I have to say that's not a void in my life that I need like filled at the moment, but, uh, but if it were, maybe I'd be looking around for tools. No. Yeah. The, the contract idea, I think that's definitely part of it, what you just described. Um, I drew the analogy of course, like a legal contract and the, there are many elements to a correct and, uh, successful legal contract, but there are three big pieces. One's called consideration, which means that the two of us, the two parties or two or more parties in the contract have to agree that they're both getting something when they sign the contract. So there has to be an exchange of value of some kind. A contract without consideration where one party gets all the benefit and the other party gets none, uh, is not actually a valid contract. I think the technical term is a ripoff. I think the technical term is a terms of service. Yeah. Yeah. Yeah. Um, so that's the first piece. The second piece is, uh, the contract has to, um, there, there has to be sort of a meeting of the minds there. Uh, both people have to agree that what's in the contract is what they actually wanted. So if somebody, for example, uh, if you don't knowingly enter into part of the contract, then you'd really have a complete understanding of it. And so the legal contract would not be enforceable. You can use your terms of service joke again. Yes, exactly. Right. Thank you for reminding me that I think I will use it again. Um, but yeah,
6:11I mean courts have repeatedly held in many different cases that certain kinds of terms of service are not enforceable for that exact reason. Uh, but those are really the, there are many other elements of the contract. Those are sort of the two that I focus most on in the talk. Um, the consideration element is, uh, is, uh, is the most relevant because it's, uh, it's about evaluating what are you giving up to run some platform or kind of control. Are you ceding to the platform? Uh, and in many cases that, that control may be stuff you don't want to do anyway. Uh, nobody wants to run their, you know, network drivers or do orchestration and scheduling themselves necessarily, that kind of thing. Um, and you know, we at Pivotal talk all the time about how we want folks, we think folks should stay above the value line because that's, that's what drives revenue. That's what drives business. You want the way that you deploy applications and the way that you, um, run applications and services to kind of mirror that philosophy of what benefits your business the most is not to focus on things like network drivers or, uh, orchestration and scheduling. So, um, so the contract approach is, is meant to have you think a little bit more about, well, if you think about sort of platforms that don't ask you to change very much about what you do, where, you know, that seems like good at first, at first glance, because you're not changing very much. And so you get to do everything that you're currently doing. But of course that raises two questions. So first, if nothing really changes about the way that you're doing anything, then, you know, are you going to get any benefit as a result? Like, if your whole problem is that the way you're doing things now is painful or agonizing in some way and nothing is changing about that, then I'd really gain anything. But the second point I try to make is if the, uh, if you are running applications on some platform and that platform doesn't need you to change anything about your applications or it doesn't ask a lot of you, then in effect, it can't make very strong guarantees about the kind of things that are running on it because it, because anything could be running on it. And when you are asked to make assumptions about the universe of possibilities
8:16and arbitrary code could be executing in an arbitrary language, an arbitrary environment with no constraints at all, then you're not really running a platform. You're really just running a different flavor of infrastructure at that point. Yeah. Yeah. I mean, I like, I like the, the metaphor of this is that you need, uh, uh, a give and take in, in order to like, uh, an equanimous exchange. Right. And so, and so you kind of like personify the platform as like, you know, it needs to get something, right? Like, like, like, like what, what's the benefit to the platform, which you've done for me lately. Yeah. Which again is like metaphoric, but, but as, as it kind of points out, and, and I imagine there's another sort of thing of, uh, you could sort of use a technology without changing yourself, but then typically what happens is it's more constraining than you want and it's more brutal. And in the sense of you can always use the network like a network and it doesn't necessarily tell you how you have to change things, but it'll just like shut you down if it doesn't like you. Yeah. There's no, there's no contract right about what acceptable behavior is. Right. So, I mean, imagine that you, you've, you've got some, uh, imagine there's some hypothetical platform that will, uh, run anything you want on it. Um, well, what can that platform do for you? Uh, the answer is probably not very much because if you can run anything on it, uh, with un, unmodified, no, you know, no effort on your part, then, uh, as I said before, that platform is basically infrastructure. What I mean by that is its job is no longer to do something special for your applications or provide some kind of enhanced guarantee on the top of your applications. Its job is now just to run anything. Yeah. And that's like a hard drive. That's not a platform. Yeah. So yeah. Right. Okay. That makes sense. So, so then, so then like, what are some examples of the, uh, consideration of platform gets? Sure. So, uh, you know, at least with cloud foundry and other sort of similar, uh, platforms that operated that level of abstraction of running applications and services, you hear the phrase 12 factor app thrown around a lot. So
10:16the 12 factors are meant to, um, sort of optimize your application for being cloud native. And it's just the first step, of course, there's many, uh, steps along that journey, but that's sort of one easy barometer to, uh, to sort of gauge how effective your applications will be in a cloud native environment. And that's, that's an example of the kind of consideration you would give the platform. You'll agree to have applications that don't write to an ephemeral disk or, uh, get their variables from a environment, uh, or if we ever get their configuration from environment variables, um, and so on. So they agree to behave in a certain way and by exhibiting that behavior, the platform can make guarantees. So for example, in a 12 factor application, if it's stateless, you know that it's okay to, uh, swap out the ephemeral disk that's underlying the container because it's safe to do that because nobody depends on the ephemeral disk. Um, so since that's okay, then you can do things like have a massive disk failure and your applications won't even know if anything has happened at all. Yeah. And I guess, I tell me, this is another one. I, I hadn't thought of this one, but like, uh, previously until you're kind of getting going down this, this route, but like there's another one of the 12 factors is like, uh, I'm, I'm rephrasing it, but your configuration should be injected. Sure. Right. Like you don't, you don't, you don't ship with your own configuration. And then, and then that, so if you follow that, that part of the contract, what that means the platform can do is it's much easier, your configuration to use a service or some third party thing or a backing service. So then the platform can move that around and can not, to some extent reconfigure it, but, but you, you give up fully controlling how you connect to and even how you configure a service. But that means that the platform can manage it a lot more and optimize it. And I think of something that's worth pointing out too, is we're describing, we're using the words giving up, but in many cases, people don't want to do these things and probably shouldn't be managing them anyway. Um, so for example, the case you just brought up of like the, the server that can move, um, well, what if it
12:17wasn't the server that moved, what if the password changed? What if you wanted to change your password every five minutes? No, that's a great example. Like that would be cool because like now you're, now you can only be vulnerable to like someone stealing your password for five minutes at a time. And then you rotated the credentials and your application can't tell what difference because it's getting its configuration from a source outside of itself. I guess maybe a, a comical, comical version of giving up is like, you know, if you use a, uh, to do list manager, you're giving up the opportunity to have to keep track of all this stuff in your head. You're giving up a certain amount of control because you know, you, this other thing is remembering for you. And I think that's an important point too, is like, um, you know, we say all the time, at least in the software development community, that it's probably smart not to roll your own crypto. So people have gotten the message about that. Like banks don't write their own encryption algorithm. Well, good banks don't write their own encryption algorithms in general. They rely on, you know, trusted sort of ideas about how that works from the security community. You know, and yet people seem to think it's totally fine to, uh, you know, basically invent their own platforms from scratch when this requires a huge amount of work, a huge amount of effort. And there are great community solutions out there already. And, um, you know, reinventing the wheel on this kind of thing just seems like, uh, way below the value line for, for most folks. Yeah. There was a few little, I mean, like we're here at, you know, SpringOne platform, as I like to say, the most awesome name conference ever. And, uh, you know, there's, I need to go look through my notes and stuff and rewatch some of the videos, but there are a few good anecdotes of people who are using, uh, well, PCF, I guess, Pivotal Cloud Foundry. And it illustrates like need to be silly again. Like we talk a lot about day two problems, right? Like once you put an application into production, you have to monitor it, you've got a operation stuff, but it's almost like with a platform and you've got like day 425 problems. We're like, you know, now we need to update the platform. Right. Like we're, we've built this whole other product, which I mean, obviously we're, we're both at a vendor, so that neatly fits into our financial and
14:17everything interests. But it is, I mean, these are the anecdotes that, that there's like three or four I've noticed of people who would say like, oh yeah, we built our own thing. And that, that's not cool. Right. And then we realize like now, like with encryption, like you don't really want to have to manage encryption when there are much better sources out there to do it for you. Right. Of course, the danger is that you don't realize that until day 100, 425, something like huge amounts of investment into it. Do you come across that a lot? Like, like up in your, you're up in the Northeast there? Uh, less, you know, sort of more of an, I'd like, but less than I feared. And, um, the, uh, I think, I think there's a particular tendency in certain industries to believe that they are special snowflakes and are, the probability is higher that people in certain industries will probably write their own platform. Um, and that's sometimes expected, right? It's kind of like really big companies are often operating at a scale that on some, uh, some, uh, orthogonal metric is unique or is actually bigger than most other companies of their size. And so that can motivate the, like the decision to write your own platform. But the key there isn't about, um, you know, it, it isn't about like number of transactions per second or whatever that you need to do. It should motivate the decision for a platform. It's again, really about the, it's a combination of the people, the processes and the technology that you're looking at and not simply, uh, not simply a, uh, sort of like performance metrics. Yeah, exactly. The, um, and I think the way to, the way to get around that question is going back to contracts of like, what are you giving up and what are you getting? Yeah. And if you're, if you're trying to accommodate a huge volume of transactions or some other large unique metric for your company, you should look at, well, is maybe the platform solves that. Maybe the thing I'm going to write will solve that one problem. What am I going to do about the other day, hundred and 425 problems that are also part of running the same platform. So. And then, and then I imagine also, once you spell out a contract,
16:21I mean, and to cut myself off as a, I recorded one of my other podcasts, the Lords of computer computing episode with, with Matt Curry from Allstate. And I'm always asking him about like, you know, what metrics would you use? And like, what, what, and at one point he was just like, why, why are you always asking about metrics? Right. And, and so with that kind of like, like context for it, you know, maybe at some point this is ridiculous, but I imagine if you spell out all this contract stuff, you can start to associate like dollar figures to it. Oh yeah, absolutely. And so you can kind of walk yourself through that, that bootstrapping for sure. Like, I feel like there's a technological bootstrapping thing to going cloud native. I'm making air quotes, but there's also a, for lack of a better word, business bootstrapping of just getting the business to, to realize that like, Oh, this is not an ERP system installed. Like this is not a VMware install, and this is not an app server install. This is like a different thing that we need to wrap our thinking and decision processes around. Yeah. And I think that's, that's sort of another benefit of the like contracts approach is that a different mode of thinking may help you see that this is fundamentally a different beast than like an ERP system. I mean, we, we've definitely, humans tend to want to analogize to things they already know. So it's very natural to want to look at PCF or another similar product and say, well, what is this like that I've already seen? Yeah. And in many cases, it's totally different than what you've already seen. So it's hard to sort of make that analogy. So that's why I think thinking about it in terms of a platform where you run applications and services is most meaningful because there aren't many things that do that and, or do it well, I should say. And, and that will probably be most directly comparable to what you're trying to build internally. If you're trying to make the decision between PCF and doing it yourself. Yeah. I was talking with one of our, our, our salespeople down, down in the south earlier today, and he was saying in his, in his kind of like industry, he was finding a lot of traction with the idea of, of like pitching cloud native and pivotal cloud foundry is sort of like this kind of new thing
18:22you're indicating is like, it's not only to analogize, it's not only an app server. Sure. Right. Right. But it's like, it's like, I think, I think the phrase is like one and done, like it's all this other middleware stuff on top. And I think, I think that's part, I always jokingly say middleware, because it's like, because you know, it's an old word, right? So it's hilarious. But I, I think that was one of the sort of epiphanies he had is like, at least for the people he talks with, if you tell them that it also includes middleware, then they're kind of like, Oh, right. So it's like, not only is it like infrastructure as a service, but it's also all this stuff on top. So you can just start to do applications. And I think, I mean, I, other than being crassly commercial like that, that kind of illustrates the point of like, how dare you, they haven't, yeah, they haven't, there haven't been that many stacks that sort of like have all this stuff in it. Like, and the only one that I could really think of was basically like as a Java developer, what I think of as .net, right? Like if you, if you're, if you're a Microsoft developer, I'm going crazy with the air quotes here. Like you have, you sort of historically, and nowadays as well, like you sort of have that, you're just like, I just get the MSDN DVDs and I'm done, right? Like I have everything, essentially. So, and I don't, outside of that world, aside from interesting little exotic stuff here and there, you don't really have, there hasn't really been a lot of that full stack. The batteries included. Yeah, exactly. And in fact, I think, I mean, at least way back when I, maybe even to the present, when, when I was a programmer, it was almost like you didn't want that, right? Like you wanted as much modularity as a developer, you wanted, or even architect, as much modularity as possible. And it was even delightful to go through and have the week long meetings deciding which frameworks to use on, on down the, the chain. Yeah. I mean, I think, you know, nowadays, especially with Microsoft being such a great partner for us, there's, you know, I think the days of like downloading the MSDN DVD are sort of behind us at this point, but the, you know, now you can grab a tiny slice of a .net framework if you want. Right. Yeah.
20:23They have it all broken up. It's been decomposed. Yeah, exactly. It's super modular as compared to, hey, I've got this enormous, you know, C++ runtime DLL, but like contains the entire C standard library. Yeah. And, you know, it's not the, it's not the, the, the, you're not boiling the ocean just to get one library inside your application. Yeah. I think there's definitely been a trend towards modularity. And I think, and I think also, especially with the rise of open source as a accepted, accepted tool chain for big businesses to use. Yeah. I think that's really helped things like Pivotal Cloud Foundry because we're at least in part a competition of various open source tools with our sort of proprietary Pivotal digital magic sprinkles in there for the support and the excitement of, um, of, uh, of, of how we're, of how we're like actually putting that platform together. So I think that's, uh, that represents something that I think is unique about PCF, um, as compared to say an arbitrary enterprise stack that you might be finding out. Yeah. Well, you remind me of something I've, I've been wondering and since, since you mentioned it also, I think kind of being in the, the, the like Northeast area, right? Like, so I, I, yesterday we had like our, our CIO round table, you know, which, which is, that was fun to, to present at and, and like hang out and listen to that. And, and in that, in that, that day, and then also other days I've noticed, um, there's been a lot of discussion or let me say more than the zero discussion I assumed about how it's basically like, so open source is cool. You should use it. And, and for me it's kind of like, I didn't even know that was a question still, but, but I mean, because you raised it up, like, what do you, what do you encounter out there as far as like, is there like skepticism or worry? Well, I mean like now, no, but like five years ago, I think it would be, I mean, five years ago we have said that Microsoft was like pushing an open
22:24source code editor and like all of this stuff. So like things have changed really fast. But, but like on, on, on, on the, the, the enterprise side, like, like, do they fret about using open source or? No. I mean, I think that again, five years ago that this would have been a totally different. Yeah. So not, not that long ago. It's easy to forget that was like 2011. Right. Exactly. Yeah. Well, actually I teach a class at a university in Charlottesville, Virginia, at UVA. And, uh, when you, when you start the class, they give you a roster of everyone who's in the class and their birth dates are, are on there too. And it's so sobering to look at that and see that they're all born like after 1995. Yeah. And that just makes me feel like super old. Like the, the video game systems they were playing were like Xbox and like it was on, you know, NES. Yeah. They never got to watch Seinfeld. Never got to watch Seinfeld. Maybe that rant, whatever. How can you live like that? Exactly. Well, so, so how, so how was your talk received? Did you, did you get questions or like what? Nobody booed. So that's always my threshold for a great talk. That would be awesome if, if like we were in some kind of industry where when you give a presentation where that was a possibility. Well, maybe I just haven't given it to the right audience where like people could boo at me. I mean, yes. Um, yeah, no, it was great. I think it was really well received. I think, uh, I was up against Josh Long and Casey West at the same time slot. So I think I was definitely competing with them on, uh, on attendance and, you know, lost miserably. But, uh, the, the people that did come were, uh, pretty excited about it. I got really great feedback afterwards. One person said that they were going to like, when they got back on Monday, they were going to like immediately start looking at the platform that they were considering and deciding if it was sort of holding up under this contracts approach. So I've, I was like the best possible thing someone could have said to me is that they got something out of the talk and they're going to put it into practice. That's awesome right afterwards. So. Huh? So other than the presentation, which I'll have to find the link to it when it gets posted,
24:25uh, you know, cause it's recorded. Um, but like, is, is there some other, like, I mean, do you have like a document or a blog post or something that goes over it? I don't know. I honestly, I honestly, this has been the synthesis of just like random ideas like while I'm in the shower of like, Hey, you know, I, I feel like I'm saying the same things a bunch of times to people in general. And it makes sense for me to kind of, um, start putting these thoughts down into a deck and that's usually my first like thing is like, how do I, how do I explain this to other people? And you know, my first stop, uh, at least for me is usually like, let me give a talk about it somewhere. So yeah, no, that's good. I mean, that's, that's a, that's an approach I use all the time, sort of presentation as whiteboard. Yeah, to kind of sort out your ideas and force yourself to do it. I'm certainly grateful to the conference organizers and, uh, you know, Humphrey for giving me a platform to blather on about this for a little bit. A platform for platforms. Yeah, exactly. What do you have anything else you, you want to go over on that, that topic or did we miss anything? No, I just, I, so I guess I'll just say that there, uh, you know, system stuff that I'm working on that I think is fun that other people might want to check out. I mentioned to you before we started the podcast and I'm looking at Kotlin, which is a really cool JVM based language that's trying to bring more of a functional style to, uh, keep like the flavor of Java, but have a more functional approach and, you know, introduce, um, some typing ideas from languages like Haskell and, um, and a little bit of OCaml sprinkles and things like that. So you're getting, you're getting a sort of functional experience without, without really needing to, uh, become fully functional programming zealot type stuff. Uh, and the other cool thing that I've been looking at lately is, um, a containerization technology called unikernels, which are sort of represent a next step in, uh, contain, or I should say a step in a certain direction for containers, not necessarily a next step, but, uh, expansion of the idea of what containers can be. Sure. And unikernels are super neat for very, very, very specific and very, very niche use cases at the
26:27moment. But, you know, no one thought that Docker or other containerization technologies would get as big as they were in 2012. So the fact that, uh, the fact that unikernels are starting to become a thing is I think very interesting to me and, um, and definitely worth checking out. They're really hard to use right now, but they're, they're getting better. And, uh, I suspect that maybe a couple of years from now, we'll be talking a lot more about unikernels than, than we were before. Yeah. Yeah. I mean, what little, we, we should, we should record another whole episode about that at some point, but like that, what little I know about unikernels, it seems like if you have the right kind of, I'm sure by this time we'll have a different word for it, but orchestration or choreography or management overlay thing of a jiggy on top of it, that it would actually be really interesting just for like, like really, really, uh, componentized and also oddly secure and trusted trusted is a better word than secure. Sort of just like processes, a little one-off process. I guess it wouldn't even have to be one-off, but just processes that you want to execute. Right. And you'd have these like little, little atoms of in out. And I mean, it's kind of, I guess it seems like a good way to implement like all this serverless mumbo jumbo. Yeah, definitely. Yeah. But you need, you need a, a management straight above that. Otherwise it's just, you know, you're a hundred percent right. A bunch of people yelling at you. Yeah. You know, a thousand like tiny voices is just a cacophony. That's not actually orchestration. Exactly. Or you got, you got my wacky analogy. Yeah. All right. Well, perfect. Well, where, where are you, uh, online and in Twitter and everything? So you can find me at JXXF on Twitter. And of course you can always find me on Pivotal, uh, or just, you know, yell at me somewhere on the internet and I'm sure I'll find myself. Perfect. Well, great. Well, as always, this has been Pivotal Conversations. You can find us, uh, like our, our raw SoundCloud page at soundcloud.com/pivotalconversations, because URL should be long to type. And, uh, you can also just go to, uh, blog.pivotal.io or I think it's, what is it? Pivotal.io/podcast. Man, I really need to memorize that. And you can see the,
28:29uh, lengthy show notes that get posted and everything. Uh, and with that, we'll see everyone next time.