 We got a lot of ground to cover in a fairly short period of time. This presentation kind of covers everything I could think to throw into it. So I would encourage you to get the copy of the slides because we kind of look through them real fast and kind of get a feel for what this thing's all about. At the same time, we're going to move super fast. We're not going to go into some detail, but I have a lot of detail in this slide just so you have that as takeaway information. So when you leave here, you go and look back at the slide and go, oh, I remember he said something about that. There's hopefully a URL or some other drill down on that. You can also follow me on Twitter and ask me questions via Twitter if you'd like to. And you can also throw questions out in the middle of the session and we'll try to get to them as fast as possible. But the quick question we have right away is how many people are not from Red Hat here? Not from Red Hat. Oh, OK, lots of not right here. It's fantastic. So how many of you folks not from Red Hat? We consider yourself to be a business application developer. So this is a smaller number here. And we're going to focus on business applications in this session. And there's a huge distinction between building a business application versus building infrastructure. If you're from Red Hat, you primarily associate with infrastructure. You build things people don't see. In the case of a business application, you tend to build things people do see. And there's a distinction there. And we're going to focus more on that side. Is that fair? OK, and if I talk too fast, I apologize. This is just how fast I go. And like I said, we've got a lot of ground cameras. So let's get in here. So this is kind of the agenda that I have. We're not going to really be able to drill down on any of this. But we're going to at least touch on a lot of it, because a lot of it really matters. We're going to talk a little bit about digital transformation. That's a term that means a lot from a marketing standpoint. We're going to talk about it in the context of being a developer, though. Because the key element of being a developer is you are the catalyst to this digital transformation. You are the champion of digital transformation. If it happens, it's because of you. That's the fundamental thing to understand. And your organization cannot transform without you. So the good news is we're going to be worth more than we've ever been worth in the history of our career paths. And for those of you who are still students right now, I'm a couple of students. So for those of you who are not even really into the full game of being a professional at this point, the good news is you picked the right career path. You're going to do really well. And I say that as a guy who started school. And I actually did my first programming in 1986. And at that point, people were like, yeah, we think these computers are going to be important one day. We didn't know in 1985, 1986. They were toys. There were things you played games on. Mostly games where you walk up to the door, open the door, not on the door. Remember those tech space games? That's what computers were for back then, right? And then all of a sudden they became like these business machines. We're going to talk a little bit about cloud, but that's going to be pretty easy. Talk about automation in general. We're going to talk about microservices. My favorite part about microservices, you can go super fast and you will die, right? Speed kills in the case of microservices, but if you really have a mainstream deployment mastery like delivery deployments can carry deployments and go fast and live, that will be an important part of it. You want to live if you go. We'll talk a little bit about A.B. testing and hypothesis driven development. This is a key element that I'm focused on right now. I want to talk to you a little bit about being a full-stack developer. If you are a business application developer and you love basically saying, I'm only a backend person, you need to let that go at this point. I don't care how long you've been a backend person, how long you've been a proctologist, you're going to also be a plastic surgeon, okay? It's great that you love the large intestine. I mean, you know, we absolutely have to have that guy, right? But at the same time, if you can't make something that's interesting for an end user to consume, you're not going to win in the future. So being a more full-stack, we'll talk a little bit about that. There's also new stuff happening in the JVM runtime world. Drop Wizard started all of this. Spring Boot now owns this, if you will. We'll mention Ballfly Swarm and then I'll talk to you a little bit about VertX, which is my favorite of these. And Kalant is here to give four sessions on VertX or something. Mr. Loss here? Yeah, no? Well, not in this room, but I hope that's in the world. So we have four sessions on VertX, some comments you'll want to see. So let's kind of dive right in. Let's just get going here, okay? So in the world of digital transformation, you can see the average life expectancy of a Fortune 500, right? Has declined from 75 years to less than 15 years today. So the Fortune 500 are going to churn, is what this point basically means, because they're not going to be able to digitally transform. If you actually look at the top five market capitalized, not even saying the word right, capitalized in the market from a stock market standpoint, they're no longer brick and mortar companies there anymore. Now your Facebooks and Googles have displaced your exons of the world and your car manufacturers and whatnot. So this is happening in a substantial way. Businesses are changing, they've become digital businesses. You don't want to be the next blockbuster. You want to be the next Netflix. You guys know what blockbuster is here in Czech Republic? So the blockbuster employed tens and tens of thousands of people in stores around the globe and now they employ like 2,000 people, right? They've shrunk down to nothing. And so Netflix is completely dominated. So you don't want to be in that business. You don't want to be in the taxi business when Uber comes to town, okay? You don't really want to be in the hospitality business when Airbnb comes to town at this point. So just keep that in mind. So this is what it used to look like in the old days. I like to give a little history lesson. So in the 80s, we built these things called twoies. This is what I call them, character user interfaces. Remember, VT220, VT100, 5250, 3270, back in the day when we had block mode or character mode screens. And it involved a lot of people. You basically, if you're a manufacturing plant manager, you would actually see that your machine was, let's say, out of product, out of supply. You needed to order something. So you would pick up the phone and call your sales rep. The sales rep would answer the phone. You'd give them the order verbally. They'd type up the order on a typewriter in many cases or maybe they'd handwrite it out. They'd put it on a fax machine, which would get sent to, the fax would get sent to the back office person and this person would actually key it into the computer. They would do the data entry here. Three people involved in that. This is the way we used to do software. This is how software systems used to run back in the 80s. So they had a nice green screen or amber screen that they would put all that data into. But fast forward, we got into the GUI. We had Windows machines and graphical user interfaces and we actually told this sales rep. We gave him or her a laptop and said, hey sales rep, you enter the data yourself. It doesn't have to go to the back office data entry person anymore. And then we actually said, wait a second. And the OOs, we have this concept of the web. The customer could do it themselves via web user interface. And we all live in this world now, right? We use Amazon. We don't go to the store anymore, right? We order our food online. We order whatever we need online and we don't have to worry about that anymore. And so most have gotten super sophisticated, right? Now we're no longer pinned to physical location where desktop computer is. We actually walk around our mobile phone and we go, oh, I need more of X. Let me order it on my phone and punch the order in. And in the future, we need no people at all. So actually I brought my dash button here. I haven't done anything with it yet. But if you think about it, even as consumers, right? We're just, the sensors will know that we're out of whatever and it will just order it automatically, okay? And so that is definitely the future of enterprises. They have to find a way to eliminate as many expensive people as possible to automate all things, at least. Now a lot has changed over the last couple of decades too. Used to be IBM and Digital Unisys own this world. I did Unisys mainframe programming way back in the day, okay? They don't even exist anymore. So look at all the people that no longer exist on this sheet. They were the dominant enterprise player of the day. Sun Microsystem is a good example. Novell was king of its day, right? That's what I was, Novell, network of land administrator way back in the day when we invented the local area network. And that's no longer. Now Netflix is king of this new world. They've completely changed Java middleware at this point. They open source Netflix. And if you actually see a presentation by the Netflix guys, they'll tell you, here's my name, I work for Netflix. We run a third of the global internet. The global internet, a third of the traffic for Netflix reason. So our software scales. Or maybe it's Google, right? Google, of course, we worked with them on Kubernetes and now we have this technology for basically launching containers. If you watch a Google presentation, they say, you know, we're gonna talk about Kubernetes. We launch two billion containers a week. We know something about Linux containers. So these new guys, right? Amazon, Google, Netflix, they're having the greatest impact on enterprise IT versus these guys. So things change, that's my point with this, all right? Things keep changing. So are we ready? This is actually a good data point here. So we're the talent. We're the people who have to make this magic happen. So talent is leaving at the same time it is in short supply. There's not nearly enough of us to do the work needs to be done. And of the executive survey, only 11% believe the people they have are good enough to do this. So the big bosses, you know, if you survey all the big bosses and big companies, only 11% believe that they have the right talent. And that's us. That's the people in this room. So think about that for a second. We are really the champions of where we wish to go at this point. We're the captains of our own ships. I really like this particular example when it comes to digital transformation. I like this because I used to work at Walmart. I worked at Walmart to pay my way through college from a 1986 timeframe to 1991 timeframe. So I, you know, stock shelves. I checked people out with the cash register. I moved stuff around, you know, clean toilets. I did all that at Walmart. But here's a great example. Walmart is a very traditional company. And they decided they were gonna completely roll out all their Java stuff. They took away the entire Java stack, put it in the JS stack in place, ran Black Friday on it with 200 million users concurrently. It was running so well, less than 1% of resources, that they decided to roll an update on the same day. With 200 million users concurrently. Right, so this is Walmart, a very traditional company and one that's kind of near and near to my heart, but they're gonna compete with Amazon and they fully intend to, okay? So this is kind of what they live in. This is where, this is what digital transformation looks like. It's changing the rules for your organization. This gentleman no longer works for Walmart. He now works for the Irish based, no JS company, which is called what, do you see what I remember? Who's our Irish based company, near form? Near form? Yeah, are they on this up here? No, up here. Okay, so just keep all these things in mind. We'll keep moving here. But you can see that 200 times more frequent deployments for the digitally transformed, right? 24 times faster to recover. Almost 2,500 shorter lead times. These organizations have adopted all these ideas are moving fast. This is why they will win. They may not be winning today, but if you're moving 2,500 times faster than a competition, you will eventually surpass them and by the time that company, the competitor who sees you in the rear of your mirror, you'll blow right by them, right? Because it's too late, they can't move at that speed. And so that's what we're seeing out of companies like Amazon right now, who deployed 1,000 new features last year alone. And that's just on AWS. They'll talk about the fact that when you're deploying on the main Amazon site, Amazon.com, they do several thousand deploys a day now. That's an example. So we, if you've read the Phoenix project, it talks about doing 10 deploys per day, 10 deploys to production per day. Well that was old data when the book was written. The company they're talking about is Etsy. They're now into 45 to 50 deploys per day. But then as soon as that number hit the market, the Amazon guy goes, we do a couple thousand a day. Think about that for a second, right? To production. That's kind of insane. When most organizations are still in a six month to 12 month deployment cycle, these guys are doing a several dozen times per hour, right? Okay, so this is a statement that I've made up. We don't have to spend time on it, but I do think that fundamentally, regardless of where you work, we have to fundamentally rethink everything we do. We have to break with the old and really embrace the new. And go fast is the new mantra. You gotta be able to deploy fast because the only time you know if your software is worth a damn is in production. Testing in production is now the thing to do. You can do all the testing you want pre-production, it matters not at all, okay? This is the new world. So this is your journey to this new world. You have to have some form of self service on demand elastic infrastructure. This point sounds crazy. This is the concept of the cloud, but if you work in a large enterprise, it takes you anywhere from three to six weeks to get a computer, okay? And I want to ask the red hat people here because you know what I'm talking about. If you need a server, right? If you need, if you're a student, you're going to be an expensive resource one day. If you're not a student, you're already very expensive resource to the organization. You're not cheap, right? You're expensive. And you have to wait three to six weeks to get a server to do your job. That is insane. And this is normal, right? If you talk to the average enterprise, there's somewhere between three to six weeks to get a virtual machine. Still, I just met with a customer eight days ago. They're like, oh, six weeks would be fast for our organization to get a server. It's kind of insane, okay? You got to think about organization, re-organizing, focusing on DevOps, right? Where DevOps work together. That's super fundamental. And it actually is a game changer because right now Dev, of course, is a different vice president than Ops. And in order for a developer to talk to an operator, they got to talk to their manager, who talks to his director, who talks to her vice president, right? Who talks to the other vice president, who talks to their director, who talks to their manager, and then they realize they didn't actually say the same thing and they got to go back to that chain here. So communication is the fundamental problem and this solves or helps address the communication problem, okay? You got to think in terms of your automation. If you're still writing scripts to do an installation, or worse yet, actually clicking through answering questions in a prompt to do an installation, you got a fundamental problem there. Installation should be one of those things where you hit a button and it just happens. It should happen automatically and instantaneously, essentially. You got to think in terms of your continuous integration and continuous deployment pipeline. We'll talk more about that in a second. And of course, then you can build microservices. You've all heard about microservices. Everybody's doing it, by the way. It's just like teenage sex, okay? Everybody's doing it, and no one's doing it well. All right? And if you do all those things, you can be like a Silicon Valley dot com startup. You can be, this is the GitHub unicorn, that's where I stole it, by the way. So I love the fact that he's snarly and pink with a rainbow mane, and it might be she, I don't know, you shouldn't know, but I love the fact that that's the kind of unicorn we want to be, okay? So this is Martin Vowler's version of the same thing that I just did here, so it's not like I just made that up. Martin Vowler also talks about the same thing. You have to be this tall to ride this ride. Do you guys know what that is? If you're a rented amusement park, and I say this as a person who's not very tall, I used to go to the amusement park as a kid and I couldn't get on the roller coaster. I wasn't tall enough, you know? So that's his point here. You gotta be so tall to ride this ride, and so you gotta think through these same principles also. Okay, here's Jezz on CI. The guy who wrote this book, right? Continuous delivery book? Nobody does continuous integration. How do people here work in some form with Jenkins or something like that? Touch on Jenkins. Pretty much everybody, okay? So here's the test. If your team, when you're CI, if your team knows that everything in trunk is always ready for production, how many people would say that's true? Nobody? You're only at least one. Come on, play along. Come on, you can be the one. Oh yeah, in trunk, ready for production. Not thrilled. But think about that for a second. So everyone uses Jenkins, no one's doing CI. You're not doing CI, you're just using a tool. You're not practicing the practice, okay? So Jezz would also say everybody is checking in to trunk daily, at least, once a day. So trunk is always ready for production, and everybody checks in daily. Because continuous integration means you have to integrate all the time. If you're on a feature branch for two to three to six weeks, right? That's not integrated. That's precisely feature branch means it's not integrated. So you gotta think about that for a second, okay? If the bill breaks, it has all hands on deck to fix it within 10 minutes, even if that's a Saturday evening. That's how committed to ensuring that the bill is always ready to go, okay? So this is Jezz's test, not mine, the guy who wrote the book. So pretty much I've seen now, I've seen several representatives him go out and give this presentation where he asks the audience this question. How many people UCI all the hands go up? How many people's trunk is ready for production almost all the hands fall, all right? How many people checking their trunk daily? There's like two people left with their hands still up, and you'll say, well, the rest of you here, please congratulate these two people because they're the only ones doing CI, okay? So you gotta think about that. We're not doing CI yet anywhere in the industry by Jezz's definition. We gotta start doing CI for real, okay? Trunk is always deployable. Everybody checks in trunk. Every bill is ready to rock all the time. The bill does not break, and if it does, it is something that is, you know, a religious event to make sure we fix it, right? Fix it right away, okay? Not about using Jenkins, all right? We'll keep moving here. Continuous delivery, continuous delivery specifically so that we know that the software we produced is ready to go, right? It's ready for production, it's ready for users safely, quickly, in a sustainable way. So these are three key words here. We're doing it safely, we're doing it quickly, we're moving fast, okay? And it's all, it's sustainable. People aren't working 24 hours a day to make this work. People are not actually doing deployments on Friday night. So here's another great test if you're a work for large enterprise. When you guys do a deployment to production, when do you do it? You'll find that most people do deployments to production on Friday evening. So the developers have gone home, they're having shots, right? They're like, yeah, we're out of here. We checked our code in, we don't know if it works or not. And the operators are spending Friday evening to Saturday morning trying to make that crap run. That doesn't work anymore. In the world of DevOps, you, the developer, also there for your crappy software to ensure it runs properly in production. And I can guarantee you this, because I've worked, I've managed the engineering team before, when you put the engineers on the front line to ensure their software runs production, the bugs just go away. I actually ran a development team specifically several years ago where because there were so many bugs that hit production, I declared bug fix Saturdays for several Saturdays. It's like, fine, you guys gonna have some shitty software on Friday? When we roll it out Friday night, everybody shows up on Saturday to fix the bugs in production. We only had to do two of those. And for some reason, all the bugs went away. It's kind of like magic, but it's just purely a communication issue. It's just a human issue. If you know you're accountable, you will fix your stuff. And the problem we've had in the world of developers versus operators is the developers have not been accountable. They're like, oh, I checked in my code. I had no idea if it really runs. Some QE person, some QA person will look at it. Some port operator will have to deploy it. That's no longer. You are accountable from end to end at this point. And you make sure that it runs great in production. And when you do that, you fix the bugs. So in this world where we think we're the developer and we can throw our package over the wall to pump this port operator on the head in operations, this is the old world. This is the world that existed prior to now. This is no longer our current world. We basically have to eliminate that wall of confusion. And then basically work together to deliver the package together. So that's an important element. What's this thing doing? Okay, we'll be gone. So if you have not read these two books, I highly encourage you to do so. This should be mandatory reading for everyone in the IT business at this point. You need to read the Phoenix Project. It's super cool. It's written like a fictional story. It's easy to read. It talks about the VP of operations who basically has to, they deployed a new application and the application brings the entire business down. And it's cool, called the Phoenix Project. That was what the code name for it was. I actually did this to a company in Phoenix, Arizona. So I actually have my own Phoenix Project where we've deployed in Phoenix, Arizona and shut the entire business down, okay? So that's what this is about. And then of course, if you want to solve this problem, right, read the DevOps Handbook by Gene Kim also and Jezz and Patrick and John. These are the guys from, so John is on the DevOps podcast. Definitely you should listen to that. Jezz, of course, the book we saw earlier. Patrick DuBois did a lot around serverless, but he's the guy who actually coined the term DevOps as an example. So you want to read their book also, okay? This is an example of a monolith, all right? Monolith, monolith means big old thing. This is actually a single rock and it's giant rock. There's a big carving up there. Here's what the big carving looks like, okay? This is the Confederate battle leaders for the southern states of the United States. These were the rebel leaders, right? They lost, okay? My point with this is, there's a monolith from Georgia where I'm from, right? And then of course, the people carved into that monolith lost the game. So let's talk about more about this, okay? So in the world of Javi, we had this concept of the operating system, the John virtual machine, right? We have an application server. We have an ear, an enterprise archive that went on that. We had multiple wars in our ear, multiple jars and mores in there. These jars were shared with different third party main dependencies, DTOs, transfer objects, entity objects, things like that, right? And here's the trick with this monolithic architecture that we specify for Java users. Everybody has to agree to all these things, right? Everyone has to agree to this version of the app server, this version of JVM, this version of the operating system and all its patches, and that includes patches to the JVM. We all agree to these same third party main dependencies. So we might have a very large team of people here who have to agree to all these things. Like 50 people who have to agree. And can you imagine getting any group of people to agree to anything? Have you actually tried organizing a bake sale for your children's grade school? You're trying to organize like a group of kids to go to an activity? You can't get anyone to agree, right? You just have to tell them what to do. And so this is the problem in this whole world. You might have 18 programmers and four business analysts and two compliance people, right? You worry about, is this thing secure? Is this thing within regulatory compliance? You have these different operators and DBAs. They all need to agree. And this is why it's a communication problem. This is why it moves so slow. Because decisions take months upon months, you know, to actually make happen. In the future, we're gonna break up into these teams called two pizza teams. That was a term coined by the Amazon folks. The idea was you can feed the whole team on two pizzas. Now these are American-style pizzas, right? Not European-style pizzas. Still, two pizzas. That's approximately six to eight people on each team. And they're wholly responsible for the technology they produce in production. Their job is to get the software they create in production as fast as possible so they can learn. You can only learn in production. And then, right, they own it. They build it, they own it, and they run it. That is the new paradigm, if you will, we're seeing within software development, okay? So these are the key principles of microservices. We don't have time to really spend time on them, but you can see the number one bullet there is deployment independence. That's the one we wanna focus on, is the ability to deploy that component independently of all others without injuring anyone else as we do it. So as we deploy that new component, it can roll out instantaneously all day and every day. We'll talk about some examples when I do that. And Raphael will show you in his presentation how to do it with OpenShift and Kubernetes as an example, okay? This is actually, is a great report here from ThoughtWorks. If you wanna know how you get more information in this world, you go to ThoughtWorks Technology Radar, and this is a quote from that technology radar for the most recent one. And so basically, this is the new way of thinking about software development. Docker is your process, your Linux process, if you will. Your pass is your computer, right? In this case, Kubernetes would be your computer, and microservices is the programming model. So we think about the layers of abstraction now, right? We're no longer dealing with C on, let's say, writing firmware at the hardware level, right? We're dealing with these levels of abstraction where microservices is the programming model in which we build all our systems going forward. They all run within containers on a backbone like Kubernetes as an example. That is the cloud native way to do these things. So that's not just me talking about the stuff that's also the ThoughtWorks guys talking about it, okay? Now, if you wanna find out more about these things, I'd encourage you to show up for Rafael's presentation. So he's got one on 12 factors today, so he'll walk you through that and do demonstrations of that. And then of course, we have a full microservices presentation where he'll do demonstrations there too, and walk you through those same principles, but we gotta keep going. Okay, purpose of the pipeline. Jez Hummel again, the deployment pipeline's purpose is to make sure a release candidate is unreleasable because everything we check in a trunk is always ready for production. It's always a release candidate, and the purpose of the pipeline is to verify that this is not releaseable, because by default, we're releasing. So the default mindset is production, production, production, production, not the other way, right? So we actually have to change our mindset, our previous mindset, our current mindset is, oh, I checked it in, but God only knows if it runs or not. Someone else will go look at it. No, the new mindset is when I check it in, I know it's ready to go for production. And this purpose of this pipeline, right, and the QE and the QAs of resources along that pipeline is to validate that it's not ready, okay? Because it should be ready. It's a different mindset, so you think about it differently. So if you think of a deployment pipeline, you might have, of course, the commit to SEM, right? This is where you check in to get your get commit or even your subversion. It gets through a development phase, maybe on a series of development servers where it aggregates and does a continuous integrated build, continuous integrated build, right? It goes to maybe a QA phase of some sort, and then some form of a staging phase and then out to production. So this is a typical deployment pipeline for a lot of people. This is kind of what they do. They might have another stage or two in there, but otherwise it's kind of these major steps. And the cool thing about it is when you do it, if you do it with a blue-green deployment, right, so you do your common build, you get it checked in and it does a build. It'll flow through, it flows through development, and then QA and staging, and then it'll go out and you can see the current blue one is the active one, and so what we'll be deploying is the green one here, and we switch the route of the green. So this is how you do fast deployments and actually still be safe. Because if anything bad happens, you can switch it back to blue, right? So you can go from green to blue, back and forth, and this is how you go fast, right? So this is something that we've seen within the Silicon Valley Unicorns. They're doing stuff like this all the time. And now it used to be very hard to do this, because it used to be this router right here cost a lot of money. It came from a company called Big IP, it was called F5. It required very specialized software engineers who knew how to update it, and actually once you got it configured correctly, because it cost you about 80 grand just to configure it, you never touched it again, right? And the new world where this is let's say Kubernetes, it's just a switch, right? It's just tick, tick, tick back and forth, and Rafael will show you that in a demonstration later. Okay, so the why this is important is this concept right here. You guys have probably not seen this stack before, but I love this one. So this guy named Ronnie, he used to work for Amazon, now works for Microsoft. He's done a lot of research over the last decade, and his theory is that only a third of what you do adds value. So think about that, all the code you write, all the software you produce, and I personally throughout my career have actually produced software that never even made it to production. So if it never gets to production, no value. His point is kind of a little bit different. Not only has it made a production, right, but it actually has to add positive value to the users who consume it. And in many cases, all right, a third adds no value, one third adds negative value. You've hurt people when you deployed that thing. So you have to think about those terms, right? Have you caused injury? Have you done nothing? Or have you added real value? Only a third of the time you've added value. So how do you actually solve this thing? You actually have to come to your software development with a hypothesis, okay? So what is your hypothesis? That's a key question you have to ask yourself. And then you would do something like, called A.B. testing, similar idea in the pipeline, but you notice the little light green here. The idea is that when you do push that build to production, only a small group of users are receiving those requests. Only a small group of users are running that new software component in production. The rest of the users are seeing the old stuff. And if you're leveraging things like Linux containers and a backbone like Kubernetes, this is all very doable and actually not that hard. But in this case, you now can see your software running in production. You basically will flip this out as a test in the production. And you also have concept of canary deployments which we skipped over very quickly. But the idea is that if it runs and it runs successfully, maybe we open it up to the rest of users. If it does not run successfully, we shut it down and run the next experiment. But this concept of always experimenting in production is where the new world is going. This is why some of those people who deploy a thousand times a day, or even 50 times a day in the case of Etsy, this is where that mindset is coming from. I wanna run an experiment. Let's see if users like it. Nope, they seem to hate it. Get it back out of there, run the next experiment. And sometimes, depending on the level of traffic you have, the experiment has to run for several weeks to verify if it adds positive value or not. So here's an example that's more specific. It might help you out here a little bit. So let's say this is my mobile application we've designed and it's just an e-commerce style application. Most of you guys should be familiar with the e-commerce style application. And you can see I have my title of the product, the price tag, the star review system, details, thumbnail images, add to cart, right, and recommendations here. So this might be my AA example. And you see here on the B example, I decided to move the add to cart button up from down here. I believe that's gonna give us better transaction volume. I believe people are gonna add that product to their cart more often because I moved the button. That's my hypothesis. It may not pan out, but if I run that as a test in production, I will know if the customer likes it or doesn't like it. Now as a software person who lives in the old world, we would sit down and we would debate this change for six months, right? We would have managers get involved. We'd have committee meetings. We might even actually sponsor some research with a third party research organization. And we'd finally make this decision and we'd try it and then it wouldn't work and we wouldn't know why. And in case of like an Etsy, they just run it in production and try it. See if customers like it or not. And it actually does have very subtle ones. Let's actually look at a more interesting one here as an example, okay? So you can see our recommendations here and notice my recommendations here are slightly different. So in this case, I didn't change the user interface. I changed the recommendation logic in production. I basically came up with a different algorithm to determine that based on that product's affinity with these other products, whether it be products that support it, maybe it's like a power supply to the laptop or some special stylish or like that or if it's just other products like it. I find, I believe, my hypothesis is if I give you this recommendation, instead of this recommendation, you will buy more stuff. So the end of the day, your AB test is really to have business metric impact, okay? I want to sell more stuff. That is the purpose of my business is to sell more stuff. My software people also know the purpose of my business is to sell more stuff because they work for this business. In which case, they want to also validate that this hypothesis is true or untrue. Very often be the old is better than the new, but we don't know that until we try it in production. No committee meetings, no long multi-month effort to decide what to do or not do. We make the change, we run in production and we'll find out, okay? Another example that's also a little bit more interesting, you can see right here where it says in-store pickup 15 available. So literally based on the GPS location of this phone device, I can look around me geographically to say, oh, there actually is a physical store for this customer. If you're like a Walmart or a Best Buy or something like that, you know, Fry is a big electronic store, you want to let people know, you can buy it right now on your phone or you could drive 10 miles that way and grab it off the shelf if that's what the consumer wants to do. So very well convened that we think this is the right model, but in the future, our hypothesis is, okay? You can see, did I make the change here? There it is, there it is. You can see that let's actually just put a map up. We'll show you, it's so close to you, come buy it right now. That's our hypothesis. We think that will actually be better and drive more sales, drive more customers. So do you guys understand this concept like the A-B test, right? You try something and you give another alternative to a subset, a portion of your user base. You do this in production. It's a test running in production, but now you know with real human in-user behavior, if it works it doesn't work. And you skip the committee meetings, you skip all the management overrides, you basically decide let's write it in production. So this concept of going fast to production is so you can do this form of hypothesis driven development. You can actually run an idea in production, see if it works. And if it works, you stick with it and you let everyone have it. If it doesn't work, you roll it back and run the next test. Now this sounds like common sense once you hear about it, but this is not how we do it if you work for an enterprise software organization. This is not how you do it if you work in a large company, typically. This is how the Silicon Valley times do it, right? But not necessarily the other people. So we're gonna see a lot more of this happening going forward. We're gonna see a lot more people running these kinds of tests going forward, okay? They'll run it through a continuous deployment pipeline. They'll run it through as a blue-green deployment, verify it from a technical standpoint that all stands up. We didn't over-allocate memory. We didn't eat all the CPU. That's really what your blue-green's gonna verify. Not the end-user experience, but more the actual technical attributes of the package. Maybe we'll run a canary deployment, right? The canary and the coal mine. You guys know about canaries, right? I assume that, maybe I shouldn't assume that. So in the case of, if you grew up in the United States, there's a little place called Kentucky or West Virginia. They mine coal there. So coal, the black stuff we dig out of the ground, burn and we make a lot of smog with, right, that stuff. Okay? You know, it's used for heating purposes and power generation. So back in the day, when we used to send coal miners 10,000 feet, you know, of 500 meters down on the ground to dig out coal, in the case of the U.S., at least, they would actually, as they're digging, actually hit pockets of natural gas. Natural gas has no real smell, but it would kill you pretty quickly, okay? You would just breathe it and you're dead. So they would take a canary down with them, a little bird, a little cage, a little yellow canary, and they'd take it down to the coal mine with them and the clarinet would sing. Maybe the canaries, they sing, they make noise, right? They're, it's a happy bird. But if the canary stopped singing, you'd look over in the cage and the canary is on the side, that means get the hell out of the coal mine. Okay? Real simple. Dead canary, get the hell out. So that's why they call this a canary deployment also. The idea is you can put that thing out production, try it, if it's not doing well, get the hell out. Simple idea. So the concept blue, green, canary, AB test, these are the new ways of doing things for an online hosted service of any sort. And people are now figuring how to do these kinds of things with even things like firmware. So one of the things that Jess Humbold loves talking about is the HP printers, right? So literally they actually found ways to do continuous integration and continuous delivery principles with firmware for HP printers. So it can be done in these non-hosted kind of scenarios too. So you just have to think through exactly what your architecture will look like for that. All right, how much more time we have? Do it okay? What's that? Okay. 50 minutes. Yeah, so look at Rafael's session for more on this concept of running the pipeline. So he'll be running you with actual demonstrations through this that you'll see that soon, right? Okay, we got more around the cover. You notice I just jammed everything on this one slide. This is actually not my area of expertise, but I did go to our UI team. We have a handful of people within Red Hat as an example that are just bad-ass UI guys. And I can show you some of the stuff they've done. Some of the stuff they've done is Mindboy. If you watched last year's keynote demo where we literally are animating people's faces and it looks like fireworks going off and all that, it's all done in JavaScript. It's all done in the browser. But what you can do in a browser these days is absolutely amazing, okay? You're gonna have the right level of people to do it. But my point to all of you guys is, you can't just be a backend person anymore. You gotta be a full stack person, okay? Full stack means you understand if there's a user interface that users will consume. You understand there's component middleware within that front end user interface. It might be an NBC solution like AngularJS, all right? And it gives you the control on the client side. You also understand there's an API layer you built back in the server side. If that's Ruby or Java or Go or Node, it doesn't really matter what it might be. And then you understand all the backend behind it. You gotta become more of a full stack developer though at this point, right? And understand it's end to end. Now, you should learn your language in the case of JavaScript. You should really understand what it means to be a ES25 or ES2016, right? So the ECMAScript. Learn what the base principles are and understand the JavaScript. So going forward, JavaScript is part of everyone's life at this point. Even if you really are a Go programmer or Node programmer, well, I guess a Node programmer is JavaScript. But if you're a Java programmer, like if you're a Java person, we thought we could get away with never looking at JavaScript. But it's just not true anymore. You understand that JavaScript owns a client at this equation at this point. Look at service workers. There's a lot of really cool stuff happening in that space. You can do essentially asynchronous multi-threaded client-side development now. You're not blocking the UI thread on the client side. You can make those requests back to the server in an asynchronous way. What's happening in the world with web components is really, it's been out there for a long time, but people are now really starting to get excited about web components and what you can do. You basically can build your own custom controls for the browser, right? Custom user interface widgets. And you can do that in the standard of web components, but it's a framework that they're called Polymer. And a lot of people are looking at Polymer as a way to eliminate Angular and React, which is pretty crazy, right? They actually think just Polymer, a lightweight solution with JavaScript and custom widgets with its own data-binding mechanism, it's all you need. You don't need all the heavyweight MVC, okay? Which I think it's funny because, MVC came from the server side if you're from Structz and Spring MVC and all that, and now it's client-side, you're like, no, that's too heavy. It's kind of crazy, okay? We're always in search of lightweight stuff. Do you understand, though, you have your mobile device APIs? A lot of people don't realize that with a mobile web now, you have access to things like the flashlight, the battery, the GPS location, vibration. There's almost nothing you can't do with JavaScript and the browser on a mobile device at this point. You don't actually have to build mobile apps any longer, right? The primary win for building a mobile app versus mobile web is you have a store to sell it through. With mobile web, the user has to kind of find it with the browser. With a mobile app, they find it through the store and there you can monetize it more easily, for honestly, but that's really the big win is the ability to find the thing or anything else. The capabilities, for instance, you can do almost anything you wanna do in the browser. If you actually look at last year's keynote demo, we had people play a real-time 60 frames per second balloon popping game, right? We had 10, like if I ran that game with you guys now, this small group of people here could easily get tens of thousands of transactions in and just a minute or two. It's just rapid, right? Here's payment on it, 60 frames per second, all browser-based on a mobile device. It's kind of crazy if you think about that, okay? So progressive web apps are gonna be the new thing. No, so just, we were all about single page apps for a while and the responsive apps. Now we're all about progressive web apps. It's just, we're all the stories changing. Just keep that in mind. There's also CID happening on the JavaScript side. You also wanna push your front ends through a continuous integration solution. You wanna do automated testing. You wanna do everything you do on your back end, but do it on the front end, okay? So we'll keep moving though, because we'll run out of time. There's many more things that are interesting here. So on the back end of your system, if you're a Java person, this thing called DropWizard happened a few years ago. And what DropWizard did is they actually took some of the Java EAPIs, they bound it up with something called Jetty, right? And then with Jetty, they were able to use an embeddable runtime solution. So if you were an early microservices adopter in the case of Java, you probably used DropWizard as an example. And so DropWizard was really the folks who kind of came up with this idea, okay? And you can see right here, but Spring Boot is the kind of new kid on the block that basically took the DropWizard ideas and some of the DropWizard code in some cases, and they've actually made it super popular, okay? So this is the current king of the hill, if you will. It comes to embeddable Java within an effect jar, is how we refer to it, right? You basically roll out the whole application into a single jar file. Rafael will show you this in his demos. And then, you know, Spring Boot seems to be the king of the hill at this point, okay? And this imperative programming model. Then we have Wallfly Swarm, which is the offering from Red Hat that specifically takes the Wallfly application server that's super popular. It used to be known as the J-Ball application server, rips it apart, and then basically it makes that effect jar, okay? So the good news about this model is unlike the original Java EAP specification, you only pay for what you need. You only use what you need. So in other words, the old Java EAP server had the entire specification, all whatever, 30 something specifications, and you know, megabytes, if not gigabytes of stuff on the disk. I guess at this point it's multi gigabytes. I think WebSphere or something like that, it might be even bigger. So you would then deploy your little war file or jar file to it, right? But you might not need all of that technology at all. In this case, the new world is you only bundle in with your application what you need. And here's the cool thing about this. C-Sharp, the new .NET core, works exactly the same way. So everybody's moving to this model of your application only needs certain dependencies, only needs certain run times, only deploy what you need. Don't deploy the world and hope you need it, just deploy what you need. And if you think of this new world where we're going fast, we're building containers, we're shipping them through containers to deliver your pipeline as fast as we possibly can, that's what you want. You want that lightweight type package. You don't want the big, huge thing, okay? Now, my personal favorite here, whatever this pair of messages is, okay, is VertX. So this is what I'm particularly interested in. And we're not gonna have time to spend a lot of time on it or do any demos of it. But the idea behind this, this is a reactive programming runtime, a reactive toolkit for the JVM. Yes, you can do polyglot development, but I mostly stick with Java. Sometimes I do JavaScript. So you can do Ruby or Java or JavaScript or Ruby if you want to with VertX runtime. It's kind of interesting that way. But it allows you to program in a reactive way. And reactive programming actually does work at your head. If you're an old guy like me, right? I always think of when I'm looking at reactive code, I always time my head sideways. And that's due to the fact that if you didn't know JS code, you know, in the case of no JS code, you basically have all these callbacks within callbacks through callbacks. And so that problem, you know, that is kind of the world of reactive programming. You don't call back, call back, call back. There are different solutions to that. In the case of JavaScript, you have promises. In the case of Java, you have futures, you know, completeable futures and you also have arcs, Java, the observable. There's lots of solutions to it. But it is a fundamentally different programming model than the old imperative programming model. Like I learned how to program in Pascal and then C. And it's super simple, right? You read the line and you know that line executes. You read the next line and you know that line comes after the first one. Doesn't necessarily work that way in a reactive world, right? Things are not ordered that way necessarily. And so you have to just keep that in mind when you move to this new world. But this is where the future is going. Because here's the thing. In the imperative programming model, it was super easy to write a little controller in spring ABC or Jaxrs and deal with get, click, post, or delete. That's what we've done for the last several years, get, click, post, or delete. Super simple. And that worked really well. If it's just a click, you know, user click the link, click the link, click the link, hit the submit button, boom, boom. Super simple. In the new world, we're not waiting for users to click links and buttons in the locker. We're actually dealing with streams of data flowing through our systems. There's so much volume of data from all those clicks, if you will, that it's no longer an independent thing, independent transaction. It's actually a stream of data flowing through, whether it be from mobile devices and all the sensor data coming in through there, or actual IoT style sensors, you know, where it'd be a motion sensor, a temperature sensor, something of that nature. Or maybe it's big data analytics and a streaming associated with all of that, right? The data's too voluminous and too fast to even hold on to. We just look at it in real time and then dump it out. You know, we don't even keep it. Those concepts will be much more pervasive as we move forward. So do check out BirdX. There's a lot of capability in it. It is a full platform for building all your favorite web applications, or backend, RESTful capability, or full event-driven style applications sprinkling around a network, has a constant, like, the event bus, allows you to distribute the processing across multiple J&M's, across multiple nodes. It's an incredibly powerful environment and, of course, it is an Eclipse project to be sponsored. Komon is here, as is Thomas, who's not in the room, but there are several sessions on BirdX that I encourage you to go to and check it out. Okay? Really cool stuff there. Well, let's keep going, all right? We're down to the last topic. I moved pretty fast here, didn't I? And I actually don't have a lot to say about this trigger topic, but you couldn't do a state of the union, state of the industry without mentioning it because this is where all the startups are super fired up, right? So this is where Facebook is investing in a huge way. Google is investing in a huge way. Apple, you know, Tesla, all those organizations. Many of them have open sourced their capabilities, so there's all these new open source frameworks that are available to you. The one that's most interesting, probably, at the moment is TensorFlow from the Google guys, and there is a presentation coming up on TensorFlow on a live Sunday. But that is one that's super interesting. But here's a weird part about this to me, right? If you studied AI in school, which I did, I'm actually of the generation where AI was science fiction, truly science fiction, not science fact, right? Some of you are a bit younger. You're like, no, no, we actually live in that stuff. I did, right? Let's put this away. So, there was no object-oriented programming. Not only was it imperative, there was no object-oriented either, right? There was not even object-oriented programming when I started programming. So with that concept, what you'll see in the real world is natural language processing. This is really where the world seems to be happening right now, so if you know about Siri on the iPhone or okay, Google, or what you can do with the Alexa, right, Alexa service from Amazon on an Echo or a Dot, this is where that world is going, and it is absolutely amazing what you can do. You can talk to your software now. And with Alexa, which has a full programming API, you can link talk to the software, okay? Now, for those of you who have been around for a little while, we used to have these mobile prompts you would dial in on a mobile phone, it would say, oh, dial, hit one for your account balance, hit two for do a transfer. You guys seen that before? I did that many years ago, and it was, and basically it was voiceover IP, voice XML, and basically dial tone processing. That was easy. It kind of worked the normal way, if you know what I mean. It's just like get the poster delete, especially with the modern software that was out there at the time. This is probably 12 years ago at this point. But this new world where it'll listen to the various words that you say, including the accents that you have, and still get it right, is nuts, okay? So I encourage you guys to think about this more. It has not really hit the mainstream yet from an enterprise perspective, but people are now starting to talk about it and think about it. And they're starting to understand how this might apply to their world. A lot of people are looking at the Alexa service in particular because that one's a nice full programming API. You can use the host or stuff of Amazon Lambda, AWS Lambda as an example, write those components, write those features, okay? But there is a presentation that I know a gentleman's doing later on, on Sunday, specifically. Or is it Friday? What day is it? It's today. It is today, okay? Eventually I said Sunday, but I actually wrote down Friday. Actually, there is one more on Sunday about Mozilla Beach Beach Project, which also will include some terms of flow. Okay, maybe that's the one I was thinking of when I did this. All right, so that's a lot of ground to cover in a very short period of time. I purposely skipped all the demonstrations and things like that. We'll let Rafael do all his demonstrations. Clamont's got several live coding examples where he'll show you all kinds of cool stuff happening in Vertex. That's normally the things I show. But since Rafael and Clamont are here to present, I decided not to provide those. You guys can see those details in those sessions. We have a moment or two for a question. There are any specific questions or you can simply say, I talk too fast. I understand, but we do not promote you. What kind of questions might you have? Random thoughts. Was this heresy? Someone's going, hell no way of doing that. You can say that to a few. No, this is what happens when you come to check a public. Everyone's so quiet. No, you're not quiet. It's not about the question or other reason that a lot of developers seems to be very distant from the business itself, not understanding what business actually is. And that's probably, you can come with very nice, nice things like the run continuous, deliver continuous integration, all nicely, as you said, usually even good ideas, it's a path to hell. So you can try as much as you want. The moment you experience at least once in your life, a factory shutdown due to your code or someone's house code, life changes. And it doesn't matter what new technologies come, your point of view on business is completely different. I think that's a very good point. If you've not been laid off before, maybe you should be. It teaches you a lot about life to be laid off once or twice. And being laid off is you're not really fired, but you're kind of fired, right? And I actually had that happen to me as a young person when I was only 16. And so therefore I learned that lesson very early in life. It's like, oh, I got fired, but I didn't do anything wrong. So yes, the business matters most and the business decisions matter most. Yes, sir? So with only A-B testing and a lot of stuff in the hypothesis-driven development, one of the biggest problems with that is you have to build all this analytics infrastructure that doesn't directly add value to the business. And so you're saying, well, we want to be business-driven, but to be business-driven, we need this closed feedback loop. How do you get past that thing of we need to build the feedback loop? Here's the crazy thing, if you follow GD as a great example, GD, which is known for its hardware manufacturing and MRI machines and everything else, they will tell you they're now an analytics company. They're a data science company. That's really their purpose for living, even though they're a big manufacturer. So organizations at the CEO level will have to learn that lesson that, oh, IT actually matters. Every company is a software company and even a company that builds locomotives or MRI machines or turbine engines for jet airplanes, they realize we got to do analytics and make that part of our business. So yeah, you can't help the unenlightened CEO, which case, you probably should find a new company. That's how I look at it. And the good news is, as a technologist who has great skills, there's lots of jobs available to you, right? Around the globe, at least at this point. There's lots of jobs available too. Okay, well guys, thank you guys so much for your time. If you have any other questions, see me in the hallway. Otherwise, Sebastian's up next with the Infant Spanish Spring Boot.