 Well, I'm Brian Grace Lee, and on this Wikibon whiteboards, we're going to talk about really the evolution of what's happening for applications. For a lot of people, you're hearing a lot of buzzwords in the marketplace today. You're hearing Platform 3, you're hearing cloud-native applications, you're hearing modern applications. And if you've been in IT for a long time, people are calling some of the things that you do day to day, legacy applications. Well, let's talk a little bit about why we're hearing about these different types of applications. More importantly, let's dive a little bit into the technology behind today's applications and what's sort of driving the future, and then understand why they do the reason and why they do what they do. So, let's start from the context of where we are today. We're going to start with whether you have a custom-developed application or you're using a vendor-provided application. So you may have developed a custom application in Java or .NET, maybe you're deploying an Oracle, an SAP, a Microsoft application. Your typical model is, I have an application that's going to drive something for the business, something probably critical for the business. I need dependability, I need known performance, and for the most part, I'm probably not going to update it all that frequently. Maybe once a year, once every six months, is pretty frequently in that environment. And again, it's for your stable system of information types of applications, your ERP systems, your CRM systems, your point-of-sale systems, you don't want them to go down. So your typical environment will look like, your application will come in somewhere, whether it's custom-developed or it's from a vendor, you're going to test it, you're going to take as long as you need to validate that environment, and then at some point, you're going to push it into production. And if you look at this picture, it would go from development, sort of falls down to test after a period of time, will fall down into production and then get deployed to your infrastructure. And just like this picture shows, this is a methodology that's called Waterfall and looks like a waterfall. The whole purpose behind this is stability, known time that you're going to deploy them, you know the frequency of updates. And from an infrastructure perspective, what I'm typically going to do is I'm deploying those on virtual machines or very large UNIX machines, but more so these days, virtual machines onto a highly available network, typically a network storage types of a device, whether that's a SAN or NFS, and all this is going to be highly available. The infrastructure itself is highly available. The reason you want that is when you're doing application deployments that take a long time to deploy, you want to know stability, you don't want this to be an unknown, you want it to be a known sort of environment. And so that's why we've built so much resiliency and redundancy into our infrastructure to manage those applications that you just can't have go down, and the applications themselves expect that resiliency to be built into the infrastructure. So that's a lot of what we do today, it's a lot of the applications we have today. Now what's happening is more and more we're seeing with real time analytics, with mobile devices, with the markets changing as quickly as they are, whether you're in financial services, transportation, healthcare, whatever industry it might be, we're seeing parts of the business that just have to go faster. And when you have to go faster and software is going to be a core element of that, technology is going to be a core element, you've got to rethink your mindset in terms of applications. If I'm dealing with mobile applications, those updates could be every week, could be every month, but it's definitely not going to be every six months or every year. You may want to have updates to your website where your competitor added a new feature and it's differentiating them, you've got to get a new feature, a new button, a new video frame into your application quickly. So we've got to be able to have an environment that goes faster and is expecting change more frequently. So that's typically called agile. What agile really means is in order to do things more frequently and have a level of quality that it's expected is I'm going to have to include automation. Automation becomes a critical element. Now that doesn't mean I can't automate a lot of the things that are in here, but because of the time frame it's not a priority. Now what tends to happen in these environments is we see more custom development, more people building their own applications. That development throughout the life cycle, and this could be one part of a build, another part of a build, that new feature that's coming along. I'm pushing those down into automated systems. And by automated systems what we mean is it's going to take it, it's going to run a set of automated tests. So we're not just handing it off to another group. We're going to try and automate the test as much as possible. We're going to try and build a feedback loop that's telling development throughout this whole process. Did it pass? Is it ready to move to the next stage? And it could be just that much amount of code, but frequent updates, frequent updates, frequent test, frequent updates. And then as we move through this automation cycle, which in a lot of cases it's called continuous integration or continuous deployment. Sometimes you'll see it hyphenated as CICD. Then we're going to start pushing things into production. And what's different here is this tended to be a huge application pushed one time into production. In these environments, we're talking about pushing multiple times to production on a regular basis. And one of the things that we have to keep in mind in these new environments is the only way this is going to happen, as opposed to here, is I'm going to have to start building my applications to be much more modular. I can't build large monolithic applications. Because if I'm going to make these deployments on a frequent basis and frequency, again, could be multiple times a day, multiple times a week, I really want to only update that part of the application. And I need to make sure that just updating that part won't break the whole thing. So you start to think about what was my goal here? Stability, critical systems can never go down, but not a lot of change. These systems, much more change. I've got to build them much more modular. And throughout the process, I've got to be thinking constant changes, constant testing, constantly pushing things, constantly getting feedback and updates. And then from an infrastructure perspective, we're not so much deploying to thinking about individual machines. We're really thinking about a platform. And this is where we talk about terminology like platform as a service or more platform-centric automated environments. The difference here is these platforms are going to provide a number of integrated services, load balancing services, queuing services, clustering services, in software for those applications. And because that application platform is much more robust, much more intelligent than some of these systems over here, because they're built for resiliency. This is built more for speed and flexibility. The underlying infrastructure, more so for all of these platforms, is being driven by containers. And so we start to think about the buzzwords that we're hearing in our industry. Well, we're hearing about containers. Containers tend to be associated with more modern, agile types of applications. We hear about DevOps. Well, DevOps is really this idea that the development and operations, or testing and ongoing operations, is going to be more automated. They're going to be more tightly bound together, because I have to be thinking about frequent and constant updates. And then we're talking about platforms and platforms as a service. And the ability to say, I'm going to let the underlying infrastructure help me scale things out. I'm going to understand that I'm trying to reduce the cost here, because I'm putting my dollars and investment into the application and so forth. And so what we're going to see is we're going to see not that this is bad and old and it all just goes away and this is good and new and this is where you should move to, but it's really an understanding of what is it for my business? What is it driving? Is it driving stability and productivity? Is it driving business differentiation? And do I have the right type of system in place and the right technology, the right organizational model to make that work? So hopefully that makes sense for you, helps you understand what's today's deployment models, going forward with the deployment models will look like. Hopefully you understand that. Much more information on that with all of our research and information on wikibon.com. If you have any questions or feedback, feel free to send it to us either for the video. You can send it to us on Twitter. My Twitter is at begracely or you can send it to at wikibon on Twitter as well. So thank you for watching and we look forward to more whiteboard videos from wikibon coming forward. Thank you.