 Go ahead and get started. I really appreciate all of you taking the time to come here and join me this afternoon, particularly during the lunch hour. My name is Robert Schimpb, Bob. And I run product management for Oracle's infrastructure products. There's a whole variety of things, but most especially Linux and virtualization. And my personal passion right now happens to be around distributed computing infrastructure. I work with a lot of large companies around distributed computing for automotive systems or for blockchain-style financial services systems and different things of that sort. So what I wanted to do today is give you a broad overview on where things are going with distributed computing and then drive down into some Linux specifics. I will be the first to say that rather than commentary, I suspect by the end I'm going to have a lot more questions than answers about where things are going. But hopefully, this will be useful or interesting for you. At the end, if you stay all the way to the end, we are going to have a giveaway, the UBS charger. So feel free if you stay. You'll be able to pick one of those up from Dave Gilpin in the back of the room. So if you think about cloud computing, broadly speaking, I think most people tend to think of really large, complex system of records type of infrastructure moving up into the public cloud. This is things like ERP systems or supply chain systems, sales and marketing on the front office. And that's a big switch from where we were a few years ago where most people use public clouds for very tactical stuff because they weren't sure about the quality or security or whatever. But nowadays, all these large, complex system of record type of applications are moving into the public cloud, which tends to leave the question, OK, what does that mean for me as a Linux or IT ops person? It's a fact that over the next few years, over the coming years, about 50% of all the corporate data centers, the privately held corporate data centers and large companies are going to go away. And for small or mid-sized businesses, the percentage is going to be dramatically higher. So that leaves, I think, the IT ops person with a couple of choices. Either you're going to go to work for some intergalactic infrastructure provider or you're going to find something else interesting for your company to do. And I think the answer is that there's a lot of very interesting things to do. And in fact, I will make the forecast that no more than one third of the business applications out there are going to run in some giant hyperscale data center in Chicago or wherever. Two thirds of all the business applications are, in fact, going to be distributed computing types of applications that do much, much more interesting things than ERP, including peer-to-peer social and mobile networking applications, a lot of business applications for virtual reality, augmented reality, and then, of course, the whole world of real time control, internet of things, and so on. So the picture isn't as bleak as it might appear. In fact, I would argue that for those who really want to embrace it, there's a tremendous new opportunity to do a lot of interesting things. And that's what I want to kind of talk about. OK. So by way of background here, there are, roughly speaking, 20-some-odd billion devices out there on the edge of the network and intelligent devices. That's going to 80 billion by 2025. It's a very dramatic shift. And there is a lot more intelligence in people's smartphone today. That's going to only increase more and more over the coming years. And that's going to create a lot of computing capacity at the edge of the network to do really, really interesting things. But the flip side of that is that it does stress the internet or network connections, broadly speaking. Most of these types of devices are incredibly chatty. And if you allow them to simply connect up to the hyperscale clouds and do whatever they're doing, it's basically going to bring the internet to its knees over time. So rather than go with that approach, which is going to be incredibly expensive, the idea is to move to distributed applications in which we push the computing capacity, all the data, and the applications as close to the edge of the network as we can and primarily reserve those big hyperscale clouds for the classic system of record application that requires a central database to do a whole bunch of transaction processing and analytics and so on. So the way to sort of think of this is a classic three-tier architecture in which all of your big ERP and so on, OLTP-based applications, decision support, remain up in the hyperscale cloud. At the front end, you've got the front layer. You have actual intelligence in the devices, and they're communicating with each other directly. And then in the middle are smaller distributed clouds that are used for systems of engagement. So my personal view of the world is that everything is not going to go up to Amazon or to Azure or anybody else. And just all your stuff is going to sit there in one or two or three data centers. In fact, I think most IT ops people are going to be actually dealing with hundreds, if not thousands of data centers, maybe very small ones, very small clouds, but distributed globally and locally to their particular application. Now, I particularly want to talk about core infrastructure stuff, but there's a whole bunch of initiatives going on in the industry. You're probably familiar with a lot of these, but there are many, many different types of initiatives to reduce the amount of traffic on the networks in order to make this sort of thing possible. The very first and easiest, simplest one is HTTP2. As most of you may know, we've been running on 1.1 forever. That's gotten very, very old, and now in the last year or so, things have been rolling out to HTTP2, and that allows very simple things like much more data compression, a whole lot of push capabilities, and so on. That's great for reducing HTML-based traffic and so on on the networks, and it's had a real effect, and that's going to continue to roll out more and more and reduce traffic. Another example, however, are next generation 5G communications networks. So the existing 4G networks, the things you use today, and you probably have a lot of experience with this, can be extremely slow. The new 5G networks, which are now in very late testing and are gonna roll out in production over the next couple of years from different vendors, dramatically increases the amount of capacity, certainly thousands of times more bandwidth, and so on than what you would get in 4G networks today, as well as offering tremendous interesting new features for slicing up that bandwidth in different ways so that you can have all kinds of multimodal traffic over those same networks. So there's a lot of creativity that you can start to take advantage of in terms of the types of applications you can deploy based on those 5G networks. So those are two very simple examples broadly across the industry that are improving network traffic, but it's also imperative that companies start to think in terms of distributed architectures, what is the most appropriate approach for the type of application they're gonna run? And I can tell you that these are very interesting and subtle architectural questions depending on the specific applications. In some cases, a hierarchical model where you simply are pushing data out and caches further towards the edge of the network's valuable, some time a leaf and spine approach is really good if in fact the devices at the edge of the network are particularly chatty and they need to have connections to various other random devices on the network. And then finally, architectures like peer to peer that enable many, many different devices to talk directly to one another. And I could go on and on. There are multiple other strategies for distributed computing networks that ultimately can run different types of applications really, really well. By the way, I'm probably gonna blow through this pretty fast so I may be able to give you back some time at the end of this or we can take questions if you'd like. So one of the other networking strategies to reduce overhead is something called Cloudlets. This was, I believe, initially proposed at Carnegie Mellon some years ago and has been steadily being fleshed out over time but basically this is the architectural concept of converging cloud computing and mobile computing into a single device or machine appliance could be a software based appliance that sits in the middle of the network between the intelligent devices and these hyperscale clouds and is designed to maintain soft state around basically for microservices and containers. And this will put your data and your application logic as close as possible to the devices that you're operating with. A classic example of this kind of thing would be in a hospital, they would have a small WAN based network with a Cloudlet in place that would talk to lots of intelligent devices that could be in patient care or surgery and so on. What you find for the telecommunications companies are that many of them are pushing cloud infrastructure very far out to the edge of the network even into the cell phone tower because as you get into the future where you have self-driving cars, two cars going down the road at 65 miles an hour are not going to talk to each other through some hyperscale data center in San Francisco. They're gonna talk to each other directly if they have connections into their manufacturer and so on that's gonna be through a cell phone tower and so on. So you need to have much more computing capacity out towards the edge of the network to do that sort of thing. Okay, so there are numerous ways that you can go about doing this. As I said, you could have actual cloud computing capacity out on the communications network even so far out is actually in the cell phone tower and that's happening today. You can have it in branch offices so I would expect retailers if you're a very large coffee retailer you're gonna put a system, a cloud directly inside the retailing store and you think, well, why would I do that? Well, it's all about engagement with the customer. You want to be able to have the customer that has a smartphone as soon as they walk through the door their orders automatically placed to the coffee machine that the barista's managing. So it produces their favorite coffee before they've even gotten to the cash register and they can take that and go. But it also manages inventory, local inventory point of sale, a whole bunch of the facilities maintenance and so on directly in that store or potentially in that neighborhood. And then finally, of course, you could actually just have software based appliances where you're pushing capacity to various Amazon data centers all around the globe and you're just time slicing maybe using those data centers as a hotel for your particular containers for microservices and so on for some application that you need widely distributed. An example of that might be something like Pokemon Go which is a highly distributed application very geocentric. Now, I mentioned Cloud Lits and the whole sort of putting capacity as close to the edge of the network. There is another strategy Mesh Networks which pushes, takes advantage of the capacity that is actually out there in the edge devices. If you look at your smartphone and where the next couple of generations those devices collectively are tremendously powerful computer. If we took every phone in this room and we're able to network that into a single system what you'd find is we have plenty of capacity to run some very large complex applications. And in fact, we are seeing exactly that that mesh networking is continuing to grow very rapidly and as we move into the 5G networks it's gonna be even bigger. So some of the changes here are specifically around proximal discovery and communications between devices at the edge of the network. There are numerous strategies and industry standards that are being used for these devices. You've got LTE direct types of communication and standards around there, com0, com1 and comM. You've got low power, Wi-Fi, low pan and so on. You've got other types of things like 802.15.4 and ZigBee and all these other home wireless types of capabilities. But essentially all of these different standards all of these strategies boil down to having intelligent devices that can communicate directly to one another from 100 or 200 meters away. So if I needed to do a phone call to somebody say in another part of this hotel that phone call doesn't go through the telephone network. It goes from my phone to their phone. So that dramatically reduces the amount of bandwidth required on the infrastructure if we can do that. And there is just an unbelievable range of possible applications that could be done using that. I'll give one really stupid simple application that sort of illustrates that. Imagine that you go to a concert, a music concert somewhere in a big stadium and if you're as cheap as me you end up in the bleachers somewhere. You don't have a particularly good view. Imagine if you can use your phone to take images of what's going on on the stage but also other people whether they're down in the first row or off to the other side of the stadium they can also be streaming video of what they see from the concert. And imagine all those phones could interconnect so that you could flip through whichever view of the video that you want to see whichever stream that you want to connect to. But it would only be directly between devices that are mesh networked within that stadium. It wouldn't be like this was being broadcast to the universe. It's for the paying audience that came to the show and want to be able to see things. And that's one incredibly simple, stupid example. There are hundreds, thousands. I've certainly come up with many, many use cases with some of our corporate customers around the type of things you could do with this distributed technology. So the essence of this is that with LTE direct types of devices that have the chips inside them are capable of handling this sort of thing. It's incredibly low power, which means that they're turned on all the time. You never turn off your cell phone. And it constantly broadcasts to the universe who you are, what your interests are, things you want to do, people you know or you want to meet. And it allows you to discover all the other devices around you that are broadcasting similar information or metadata so that it has some sense of what's going on around you. And as you move through your environment, it senses where you are, what your motion or direction is, and what's happening all around you. Because it knows your preferences, it can tell you things like this store over here is having a sale on watches and you're interested in buying a watch. You might want to go over and look at the watches they have to offer. Or if you walk into a store, the clerks know automatically or immediately what your interests are. Now, that's kind of a human-centric view of systems of engagement, but it also very directly applies to any other intelligent device. So for example, today I've worked with customers using robotics on the factory floor and other construction type of environments and so on. And they're beginning to instrument all these, the heavy machinery, the trucks, the different pieces of equipment and the buildings themselves to be able to interact, and in particular to know where they're located and where they're going to so that they can improve overall safety and performance and efficiency in a factory or a job site and so on. The devices themselves have preferences, the devices have interests, they need resources and so on. They can communicate both with people and other devices to orchestrate their work that they're doing. So again, some extremely interesting types of applications are possible in virtually every industry that you can think of. I certainly have touched customers in financial services, automotive, agriculture, manufacturing, high-tech manufacturing, IT data centers and so on doing this kind of thing. So just to sort of summarize this first part of this, the basic infrastructure model then is, yes, you use whatever, SAP Oracle, to run these big back office applications, typically giant monolithic, SAS applications, big private clouds that maybe run your own back office and front office applications, but then there's a whole tier of cloudlets that you push out containers full of microservices to run other distributed applications and in fact, software that you're pushing all the way out to the edge of the network to specific intelligent devices that you work with and they interoperate through mesh networking technologies. And this creates tremendously interesting things, but also is incredibly complicated to manage. So you've got the continuous discovery applications, personalized interactions, lots and lots of the distributed control applications. Traffic management is one that's coming to Silicon Valley for sure, quite a bit nowadays. And then in the financial services arena, there's automated transactions and so on using distributed blockchain technologies for import, export types of applications and things of that sort. Okay, so now we get into the next level of detail. Exactly how would you build an application to run in that type of infrastructure? Well, we've got very fortunate timing here as microservices are beginning to mature and the availability of containers has a way to package and deploy and manage those microservices. So we're able to create very small, single purpose services that are very easy to deploy. They have a very small footprint so they'll fit on the thinner infrastructure out towards the edge. And the overall model is that you don't try to patch all this stuff that is sitting in maybe 100,000 cars or smartphones or thousands of cloudlets out at the edge, but instead they're immutable. You just replace them entirely with the next version that you're gonna use. So all you have to do is be able to keep track of where they are and when you wanna upgrade, you just dump all the old ones and replace them with new. And of course, these things can be stored at the edge. They don't have to be actively running because they start up incredibly quickly so that as they're required, they can be booted and providing whatever service you need and then shut down and put off to the side again until the next time you need them. So if you try to think of this environment, you've got incredible range of container-based services talking to each other, very small, very light. They're very ephemeral, they come and go as needed and provide the services required. Now microservices themselves are definitely designed for distributed computing. And I don't wanna oversell microservices, they are very complicated. A lot of people think for some odd reason that monolithic applications are kinda equals legacy or something and that's idiotic. Monolithic applications have tremendous advantages in their own way in terms of overall ability to maintain them and to upgrade them and so on. But microservices are far, far better in a distributed computing type of environment. So each man to his trade, if you will, monolithic applications for SaaS in a hyperscale cloud make tons of sense and microservices in a hyperscale cloud can also make sense but they're really very well optimized for a distributed environment. So each microservice because it should be independent of or not dependent on any other microservice has its own data store and that's what causes this need for coordination between the microservices and fundamentally things like REST and HTTP are too slow for microservices to communicate with each other. You basically want an in-memory model if you can do it, something like coherence where you have a memory bus and everything is talking at very, very high speeds in memory. You wanna reduce that overall latency because there's already inherent in the fact that it's a distributed set of services. There's gonna be a lot of latency in those types of applications. So now we get to Eric Brewer's CAP Theorem and this is the fundamental computer science problem that we face and that is that you can have consistency availability and partition tolerance but it's near impossible to have all three at the same time. This is something I'm sure you've heard many times before. I personally don't believe that this is a theorem. It's never been actually mathematically proven to the best of my knowledge and in fact I think there are particular cases where they actually, it can be all three but let's just say for purposes today that all mainstream mundane sort of applications you have to make this trade off. So typically for a big system of record or enterprise IT system, consistency is the most important thing you can do. For distributed application where eventual consistency can be perfectly reasonable, you're basically gonna try to focus on availability more than anything else. And then partition tolerance is a given that you have to have that because in a distributed computing environment you cannot design an architecture that assumes all networks will always be up and available. It just isn't gonna happen. So you take P off the table, you're basically down to a choice of what level of consistency you require and then what level of availability you require and what's the trade off you're gonna make in these distributed environments. Okay. So I said containers are the primary deployment model that we're all in this industry looking at as the way to deliver these distributed computing applications. There are tremendous advantages to containers. They do not, in my opinion, replace VMs. VMs have their own special role in the world and those are gonna continue for a very, very long time. But containers definitely provide developers with a much easier, faster way to put microservices together and to integrate and package everything up and then send it out very cheaply, deploy and destroy whatever you don't use and then replace with something new. For administrators, containers mean you know exactly what the microservice is running, what all the environmentals are that it has. You can keep track of where it's going. You can optimize the overall performance and throughput of these systems and so on. So containers look very attractive from both sides and as far as I can see, they're gonna continue to be extremely popular, extremely important as we move into the next generation of applications. One of the tricks to all this, of course, is that when you're talking about building a large, complex microservices-based application with a whole bunch of containers and then deploy that very broadly geographically, let's say even around the globe, you're talking about an awful lot of containers and then you pile that up over time. If you think that there was a crazy overuse of VMs and that they just spiraled out of control, well containers are gonna go an order of magnitude worse in terms of the sheer volume of these things that are gonna be deployed. You need to have a core infrastructure in place that enables the developers to do their thing, dev and test and provide a staging area, delivery model, the whole set of management tools around that that allows you to properly maintain the entire application life cycle because as you push this stuff out, it's out in the wild now, it's gonna be out in the world. In the case of automobiles, containers are very attractive because if you've got a system or a service that must be fail-safe, well you don't really wanna be doing patching on that application out in the field on cars. It's an iffy proposition in the first place and you may not even be able to attach to every car in a timely fashion to do patches and so on. Containers are nice because you're basically gonna flush the entire service or set of services and just replace all new with a new container on that automobile and that's to me a much safer, saner way to go about putting fail-safe types of applications on heavy machinery. But it also applies to every other type of device you can imagine out there and in various cloudlets that may be scattered around the world. Now, that doesn't mean that containers don't have their issues. Containers really still are fairly immature and it's gonna take a couple more years of work to make this all come together, not the least of which are things like how do I build these things in a high volume production environment? How do I do debugging of containers to understand what's going on inside them? There's a lot of questions around security. I think there's a whole presentation or set of maybe a couple sessions on container security going on here this week. And then a lot of new questions about management tools because most customers I know don't wanna take on a whole new set of management tools just for this type of deployment. So over time, all this stuff is gonna get worked out and things will smooth out but for now, there's still a lot of questions about how would you actually use containers embedded in intelligent devices that may be tens of thousands or millions of devices out there or hundreds or thousands of cloudlets that may be scattered everywhere. So for me, this boils down to four big topics that you wanna think about when you think about how would I build out this infrastructure. The first is to provide the actual immutable infrastructure for the containers in the first place. Second is ensuring that you can have application portability because I guarantee you this infrastructure is gonna be incredibly dynamic. It's gonna evolve very, very rapidly all the time and what you have six months from now is not gonna necessarily look like what you have today. And for every type of distributed application, there's gonna be variations on how you want the architecture set up and so on as I mentioned earlier. And then you need to manage the whole life cycle. So how are you going to deal with building and publishing and orchestrating and so on all of these different container-based applications built with all these different microservices and then how do you secure that entire infrastructure? Now I'm not gonna say that I can, I'm gonna stand up here in the next 15 minutes and give you all the answers to this because I can tell you we're struggling ourselves as we work with our biggest customers around the world on how are we gonna really build this out to do very sophisticated kinds of things. But let me make a few observations that may be worth noting. The first is around the immutable infrastructure. By this I mean the actual immutable OS and so on that you're gonna have throughout the network. You need to have an OS that is very small footprint for a couple of reasons. You're not gonna have as many resources at the edge of the network to run this stuff. So the tighter, smaller that you can make it, the better you're gonna be, off you're gonna be. And of course the fewer packages that you have in that OS and so on, the more secure it's gonna be. And since you have less direct control, physical control over those systems necessarily, you wanna have the highest security you can get. And then finally of course, that OS has to be small enough, easy enough that you can just throw it away and replace it with a new version very, very quickly and get it up and running. So getting the right host image for those containers is step one in my opinion for understanding how you're gonna build this architecture. Now, I took this from, what is it, InnoVex, Vex is a company I just saw this article online and this is from May of last year. But I think the numbers are probably in the ballpark of being correct from my experience. There are a ton of different micro OS's that you might choose from. And they do vary significantly in size but size is not the only consideration here. So I would quickly note that some of the larger ones actually have more security features built in than the smaller ones. So there's some trade offs here. You need to think, look at these kinds of things a little bit more closely before you decide which one's the most appropriate for your needs. But I will say that on a purely philosophical basis, I really like the Rancher OS because it's container-based and everything it builds is based on containers in the user space and so on. So to my mind, it's a very pure kind of design but I think there's a lot to be said for many of these other, certainly core OS is very popular and so on. And one of the areas that I just wanna quickly mention is, okay, so you pick an OS, how exactly is it upgraded out there at the edge of the network? And it's interesting all these different vendors have different strategies that they're deploying. Atomic uses just a whole new directory structure and you just update that and you can roll back if you need to and so on. Core OS uses two partitions, an active and a passive partition so that you update the passive partition, make it the active partition and then your formerly active partition becomes passive for some reason you need to roll back, you can shut down the active one and go back to the passive one, sort of roll back to where you were. And then Rancher OS, as I mentioned, because it's a pure Docker container construct, if you will, it basically just has a very small system Docker container that can be easily replaced and then you can upgrade all the other containers in the OS. So using Docker commands and so on. So there are numerous different strategies being thought about by different vendors. These aren't all of them, there's other choices. I don't know how this is all gonna evolve over time, again for me personally from a philosophical viewpoint, I like the Rancher OS idea but the others are totally valid ideas too. Now in terms of application portability, broadly speaking containers were designed to try to be portable, that is core to the philosophy of Docker and all the other container options out there. The open container initiative is very broad based, has very strong support from everybody in the industry so I'm personally pretty optimistic that containers will continue to be relatively portable over time. I will say some of the vendors who make containers are doing their best to try to put a mode around their value add or their IP and that always creates some problems but broadly speaking I think we're gonna see very good application portability with containers. And then earlier I alluded to the security challenges for containers, again the philosophy here is you do not patch, you replace software but who is the gatekeeper, who makes those decisions on what will be done, you have to make sure that you set these policies early in your IT environment. Is it going to be the development team or the operations team? Quite often the operations team wants to move faster than the developers on security issues, at least that's what I find in my day to day. And so you've got to have a strategy going in before you start production deployments of all this stuff because it definitely becomes an issue. And you have to make sure you have the right tools in place to understand whether you're compliant, whether the containers have maintained compliancy with ever changing security regulations in your business or policies in your business and then what do you do, what is the risk? Very different for say companies that are embedding a container and intelligent device that's a big piece of machinery, a robot or something like that than if it's just in a smartphone. We also have been going back and forth a lot of discussions around whether hot patching, do you think of K-Patch or K-Splice or some of these other things, is that technology relevant anymore in this new distributed world? And while certainly we do want to have this immutable model where you simply throw away containers and so on, I do think for micro OS is that there's going to continue to be a place for hot patching OSs out on the distributed network for security reasons. Again, this remains to be seen over time but I think that this will end up being something that we need to maintain. Okay, so ultimately the mindset does have to shift for Linux administrators or other IT ops people that doesn't matter what type of failure happens out there in the distributed environment, you do not attempt to patch hundreds or thousands of systems out there where you can't even get at them. If there's a hardware failure, use auto scaling to move on to the other machines. There's network failure similarly. If you've got system software failures, just replace the OS. If you've got an application software failure, replace the container, just replace everything as you go over time. You gotta design or architect that application with that kind of mindset because once you have this stuff out there in the world, there's no way you're gonna be able to fix it on the fly. In terms of management, I do just generally want to endorse OpenStack. I think it was Rich Bo and I was speaking here in the prior session on OpenStack.org. These guys are doing great stuff. In my opinion, it's still very immature. A couple more years, it'll be much better, but it has a lot of interesting projects and potential with Magnum and Triple O and some of these other things where you can, where we'll soon be able to handle a lot more of these distributed environments and I think OpenStack's gonna be a very, very good choice over the long haul for distributed applications. Yeah, so the OpenStack community through the Magnum project has a lot going on to integrate with the various orchestration engines and so on like Kubernetes and Swarm so that you'll be able to have a common infrastructure where you can see and manage both the hardware, the systems, the networks, as well as all of the containers and the application infrastructure, the microservices and so on behind that. I think that's gonna be fantastic. So in closing, I just wanna say a huge proportion, 80% plus of all of the companies out there are moving to a hybrid cloud infrastructure. Fundamentally, that's the first step towards a distributed computing architecture. I believe that there is a tremendous amount of work to be done before companies are really ready for large scale production, distributed applications that take full advantage of all the things that 5G networks and the global cloud infrastructure can provide them. What I would recommend is first, you need to have executive recognition that there is a whole new class of distributed applications out there that harness intelligent devices to do really cool things for engaging customers and consumers and users and just make them understand the business value and that there's a technology shift that needs to be made. The second thing is, and I find this with a lot of customers, they do not put in place a mature DevOps model before they start leaping forward into other stuff. I think the DevOps piece is really hard to do well and is critical to have in place before you attempt much else. And then examine the business processes in your company. What would you like to re-architect? What types of applications you have that would be amenable to a distributed environment that would do something new and interesting for your business and begin that to plan how you're gonna take each business process and implement distributed strategy to that. So those are my recommendations on next steps and that is it. I'm saving you five minutes here. I guess I'm happy to take questions if there is anything of general interest. Okay, well, I'm not gonna take up people's time. I'll be here for a few more minutes and then feel free to ask me or you can email me too after the fact. Thank you.