 Fun bit of trivia about this talk. I've never actually been asked to give walk-up music for a talk before. So the day I had it all picked out, I'm a big Pearl Jam fan, it was going to be a Pearl Jam song I was coming out to, and the day I had to pick, I come from Maine and it was a typical Maine spring day, which is, say, it was about 38 degrees, raining, just awful weather. One of the office in Robert Plant is screaming at me about coming from the land of the ice and snow, so hence the immigrant song, intro music, and we're here to talk about something that immigrants care a lot about, which is freedom. Now for those in the audience who may be free software people, we're not going to be talking about freedom as in free software, one, because I don't like to have that conversation very much, and two, we don't have time. What we're here to talk about instead is freedom as it pertains to choice. We're going to look at, you know, essentially some of the choices that are available to you and what that means, both for better and as the title says, for worse. So to do that, we're going to cast ourselves back, and we're going to go back to 1998. Now 1998, some of you in the audience, at least from what I could see from yesterday's session, were probably in high school during that time, I don't want to talk to you, that makes me feel super old. In 1998, I was a systems integrator, and we'll come back to that in just a minute, but that same year, a company was founded, some of you may have heard of these guys, another fun bit of trivia, that actually wasn't the name, the name was actually mis-filed on the original paperwork, and they just stuck with it, it seems to have worked out all right, some of you probably heard of that brand. In 1998 also, the Voyager spacecraft became the furthest, the man-made object furthest from our sun, so props to NASA for sending that out. A book was released, some of you may have heard of this, this actually was released the year prior, made it to the United States in 1998. And a movie about a boat, some of you may have seen this, judging from the fact that in March of 1998, this movie became the first movie to crack the billion mark for worldwide sales. So what's the point here? The point is that it was a simpler time. It was a very different time, and it's not necessarily just when we look at things like media and books and so on, it was a simpler time from a technology perspective. So as I said, I was a systems integrator, so my job was running, sort of running around to different businesses and helping them build applications. Some of the companies in the room I probably worked with at that time. And the job essentially was to build these applications for a variety of reasons, but the interesting thing is that the number of choices that went into building these enterprise applications was pretty minimal, it didn't seem like that at the time, it seemed, we had these complicated bake-offs and brought all these vendors in, and it seemed like a difficult thing to do, but particularly when we think about just what are the core decisions that get made, aren't that many of them? So platform is sort of a big one, right? And the interesting thing is that there weren't really many choices to make in terms of the type of platform that you were going to build on. Because basically, we talked to most of our customers at the time. You were probably going to go down one of two paths, Java or Microsoft. If you went the Java route, which a lot of the businesses that we work with did, there really wasn't any argument. Everybody built applications more or less in the same way. Three-tier architecture, spread across servers, you're probably going to use a Java application server. And within that category, you're probably looking at two vendors. Sometimes we'd have as many as three or four, but it usually came down to either BEAs, WebLogic, or IBM, for WebSphere at the time. And it wasn't just with application platforms. Databases were the same way. When we, in 1998, would walk into a customer, we would talk about building these applications, and we talked about databases. We didn't say relational because that was just assumed. If you had a database, it was going to be a relational database. Because the ratio of databases to answer, what's the question? Was basically the setting. And when you look at relational databases, again, you didn't have that many choices to make, right? You basically are probably picking from two or three vendors more often than not. We ended up on Oracle. So this was the world, right? This was all of you in the room who build enterprise applications. This was how it was done, right? You looked at sort of a world in which you pick from a very, very small number of vendors. And there was essentially an agreed upon approach for how we build things. Now we fast forward to the present. World looks very different. For a variety of reasons, I wrote a book called The New Game Makers. We don't have time to go into that whole spiel. But the important takeaway from here is that developers for a whole variety of reasons have been empowered in ways that we've never seen before. They've been empowered to make choices. So again, in 1998, we didn't have the ability to go out and get free software and assemble architectures ourselves. We had to essentially work through channels and buy the software to implement it. Today, thanks to open source, thanks to the availability of low cost hardware, from a cloud perspective, among two other factors, developers can make the choices themselves. Half the time, when we talk to businesses, the platforms that they're built on were started by developers who never asked for permission. They eventually showed up and said, hey, this is what we built, using free software, using low cost cloud platforms. So that's great, developers are empowered, they can make these choices, they are the new game makers. But those choices, not surprisingly multiply. Because if you think about the difference between if you have a CIO or some other decision maker within an organization, and you're making some decisions, not gonna be too many decisions that can get made. If you think about organizations such as many who've been on stage in the past couple of days, who have thousands, tens of thousands in some cases, but developers in each one of them is making individual choices, not surprisingly. You see a lot more diversity in terms of the choices that are made. So this leads to what we refer to internally as the Cambrian explosion of software. Now, we didn't come up with that term. We borrowed it from a gentleman by the name of Brian Aker, who was one of the original architects from iSql. And basically what it refers to is that the Cambrian period in life, for those of you who are geologists or probably pan-intellogists, I guess. Basically, when you think about the way that life evolved, it's meant millions and millions of years, first to get to unicellular organisms, then to get to multicellular organisms. And that process took years, millions of them, literally. And in the Cambrian period, from a geological perspective, there's this tremendous explosion of life. All sorts of new life forms begin to emerge in a very, very short span of time, geologically speaking. And this is the Cambrian explosion. Now, we're seeing exactly the same thing play out from a software standpoint. We've gone from a world that we just talked about, where you have a small number of commercial options, you don't have that many choices to make. Now, you have all kinds of choices. New software is arriving every day from every corner. And as we'll see, this is good, but it can be a challenge as well. So when we think about it, we're talking about the platform earlier, the Java application server that was the standard in 1998. Today, it's not even picking between the platforms, it's which kind? As Kim was saying, in the opening, you have questions like, how do I think about Kubernetes versus Foundry? Well, guess what? That's actually a pretty narrow segment of the choices that are available to you. You have to sort through, as a user, as a developer, as an ops person, whatever your background, through an incredible array of options. So before you even get to product selection, before you even get to talking to vendors, you have to figure out, how am I going to do this? What am I going to use? What is the correct approach for what I'm trying to do? Same with the database. As I said before, it used to be, the relational database is the answer. Now, what's the question? Today, we'll talk to developers, we'll talk to enterprises. In many cases, using four or five different styles of database on a single project, they're relational for this piece. Some sort of big data for a lake that sits behind it, in memory caching all manner of different persistence mechanisms. So again, you can see how these begin to multiply. You can see how all of this choice begins to add up. And that doesn't even get to the speed, the rate in which these things are arriving. So as a non-comprehensive sort of list of platforms that have emerged in the last couple decades. So 1997, we see the emergence of the J2E application server, VA, WebLogic, WebSphere, others certainly that we could mention. 2007, we see the emergence of hosted platform as a service. Force.com came out first, Google App Engine shortly after. And then obviously the project that we're all here to talk about, Cloud Foundry kicked off the open source, PassMovement in 2011. Containers, now somebody's going to nerd snipe me in the audience, I'm sure, I'm not saying that containers were invented in 2013. Containers have been with us for a very, very long time, dating back to the mainframe in fact. But 2013 was a company called Docker, popularized them for the first time they blew up. And in 2014, AWS introduces a service called Lambda. So again, this is not comprehensive with lots of platforms that are left off this list. But if you are in the audience, you think about building an application, these are some core choices that you could make. In terms of building different styles of application, obviously. Now what's important about this list? Well, from our perspective, it's the pace. So you have 10 years before the first two, six years after that, then two years and then one year. So the point here is not just that, hey, we have a lot of choice and there's a lot of diversity and there's a lot for you to sift through, it's that choice is actually accelerating. It's picking up. So the choices that you have are not only wide but they're widening faster as we go along. As I'm sure every single one of you encounters on a day-to-day basis, right? You think about this, it's just huge array of technology, open source technologies. Again, Cloud Foundry being the one that we're here to talk about. But Cloud Foundry is a piece of the puzzle as we'll talk about. So it's not just with projects either. Some of you may have seen this as an eye chart, you're not meant to read this. What we're trying, the point that we're trying to make here is that this is essentially a plot of our language rankings. We do them twice a year. We look at data from GitHub and data from Stack Overflow. We correlate them and we produce a ranking, a plot. And again, the point of this isn't to try to pick out where anyone language is. You can go to the website and look at that in more detail if you like. But the point rather here is to emphasize the fact that very much like projects, languages have exploded in terms of usage. Back in 1998, for the most part, if you're talking businesses are gonna be writing Java, they're gonna write in a Microsoft language. Probably, that's the majority of projects. Today, we may have two, three, four, five languages used on a single implementation. You're gonna have a couple different components because people are increasingly using a best tool for the job approach. So when we look at this plot, we have 10 to 12 languages that are very popular at the top. We have another probably 12 to 14 that are, again, very popular, not quite as popular in a tier two. But what does that mean? It means that we're looking at two dozen, potentially three dozen languages that are widely in circulation within enterprises. It's a totally different world. Totally different world. And obviously, some platforms called Foundry Among Them have adapted to that and have adapted to this multi-run time world. But the point is that we live in an age of choice. We live in a world where you have a huge array of options. You have a huge number of choices that you can make for every project that you implement. Now, from a developer perspective, on one hand, that's a great thing, right? Because all of a sudden, back in the day, back in 1998, I didn't have any of this available to me. I couldn't take pieces, high quality free software, or I should say open source software, off the shelf, assemble it on hardware that's gonna cost me pennies per day and build something. And companies, for example, that can, in the case of WhatsApp, right? You can essentially have a huge multi-billion dollar valuation with a tiny team. That's possible because of all of this choice. It's available to you. So what's the catch? Well, the catch is, not surprisingly, the choice does not come without a cost. So it's an excellent book, I recommend it, if you haven't read it, it's by Barry Schwartz, and talks about energy choice. And choice is this thing that we tend to treat as an unmitigated good. That's something that we must preserve at all costs. And in large part, that's true. Choice absolutely is something that you need. Nobody wants to be locked into a single option, a single approach. But there are diminishing returns over time. Too much choice becomes a burden. And we see this playing out now in a variety of markets. So probably most of you in the audience don't deal with this every day. But the explosion in JavaScript frameworks has been absurd. It's a job of people like us to look at, monitor, and evaluate new technologies as they emerge, but JavaScript frameworks is basically impossible. And that's our full-time job. Now imagine, sort of as most of you in the audience are, your full-time job is not keeping up on the stuff. Your full-time job is doing what you do. So what's the point here? Well, the point is that from the technology standpoint, it begins to cause friction. So Tim Bray, most of you probably know, is essentially a legend in the field. Works for Amazon now, has worked for Google, and lots of other places over the course of his career. Very, very smart developer, still actively developing. And he has observed this, which is there's this cost. There's an overhead to his widening base of knowledge that you need to have to remain relevant as a developer. Marco Arment, some of you I'm sure in the audience use his Overcast podcast application. Others of you may know him from, I think he's employee four or five, I believe at Tumblr. And he's gotten to the point, as a famous developer who makes his living, essentially building products. They're available on the web and elsewhere. And he's gotten to the point where he's lost almost all interest in being a web developer. Why? Because of this choice. Because there's too much choice, there's too much arriving too quickly, and it's difficult to process, it's difficult to keep up. So, okay, you're probably sitting here saying, that's great, I guess it's a mixed bag. What do I actually do about it? And this is gonna sound trite, but bear with me. The simplest piece of advice I can give you is to think. There's no, unfortunately, magical solution that is going to solve all of your problems. There's no single answer, single approach that's going to be appropriate in every workload, for every application. But what we want and we recommend all of you to do is to think about the implications of the choices that you make. So again, I don't have time to get into it here. There's a fantastic sort of vision, I guess, or methodology that's by Clayton Christensen, who many of you may know from the innovators dilemma, and he talks about the job to be done. In other words, what are you trying to accomplish? And that, in the context here, is likely going to be whatever the application that you're building. That is fulfilling some purpose, that is doing some job at your company. Now, Cloud Foundry, or any other software that you use, is going to be a part of that. But it's not going to be the entire solution. And the difficulty is that, and the reason I have containers as a background here, is that you will very frequently see people pick up and identify one technology and say, this is great, I'm going to solve all of my problems. Okay? Well, how? Because the simple fact of the matter is, is that no piece of technology that you use is going to solve all of your problems. What you have to think about is the job to be done, what are you trying to accomplish, and how much of that job can be accommodated and can be solved or addressed by the piece of software that you're using. So essentially you need to take a wider vision in terms of what you're using. Just as important, you need to think about the choices that you're making. And more importantly, the choices that you don't want to make. As an example, we talk to developers every day. And one of the things that we see increasingly over time is that developers are opting out of choice. You know, there's choices they just don't want to make. So, you know, when they're using a cloud platform, in many cases, they're just going to default to whatever the cloud platform is going to offer them for a variety of services. Messaging, database, take a pic. Is that because they've decided that this is the best tool for the job? Maybe, probably not. In many cases, they're just opting out of that choice. You know, they're saying, you know what? I don't want to sit down and have to evaluate a dozen databases. This thing's pretty good. I'm going to use it. And there's nothing wrong with that in many cases. As long as you are conscious and cognizant of the fact that you have these choices and you've taken a step back and thought about what are the choices available to me, which are the ones that matter, and which are the ones that I care about? How do I think about the choices that I make per platform? So back to the sort of Kubernetes, you know, versus Cloud Foundry, a question that Kim raised and has certainly come up a number of times at this conference. Those are going to imply different choices, right? They have different implications to them. It's not, you know, for me or for anybody in this room to say, to be prescriptive and say this is a solution in every case, but you have to think about the choices that are made. Cloud Foundry is opinionated, is going to make certain choices for you. May or may not be the best approach. Kubernetes is going to make a different set of choices for you and open or close choices for you. So part of what you need to do is understand the choices that are implicit in the technology that you're using. And lastly, and perhaps most importantly for all of you, is the value. Think about the value of the individual choices that you make because organizations in many cases are making decisions without any eye or any sort of essentially tension to the long-term value. Does this sort of make a difference for my organization? Is this a high value thing for me to do? You know, going back to the cloud services, many organizations are looking at this and saying, am I getting any value out of running my database? Am I getting any value out of running, you know, messaging service, streaming server? Probably not. So is that something that I can outsource? Maybe. Again, it comes down to thinking about the value. But most importantly, and the thing that I would leave you all with is think about all of this on an individual level because so many talks at conferences, you know, so many conversations that I have with people in my lot of work as an analyst are going to talk to you about numbers that are enterprise, essentially important to enterprise, right? You know, efficiency and return on investment, cost, value chain, et cetera. But the key for me, for all of you, whether you come from an ops background, app dev background, or both, is basically think about the value to your day, right? On an individual level. So sure, I can have a conversation with each of you about the benefits to your organization for any one of these pieces of technology. But what I need all of you to think about is, is this a good decision for me personally? Is this addressing something that I need? Is this making my day simpler? Is this fun? Do I like using this? You know, and conversely, is this going to solve a whole bunch of problems so I don't have to deal with it? And with that, I am actually two minutes over. I'm out of time. This is where you can find me online. I appreciate the opportunity to be here and have a great conference.