We're close enough to the top of the hour. If that's, yay, we're live. Hello, everybody. My name is Rob Hirschfeld. And we're going to have a really fun discussion today about open infrastructure and how it's any infrastructure. I've been in OpenStack for a long, long time. I was one of the founding board members. I served four years on the board. I've been to every summit. So I've seen OpenStack for a long time. And really embraced fully the idea that we needed open source infrastructure and open cloud. And then as I progressed through this journey, I really started seeing that when people outside of our community are consuming cloud infrastructure, they're not as concerned about whether you used open source software or not. They consider Amazon just as open as OpenStack. They consider Google just as open as OpenStack because they have APIs. They can consume it. And there's a lot more open source activity actually around Amazon than there is around OpenStack. That might be heresy in this crowd. It hopefully isn't, because I think we need to actually understand the communities that we're involved in and how they want to consume what we're doing. That's more of a preamble. My background, I'm the CEO of a startup called Rack N. And we run a project called Digital Rebar. Two generations ago, it was called Crowbar, if you know some of our history. And we really focus on helping people run cloud and physical infrastructure in a hybrid way. And so for this talk, I had a very straightforward goal.  But our goal was to run a reference workload. We're doing a lot with Kubernetes right now because we think it's interesting and a really strong community forming around that. We love these open community processes. But we want to be able to run Kubernetes on any infrastructure with the same operational process. So I want to get out of this whole idea that it matters if I run on Google or Amazon or OpenStack or Metal or Packet or any of these other places. I want to be able to run Kubernetes and have a conversation about somebody who's running on a different infrastructure and not have that get in the way of is it scalable and upgradeable and secure and the real operational concerns. And so what I want to be able to do and what I'll show right now is we're going to run Kubernetes on three different infrastructures. I'm running, I'll explain how I'm using Metal. And I'm going to have three different software to find networking choices. And I'm not going to switch the operating systems in this case just for simplicity, but actually have a nine, this is in this case a nine by nine test grid of options for this. And I'm also going to demonstrate something else which I'll have as sort of a research point if you were in the last session, this will be a really nice tie in. But I actually did work in advance of this running on multiple open stacks. So my goal originally was to run on six different open stack clouds and new Kubernetes across six different open stacks. So that's my demo one. I'm actually going to jump into that and show you. So here I have a command line. And I'll show you the UI behind all this stuff. But I have just an open stack script. And what this is going to do, those are correct. I've already run this script to create the providers. But it's going to tell our infrastructure to, let me show you what it looks like. This digital rebar is the project that's doing this coordination, rebar.digital if you want more information. And on this system, what I've done is it's gone in and it's spun up requests to build, request a server from five different open stack clouds. So it created, it uploaded my credentials. That was those 404s, I was trying to upload credentials. They're already there. Five different infrastructures. I have hidden the names to protect the innocent, to protect the guilty. So you won't know which cloud infrastructures we have. Because I'll tell you four of the five aren't going to actually complete the deployment. And we'll talk about why. So I'm literally using the tool to spin up these five VMs on five different infrastructures. And digital rebar is going to take those. And it's going to send those out to five different infrastructure limitations. So that's goal one. And that's demo number one. And we're going to let that spin a little bit. The one I do identify as Dreamhost. Because what I found was Dreamhost worked incredibly consistently in their new Dream compute. And we'll talk about why. I call them out. And I think that what they've done is really important. They'll become very clear as I go through the talk. So this is actually going through and spinning up these cloud infrastructures. And then back on the talk side, goal number two is this multi Kubernetes deployment. So we're going to take the same Kubernetes automation based on an Ansible playbook called Kube Spray. It's one of the community-maintained Ansible playbooks. And we're going to deploy that against three different targets. And what that looks like is this. Actually, I'll show you what the, so there's, I'm not going to show you all the parameters, but there's a helpline that would show you tons and tons of options and variables in these Kubernetes playbooks. So in this one, I have an AWS provider. So here's my Kubernetes workload. I'm just using my administrative API. I'm saying use AWS, name the deployment AWS, and use Flannel as my networking. So that's my AWS infrastructure going up. In this line, I have the exact same line, except instead of using AWS, I've told it use Google. I'm going to name that deployment Google. And I'm going to use Calico for my networking. So these are different SDN capabilities. Calico's here. Juniper, I'm going to show Contrail next. OpenContrail, I'm going to run on the OpenStack deployment. OpenContrail's a little bit more sophisticated. They're supported by Juniper. They're also here. And it'll actually set up a dedicated node to run the Contrail workload. So it'll actually bring in an extra machine for that. All right. So basically what's happening in this case is it's going through, and it's going to talk to our infrastructure and going to request machines from these three different cloud providers, and then build all of the roles and associated pieces and permutations to build a Kubernetes deployment. And I'll go through that. I'm going to check back in and out as we go. But I love doing a demo for this, and then we'll talk about what the demo means from that perspective. So if I go to demo server one, you'll see there's a lot of activity going in here. It's not as simple as just the five nodes I built. So this deployment request, there's four nodes in each Kubernetes deployment, five, and then one that uses Contrail. So we just spun up 8 plus 9 to 8 plus 5, 9, 13. And I already had a working Kubernetes deployment going. So we're watching this stuff come in. It's going to automatically allocate off of these different cloud providers.  This is competitive cloud infrastructures. So I'm spinning up machines in Google. I'm spinning up machines in Amazon. So here's my instances coming up in Amazon. And here's my machines coming up in Dreamhost. So down here it's actually bringing up these different deployments. And so that'll come through and spin, actually allocates the nodes and brings them through the whole process. And we'll jump back into this, and we'll show it, and I can talk more about how this works and things like that. Makes sense so far? I know I'm going super fast because I'm trying to kick off the demo, but it's a one line command demo. So it's not much to do. Back to talk. So what I'm demonstrating for you and the purpose of demonstrating this is hybrid. The business value, the thing that people should care about here, is not that I'm installing Kubernetes and I'm doing all this stuff. You can take your time. You can see demos of how this product works and watch how digital rebar actually orchestrates and composable ops, things like that. We'll talk about the values. But what we're really trying to say here is that we're talking about hybrid. And it's not just one thing for hybrid. Hybrid is about multiple cloud platforms. It's about multiple dev tools. We did samples before. Everybody uses Amazon, but some people use other things. We have Chef, Puppet, Ansible. We have different operating systems. We have a lot of different things that we have to consider when we talk about hybrid. So it's not just, hey, I want to use two clouds. I actually want people to mix and match tools because what we really want to do is drive a community. It's very disruptive to operational improvement if I get mad because you're using Ubuntu and I'm using Decentos and now we can't actually compare operational things. So we have to find ways to abstract those differences. And that makes us use infrastructure in a changed, tolerant way because you might decide to switch from Ubuntu to Decentos and you don't want that to break everything you've done. Or you might want to move from Amazon to Google, and that shouldn't break everything you've done, or use them both. And the reality is, and this is an IDC number, I think, is wildly low. But two-thirds of enterprises are hybrid. Most enterprises is a Gartner number. Most enterprises are using two dozen cloud services from nine different providers. So this is what people's IT environment looks like. And I think they didn't even factor in their own internal infrastructure as hybrid. And this is the use case that we're hearing from people. They want to be able to move back and forth. They don't want to be locked into VMware. They don't want to be locked into OpenStack. They don't want to be locked into anything. And the extent to which OpenStack will succeed is the extent to which we create portability between cloud providers, between OpenStack cloud providers, and between competitive cloud providers. Portability is the most important thing from an OpenStack adoption perspective to me. That's why I was chair of the deaf court committee for the whole time. I just gave up that long-suffering task to two very qualified individuals. So obviously, the answer is one ring. We need one API to rule them all. No, yes, no. I'm not making a randy bias suggestion here about EC2 APIs. Actually, my experience of this tells you that API is really not that much of a factor. We use different APIs. I don't expect Google and Amazon to converge their APIs. Not going to happen. And so no API wins. And I use this slide a lot when I talk about what we do. I think it's very helpful. We have orchestration at the top. But the thing that I want to call your attention to here is that it's a decomposed architecture. So every time we hit a new infrastructure, there are different operational needs at each one. There's a lot of overlap. I like to describe it as an 80-20 rule. 80% of the things are the same. But those 20% differences don't all happen in one nice little layer at the end. They're all spread throughout. You do a couple of steps, and then you stop, and you have to do something that's unique to that infrastructure. Physical happens all the time. That's why we started on physical. But it still happens on Amazon, and Google, and OpenStack. You have to be able to have your deployment, which is 80% the same as one on another platform, account for the 20% differences that are interspersed, like raisins in your pudding. So this is what the world looks like. The contrary to Boris's perception, when I'm talking to people, when people are using cloud, it's Amazon. In this room, everybody is multi-cloud. It's Amazon and something else. And so when you look at the market, if you are not working with Amazon, you are not working in cloud. Now, that might sound harsh, but if you're a product company, and it says vendors at the top of this, if you're a vendor and you're not selling into Amazon, you have limited your market to effectively zero. I know the OpenStack vendors on the floor here might disagree with that, because they're happily selling you into this market. But if they were OpenStack and Amazon, their market would be 99 times larger. That's the way cloud is right now. That's the way we approach things. So you can't overlook the statistics.  And if you look at this from the IT user's perspective, they have a very different perspective. They don't see Amazon as huge. But they do see it as the main thing that's eating their lunch. When they're dealing with shadow IT and IT transformation, most of it goes to Amazon. Most of the vendors they're talking to are Amazon vendors, and that's where they're going to direct them. But they also look at it and say, well, what are my alternatives? Enterprises want multiple vendors in their mix. They want to have alternatives. They want to be able to have business continuity plans. And so they're looking for alternate public vendors. They're looking for vendor relationships that they have. I'll spotlight IBM here. IBM has deep relationships with a lot of people in market, and they have a lot of different cloud offerings. So they can help people get to Amazon, but then they can offer them off-ramps from Amazon based on their relationship. So relationships are important. And of course, with OpenStack, private cloud is a very serious thing. So Amazon's already there. People are looking for ways to control, have internal control, or cost management, or security. And so they want to come back into private cloud and make that an option. And the highlight here is that all of these things are really about portability, choice, moving things back and forth. If we don't do this, it just becomes an Amazon eats the world market. And you wouldn't be sitting in this room if you thought that was the right exit for data center IT. And what that means is we need beneficial diversity. Hybrid is hard because everything is a little bit different. And the thing that I want to convey here is that that's not bad. It's actually very good. You're an open source community. Diversity is the key to strengthen that community. And it's the key to strengthen even in operations, but it just makes it harder. We have to deal with beneficial diversity. And the number one thing to do when you consider that is that these choices aren't wrong. So one of the things that we do as a company that we do when we talk to people is we don't start with, we have the right way to do this. And your way is wrong. Most people I know who are running data centers, those data centers run. They deploy servers. They get things done. They don't do it as efficiently as they want. They might not do it in all the choices. They might not love what they're doing, but it works. And they do it that way for a reason. And so walking in and telling them that they can't deploy OpenStack or they're doing it.  Those are the wrong messages. What we really want to be able to do is we want to work, especially in hybrid, with an acknowledgement that different choices that people have made are that way for a reason. And work with them on that. And then the beauty of hybrid is now you're giving people an exit path. That same portability that enables us to talk about hybrid gives us an exit path so that people can give up their bad habits. If you want to stop smoking, you want to start chewing the gum a little bit and get off of the habit before you give up nicotine altogether. Cloud native applications are like going cold turkey. And we already know it's very hard for our companies to do that. So I'm going to pause again for a second. I'm going to jump back to demo and look. Because I'm going to talk about what happened when I started doing some of this hybrid work. It'll be helpful to show you what that looks like. All right. So this is the Kubernetes multi-deployment that's been going on. And what you'll see here is I have a whole bunch of nodes from a whole bunch of different providers. You can see the providers down over here. And the ones that came in from other infrastructures, I might have gone over my quota for this second OpenStack deployment. So my OpenStack ones are here. My Google ones are here. When it came through the system, I got an IP address. And then what we've done is we've built all of these different deployments. And so if I want to pick on, I'll pick demo one. This one's already completed. All right, hold on. Let me step back. So this screen shows you basically how we've brought systems up into a common workable state before we deploy Kubernetes. So in this case, I have all the nodes I've brought into the system. And what's gone on here is that all of these infrastructures, I have certain steps that I take to make the node what we call ready state or available for the next level of deployment. If I'd done this on metal, I would have added about 15 extra steps. And so it takes it through this process of inventorying and getting it on the system and things like that. And then it puts them into scope boundaries called deployments. And those deployments, actually, I'm going to switch and show you the Amazon one. So what it's doing is it actually puts them into a scope boundary. And it says, well, each one of these systems has different roles. In this case, we're just using the Ansible Playbook. So we fed a whole bunch of data into the Ansible Playbook. And then we're running this Playbook. If you're used to something like Ansible Tower, we're just running a multi-node Playbook to accomplish this. The thing that's really fun to me is that I didn't have to build an inventory file. It dynamically assembled all the information that I needed to make things go. I'm happy to talk, especially in Q&A, about I'm powering through this, so we'll have plenty of time for Q&A. But I'm happy to talk through about how we would actually take this community Playbook and break it into pieces to make it more sustainable and upgradeable. Those are really fun Q&A conversations. But this is the key idea. We're taking this infrastructure. And we're actually running this infrastructure through a common set of steps, even though they've come from different places. And so when you think about how do I make a hybrid operational step work, what you want to do is you want to create isolation between the layers. I'm going to talk about that a little bit more and why we do it like that. But this is that demo proceeding. If I jump over to my OpenStack demo, what you'll see in this case is of the clouds, I'm in different states. It looks like they definitely exhausted my quota at DreamHouse. But what's happened is that some of my cloud providers got different levels through the implementation. In this case, I actually got an external address. But I wasn't able to complete my automation for it. And I can look at those things and see what the deployment issues were and come through and troubleshoot what's going on. In this case, there's a permission denied issue. I couldn't actually log into the system. I'm actually going to go through some detail on this. The reason I want to show you what's going on is, for me, especially with this type of talk, it's important for you to see that this is the type of work you can repeat yourself. You can go through this process. You can say, look, I actually want to be able to try and replicate hybrid operations. I want to use Amazon and Google together. I want to be able to try in different OpenStack environments. And then ultimately, I want to find out ways that I can help my OpenStack environments create consistency, which brings back this question.  Otherwise it wouldn't have even shown up on that list. VMs were able to create. The networks were able to attach. My keys were uploaded. What happened? Why did I not succeed in finishing those deployments? And it looks like this. And it's worth noting, no cloud that I tested for OpenStack was successful in deployment. Even my favorite here, Dreamhost, I needed information that was not included in the OpenStack.rc file, that file you downloaded that has your configuration settings in it. And none of them had something perfectly consistent. Some of the things I could cope with really easily will walk through that. The number one challenge that OpenStack clouds have from a cloud consumption perspective, remember my test is Amazon. If it works like that in Amazon, remember the big graph, everybody's going Amazon first and then coming back, we need to be very Amazon compatible. So Amazon gives me an external IP address, only one of the clouds I tested gave me an external IP address. And I'm going to come back and stress, it's not wrong. It's different from Amazon. And that difference from Amazon is frustrating from a user experience perspective. Complete configurations. I had systems that were delivered to me in places where I couldn't actually sudo into the system. Actually, I have a blog post I published today about exactly what our steps are for this automation and what we expect to be able to do. But sudoing, definitely one of the things I expect to be able to do. And then we create a root account and disable password logins. I want to be able to get a standard operating system. I expect CentOS to be on a cloud that I consume. We need to have certain safe defaults. I should be able to always get a Muntu and CentOS and consider us as OSs. And you could make the argument, hey, I can upload anything I want. But I'll tell you, all the public clouds offer a significant library of default operating systems. Very easy. I don't have to think about it in order to start using their cloud. Network names. This was significantly problematic. I have examples where the external network is called private. The network named external is actually not allowed for me to be used. I can't use it because it's a protected network. But I can see it. And so we end up with these very frustrating experiences where, since I don't know what networks to use by default, there's no easy way for me to figure that out sort of experimentation. It's a very frustrating experience. And then log-ins are very different. And this is actually true. If you've used Amazon, Amazon creates their own user account and you have Amazon, so everybody knows that. But it's not root. It's not CentOS or Ubuntu. It's AWS user. And so needing to have to understand what account I use to log in, and I have to log into a machine before I find that out, it's frustrating. So those things, those details really break hybridization. That means every time I step up to a new OpenStack cloud and try and run the automation, if you're going to use Digital Rebar to automate against OpenStack, you're going to have to come in and figure out the answers to these questions on the cloud that you're going to try and use. So why is this a problem? This goes back to a lesson that my team learned at Dell when we were first building Crowbar and even before that. When you're going to set up a cloud, this is really a cloud user audience, but when you're building a cloud, you have OpenStack software. It works. There should be no doubt in your mind OpenStack software works. Hardware is pretty easy to acquire, and it's pretty standard. OpenStack reference architectures are well enough understood. You can go buy reasonable gear for OpenStack and be 100% confident it's going to work. The reason we have these challenges is because a significant component of the work done is ops. It's not the OpenStack software. It's not the hardware. It's the ops. And the choices that people make in ops end up having dramatic impacts in their ability to be successful. And the thing to realize, going back to the earlier picture about your ops is not wrong, is that there is no one ops. Oh boy, that was bad. There is no one way to do ops to actually be successful. There's no cookie-cutter recipe because everybody's operational environment already exists. It's already working. And somebody's correct monitoring solution, or IP ranges, or network topology, is not going to match somebody else's. Now we're back to our 20% differences. The snowflakes really cost a lot of time and challenge. This is really where OpenStack doesn't address this problem. It walks into this problem and then suffers as a consequence. And so when we look at this, we're starting to talk about something called hybrid DevOps. So our focus, what we've been thinking a lot about is how do you create operational constructs that span infrastructures? For us, originally, that was how do we span data centers? How do we help 10 customers with 10 totally different data centers, with different vendors, with different networks? How do we help them? But you take that a level up and you're like, well, if you're going to use Amazon and Google and OpenStack and OpenStack and OpenStack, those are all different environments, too. How do we create a hybrid experience against that? And I add the word DevOps here because it's not just operating it, it's automating it. To me, DevOps is a lot of things, but it's taking us from an ops perspective to an automated ops perspective. And so when you think about what does it take to create a hybrid DevOps environment, I've come to this sort of simple Venn diagram. We have configuration management, Puppet Chef, Ansible Salt, they do a great job configuring systems. They don't really do any good job configuring services.  DNS and networking and we're creating services every day. So configuration is configuration and service management. To make that work in a portable way, you have to have composability. I've been talking about composability. Some of what I showed you in demo is composable. But you have to be able to say, I don't have one long stretch of automation. I actually have a lot of little pieces of automation.  And the reason you do that is because if you want to make a choice, I want to use Calico instead of OpenContrail, then those two changes are going to have ripple effects, but they're actually, they could be isolated into pretty narrow pieces. What you don't want to do is you don't want to have automation that does both. Because changes to one are going to break the other and you're going to run into trouble. Same thing is true with operating system installs and components like that. The more we can get composable, the better. The reason people aren't that composable and haven't really been working in composability is because that brings in a requirement for you to chain the components together. So you can't decompose these configuration steps without some type of orchestration. And so they really have to be done together. You can't break things into a lot of pieces without having a way to execute that as a chain of logic. So next time you're looking at a really deep puppet manifest or a long chef run list or something like that and you realize that all these things are chained together and very brittle because of that, this is where I'm talking about looking at things as a much more composable way. And I will tell you, because I feel like we're doing very hybrid type work and we're very flexible from that perspective without composability, we couldn't have that discussion at all. The demo I'm doing right now is based strictly on these three principles intersecting. This is what it looks like, sort of the A-B pattern. So our fragile mono integration says I'm gonna take all these pieces and ram them together. Usually that looks like I have a big start file that describes my whole infrastructure and then I have a big red button and I click it. And if it's a good day, I'm a full moon with high tide and sun, then everything's gonna run through and it'll be great. Those stars don't line up that often and so a lot of times we'll find that those changes are very hard to put together and pull off because of exactly these changes. So what we really find very effective is looking at this as an interchangeable composition where I can take different pieces of this puzzle and step it together, stitch it together and then start changing things out. It's still gonna break, but it's gonna break in smaller steps and it's going to allow you to then start layering things on top and not having to reinvent the world. So if I'm doing an open-contrail network, I can reuse the logic I did for open-contrail in OpenStack and Mesos and Kubernetes and Docker Swarm. I can actually reuse that component in multiple ways. It could still break when it breaks, but I'm gonna be much better able to cope with that change and continue to reuse it. So I'm gonna jump back to the demo in a second, but I'm gonna go ahead and summarize where we are. So there's five real takeaways we have for this. One is hybrid infrastructures to the new normal. If you are not building your infrastructure with the assumption that it's hybrid, boy, then good luck because you're gonna be, you're gonna really be stuck in that decision. You're gonna be taking away freedom from your business to make operational decisions, right? You're driving a technical decision for your business rather than you're making infrastructure the lead instead of the caboose. And you really don't want that to happen. It really translates into poor business practice. And it's actually really the reason why people are abandoning private infrastructures because they got locked into private infrastructure. And the only way they feel like they can improve their operational capabilities is by burning down their own infrastructure and by moving it all the cloud, the shift and lift strategy. Operations can work hybrid, right? So it is possible to write operational automation, hybrid DevOps capabilities, but you have to be able to isolate those changes. You have to be able to work that in.  I have a long blog post about the next point. Amazon is the operational benchmark. Even if you are OpenStack only, the closer you are to those Amazon practices and patterns, the faster your team is gonna go, the more resilient you're gonna be, the better options you are, the more easily you're gonna take in technologies from the community because the community activity is centered around Amazon. There's a funny anecdote. Somebody was talking, was arguing about cloud foundry, PAS, beating, people love to have this, who's gonna win the container orchestration game? And I saw a tweet, somebody said, Amazon is 20 times, 100 times, all of you put together in their ability to do container orchestration. It's just the rules of gravity right now. So we end up in our own communities very siloed. We have blinders on about what's going on. If you start with an Amazon assumption, then you're gonna not have those blinders on, you're gonna be able to pick up technologies, pick things up a lot more effectively. Implementation choices do matter. And so as we go through these pieces, it does have an impact on how portable you are. The OpenStack choices that we've made, we wanna have floating IPs, we wanna have, oh, name your machines whatever you want, it doesn't matter what the login account is, it doesn't matter what the networks are named, those choices really have big impacts on usability for people coming into your infrastructures. And really, on top of all that, let's make things more composable. And the reason why I would suggest you do that is because it's going to improve your ability to reuse other people's work. When I started all this stuff, we were at Chef and Puppet were really hot at that time and there were big libraries of Chef and Puppet routines, big libraries of Ansible routines. And what people would do is they would take a big playbook or a big set of roles and they would fork them, they would put them together and use them for their piece. So basically day one, they immediately drifted off the community. If you look at what's happened in the OpenStack community, so you don't have to go very far to see this, we have a whole bunch of vendors with forked operational techniques that are 80% the same and 20% different. And so they can't come back and collaborate the way we'd like. And it's a real frustration because that means the users, the operators, the customers here are really stuck with individual vendor stove pipes rather than being able to share operational best practices. And it slowed us down as a community. All right, pause for a second. I'm gonna jump back to demo, but I'm doing really well on time. Are there questions before I start showing more in the demo? Come to the microphone. Excellent, thank you. I'm not sure this is so much a question or a comment, but first I wanna thank you for your very thoughtful presentation. I think we don't have to go too far field to look at some of the challenges that we're gonna be facing in the future. If we look at things like what Google did with Angular going from one to two, what just happened in the Node community where you remove one small bit of software out of the repos and everything breaks. So I think we're going to be facing challenges in this environment as Amazon grows up, as Google grows up, as Microsoft grows up, and they can pull the rug out at any point in time, right? And it will affect everybody who's doing automation in this space, right? So I'm kind of obviously concerned about that happening. You should be, that's a very reasonable concern. So I kind of invite your thoughts on that. So, and this is, it's really interesting. So in this year, 2016, the level of interest in hybrid has skyrocketed, right? It was, you know, 2015, it was sort of considered a unicorn, right? People were like, ah, hybrid clap, blah. And then this year people woke up and were like, oh, we're hybrid, we gotta be hybrid. So there's a business continuity issue. The thing I add into that, and I'm starting to see a trend line on this word too, which is composability, is that you have to, if you want hybrid, you have to be composable. And that composability story ends up being a really important one. The challenge has been, and for something like what we're doing with Digital Rebar, I love being able to show these one-click installs because it's sort of, it's like, ah, okay, I can do it fast. To build that, you have to be willing to say, all right, how do I decompose my work into smaller units? So your NPM, so people who don't know the NPM story, they're going through some really good community process where they're rationalizing and making sure licenses are correct for the shared libraries for JavaScript. And no JS for NPM. And somebody didn't like the process and they yanked all the permissions off of certain libraries. And it turns out that the left pad library, does nothing but left pad strings, was used in, I think, 80% of other people's libraries. And so that one library went offline and everybody's node applications broke. That's simple. So this is where composability becomes really important.  What happens in ops is that we don't isolate those changes. So in this case, somebody could write a new left pad, you could change it, and now you're back in business. In ops, finding that error and fixing it is much, much harder because we've built these vertical silos. So I can't go out and get somebody else's left docker install. And if y'all haven't been trying to install docker in production, it breaks all the time. They're changing the APIs, they're changing the repos, they're changing the way you get it. It's not just docker. Things are constantly in flux in the data. So you build this big stack of logic. And what's really sad to me is you know when somebody changes an RPM or an app get install instruction and it breaks in a certain way, you know that there's no one place that people go to fix their operational logic. Everybody's discovering it independently. Everybody's digging into their fork of that script and they're all trying to fix it. And that's what makes it really sad to me. We don't have as good constructs for ops as we have for programming. But the charge here is that if you're doing ops and pretty much everybody has to do ops at some point, you have to take time to invest in composability. What I see people do is they jump in and they'll grab Ansible or Terraform or something like that and they'll build this really big stack of vertical stuff and then it starts growing horizontally and it's very hard to go back after the fact and decompose it into much better logic. All right, I had another question, Joseph. Yeah, I think I was kind of in line with like what you didn't really kind of talk about, but it was on your hybrid DevOps part of the slide, the composability, you know, like the automation, we know that's all kind of figured out, but yes, we can kind of get to this point where like as you, you shown like Kubernetes is a way to kind of like really normalize across clouds. But is it really the challenge of like a lot of the tooling even just to get to that point? I mean, that's kind of what in our journey is some of the challenges of like, you know, how do we consume it as well as like the other piece within AWS is all the big data. So that sometimes drives some of the decision-making. So I mean, what's your perspective on that? In that, how do you bring in the different bits and pieces? Yeah, I mean, what are you seeing? What are you recommending to kind of adjust that gap? So I want to make sure I understand because one, you know, there are definitely different services in AWS and one of the things. So AWS in my mind is two different, two very different things. One is it's an infrastructure capability and that's relatively straightforward to make hybrid because it's relatively portable. If you turn around and start consuming services in AWS, like are you talking about like a big data service or an analytics service or something like that? It's a classic use case for us. So when you start doing those things, you end up much more tied into what their service is capable of doing. And so the composability piece, you'd end up wrapping that service into a composability layer. And to the extent that you have alternatives, you could actually do a composable infrastructure for that and say, all right, big data is a composable unit and I'll just tell you how to consume it. But you're gonna, and so it's entirely reasonable to do that. You're about three steps beyond where we usually get from a composability perspective, but that's where it would go logically. And that's where like drives a lot of our challenges. And that's why we would choose a cloud formation because we're trying to access all these resources. We don't live in just a, there's all this other legacy, there's all this stuff that we've built up over time. So it's just kind of hard for us to kind of neglect that piece. So I feel like if anything, there should be a focus on a lot of that infrastructure to kind of give you some of that extensibility to kind of like get to those resources and then you start getting into a true hybrid DevOps. And you're entirely right. So the balance is if you do cloud formations, that's Amazon's tool for doing this orchestration. If you do that, you're gonna be able to be successful really fast in Amazon and they start making their services available. But the challenge is that takes you down a monocloud path. And so what we really need to be able to do is start building the tooling that lets us be more composable at every level as we go. And we're just starting to get there. And part of the challenge here is that the nice thing about a Terraform or a cloud formations or a heat template is that everything looks like it's in one nice little place and I can check it in to get. And you're like, hey, look, now I can repeat my infrastructure. What you haven't done is you haven't protected yourself from all of the variations and orchestration needs and all the pieces. And so what I'm seeing is that those capabilities while very fast become brittle over time. Just like Chef and Puppet, big Chef and Puppet cookbooks and playbooks became over time. And so this is my concern. We're getting faster. But those vertically integrated stacks become very fragile. And from a business perspective, they're going to limit you in a lot of choices, right? You don't want to be told, oh, we can't move out of Amazon even though it's costing us $100,000 a month for this application because all of our automation script and our CI CD pipeline targets Amazon. And it's very easy to build those deep hooks into the APIs and pipelines and things like that and not think about how you isolate it, right? And cool. Good questions. Thank you very much. If you have more, I'd be happy to keep talking, but I do need to exit the stage. So thank you all for coming. I hope this was helpful. Thank you.


The Senate on Thursday started the screening of nominees for appointments as national commissioners for the Independent National Electoral Commission, INEC. The nominees include one of the aides of President Mohamed Bwari, Loretta Onoucher, and they are already in the Senate for the exercise. Onoucher is currently waiting for her turn to be screened by the Senate panel. The nomination of Onoucher, who currently serves as senior special assistant on new media to President Bwari, had provoked serious public outcry with the People's Democratic Party kicking against her nomination. The PDP said Onoucher is a card carrying member of the ruling or progressive Congress and by virtue of her political affiliations with the APC, she is not fit to be appointed as an election officer. Other nominees include Professor Mohamed Sani Kala from Cassino State, Professor Kunle Cornelius Ajayi from Iqiti, and Seidu Babura, Ahmad from Ajigawa State. We will bring you details in our subsequent bulletins.


And we're back. Hi, this is Stu Miniman with wikibond.org, with SiliconANGLE TVs live continuous coverage of the biggest tech conferences in the industry. Here at the Open Networking Summit in Santa Clara Convention Center, unpacking the future of networking and joining me for this segment is the IDC networking team, the power play team from Canada. We've got NavTanler and Brad Casemore. Gentlemen, thank you for joining us here on this segment for theCUBE. Thanks very much Stu. We want to thank you for not discriminating and putting guys with radio faces on the air. Yeah, so in Canada do we have, you know, a different pronunciation of SDN or is it? We say A, right Brad? Yes, before we say everything. Thanks Stu, I'm glad to be here. By the way, I'm a transplanted Canadian, I'm living in Boston, so. We still say A. You know, home of the East Coast studio of theCUBE. So guys, you guys go to a lot of the shows, you've been looking at this technology just like we do on theCUBE. So I want to dig into it. Nav, if I can start with you, you know, last week you were at Mobile World Congress in Barcelona. You know, very different audience I think from this show. What can you bring back for us as kind of the key learnings from that event? Yeah, I was there and it seems like it's just blurring from one week to the other. You're absolutely right. Very different audience, big show, but guess what, it was all about apps and content. So the big news of course was Facebook's acquisition of WhatsApp, but what was even more surprising besides that was what WhatsApp CEO said he's getting into the voice business. So pretty significant, but in terms of SDN and NFV, a lot of buzz, a lot of activity actually, lots of NFV announcements, trials, HP announced their open NFV, number of other vendor announcements. So Mobile World is more than just mobile. It's content, apps and everything to do with networking. So I'm wondering if you could give us from just kind of a market standpoint. My take is that NFV solutions are probably a little bit further along. There's actually more different products I can point to out in the marketplace than adoption. Do you guys have any revenue numbers or just anecdotes that you can give us as to kind of NFV adoption? So good questions, Sue. I mean, NFV adoption will happen more quickly because service providers have formed the group, the standards group and have made significant progress in less than a year and a half. They've actually defined use cases and at Mobile World we saw, I saw many examples from Telefonica, from NTT, BT and others that were deploying it. Now in terms of revenue, one of these applications are yet going to hit the bottom line, but long term, I think NFV will have multiple orders of billions of dollars of impact in terms of value creation for the service providers. So Brad, you travel also, a lot of the networking shows, you look at inter-op, you look at this show, there's lots of other SDN shows. Wonder if you can, where does this show fit in the overall ecosystem of networking today? I think this show is an interesting one and a unique one in that it brings together so many aspects of the industry. We have, obviously NAV's here, but NFV it's rare actually that we're at the same event, but we're at this event because it does cover telco adoption, it does cover cloud adoption. There's more and more discussion of what enterprises of varying sizes, starting with the largest and starting in verticals like financial services will do with SDN. Of course the vendors across all those markets are here. So it's a show I think that really is the biggest and the landmark SDN show right now. So you mentioned, there's a lot of vendors at this show actually. You've been walking around, you've been talking to a lot of people. I mean, are the vendors just coming together, drinking their own Kool-Aid and saying that this is how we finally topple the giant in the industry or what are you seeing out there? You mentioned financial services. There's a lot of variation in terms of solutions. There's a lot of variation in terms of approach, in terms of architecture. I mean, the SDN is an architectural model above all. It's, you know, and then products of course are built according to that model and they vary enormously. And I think the thing that I would say is that we're seeing tremendous disparity in how the market is reacting. For instance, this all started, look at the board of directors here at the ONF. It all started with hyperscale. And it's working its way through to very large cloud service providers. And then of course, the largest players in the financial services who, from a data center standpoint, look a lot like hyperscale. You know, you've got guys like Goldman Sachs, for instance, and Fidelity. They're data centers, they have more than one data center and they're building skill out data centers to support their application workloads. You know, the morning keynotes, I think kind of had some of those big guys out there. If you look at NTT, it's making a big push into many different aspects of SDN and NFV. I mean, they made an acquisition. I heard it's hundreds of millions of dollars for that acquisition to get them into the NFV market. Most enterprise companies aren't going to make an acquisition to take advantage of that. Nav, I think, I know you were watching closely AT&T. Did I hear right that they spend $50 billion a year on capex? No, it's actually 20, they spent 20 billion a year on capex, which is still a huge amount of money. So let's give you a little insight. John Donovan was also at Mobile World and you think this is a person like John would have had a lot of prominence at a Mobile World show, but I think here today, and you're asking Brad and I have the same kind of view, this is a real melting pot. This conference, you got everyone from dev developers to VCs, CEOs here of startups, as well as larger companies. I'm pretty impressed. NTTN, AT&T are two of the early adopters in the large telcos, but both taking different strategies. AT&T made a significant announcement that they're going to revamp their whole procurement. That 20 billion capex is not going to be guaranteed to be the Cisco's and Alcatel's, Juniper's, et cetera. So I think that's a significant transformation point in the industry. Do you have some estimate?  Yeah, we as analysts, we've been asked that and I'm going to say that it's going to take, we probably see next year, even 5% of that capex really get impacted. One of the things that a lot of people don't realize is that the biggest cost is really in their Apex and what John pointed out, and AT&T and NTT are both focusing a lot also on Apex. So trying to do everything at once is not going to happen overnight. Yeah, I mean, I know what we've found talking to most CIOs today, maybe not at the 20 billion dollar level, but CIOs today, the capex gets the budget approved and then the Apex is where they have the huge savings. But what's different is, there's been competitors out there and networking that have said, oh, we might be able to save you on a capex 10, 20, maybe 30%. There's the potential here that we could be talking a significant more, I mean, just from old way versus new way, it might be 70% cheaper. And the operational expenses should be 10x better than what you were doing before. So I mean, do you think that's real and how long does it take for that to kind of percolate through the rest of the market? When you look at Apex and telecom service providers, it's anywhere from 60 to 80% of their overall budget. So it's huge and it's going to take, the capex savings part will happen with NFV first when we build virtual appliances, x86, that's where they want to go. And I think they'll start off in small steps. So the overall impact of capex is not going to be, you know, 10, 20, 30% year over year until we get some of the innovations from the community here at this conference, right? Open source, programmability, SDN and NFV are enablers. It's all about programmable networks and open APIs. It was very interesting to see some of the vendors and to hear some of the telcos talking about this issue. I mean, now covers this full time, but I'm fascinated that how much of this has come from the pressure that they've seen from the OTT cloud service providers. There's a lot of higher value services that the Amazons, the Googles, the Facebooks are providing and telcos realize that if they don't make a move and begin to adopt some similar technologies and processes, they could lose this opportunity for good. And I think it's a significant impact this for them.  You know, networking doesn't necessarily play well with others, you know, I lived at the intersection of storage and networking for many years and storage would say, I'm not performing well and, you know, can you fix this? And, you know, QOS was a four letter word for most of the networking guys.  I would say that it's already happening in the hyperskill world. I mean, that's happened, right? They have a more collaborative approach to IT, to how they use technology, to how, to the processes, to how they build their networks, to how they deliver their application workloads and how they develop infrastructure for that. The big question is, what happens in the enterprises workloads move to the cloud? I think silos will persist in a lot of enterprises for, you know, years. And certainly there are a great number of vendors who would tell you that and some who will argue otherwise. But there's no question that, you know, more applications, more workloads, will move to the cloud. And as enterprises adopt private cloud, they have to rethink how they deliver their applications. And once they rethink how they deliver their applications, they move to things like orchestration. And then they look at how their infrastructure aligns with that. So, once that happens, the silos break down. And some enterprises, it's going to take a long time. So, you know, you've been meeting with a lot of people at this event, you know, how are we doing?  You know, if we take, you know, maybe baseball is not the right one for you. We'll use hockey now. So, you know, hockey is the Zamboni clearing off the ice at the beginning and people are getting into their seats. Are we still in the first period? If it's hockey, you know, or is the game already won and we're just playing out the clock? I mean, where are we with, you know, kind of that transformation? Yeah, I think that some players again, I've been playing the game and continue to play the game. So, you look at obviously Google, Facebook, Microsoft and the data center side, Amazon and those sorts of companies, they've been playing this game for a little while and then there are a tier of cloud service providers who are still moving forward. Maybe it's the first period of intermission for them, but they've begun playing the game. And then you've got some who are clearly, you know, just getting their skates on and they're going to have a basically, try to get the feel for the ice and figure out exactly how far they're going to play the game. I think it's very early for some companies. So in the telecom space, I mean, this is mind blowing because getting all the telecom guys to get together in such a period of time to do NFV and get people to actually develop this. We're not even in the, you know, halfway through the first period of a hockey game to use that analogy. I mean, there's a long, long way to go. The good news is that they need to learn how to try and fail. I think we heard Vinod Kosla and some of the other speakers of this conference say, telcos have to learn how to fail as well as be successful, but they have to do it fast because Google, Facebook, as Brad said, they're so far ahead that that race, if you're looking at a marathon, there's, you know, there's a lot of catching up these guys have to do. And I think the service providers have got to change their culture. And part of what's nice about this conference is that John Donovan made a recruiting pitch at the several times from AT&T, which is interesting because he's in Silicon Valley and AT&T is not obviously top of mind or any service provider, but they're going to, you know, I think they're sending a strong signal on, it's going to take time. And to continue the hockey analogy, we've even seen a few fights, which is... Absolutely. You know, the IT industry's, you know, not above dropping the gloves, you know, putting some people in the penalty box. So what are you looking at, Brad, over the kind of the next six to 12 months? You know, what kind of market indicators can people look for to see that this is maturing, that, you know, the ice is ready to go on and, you know, get involved? What should people be looking for over the next kind of six, 12 months? I think we're definitely watching the customer adoption rates and watching the size of companies and what those companies do, vertical markets, that's something that we'll be tracking closely. And we do expect the adoption is ramping up. There are various ways that this technology is cut, of course, we have network virtualization, we have, you know, in the telcos, we have NFV, we have, you know, open flow-based SDN, which the show is predicated on in the ONF, and we have network disaggregation also happening, you know, vendors like Cubilis and peak eight and Dell's adoption of Cubilis. These are all things that I think we're watching very closely. We expect this to be an eventful year, but somewhat of a bridge year, if you will. I think there are bigger developments coming, but this year will be a year of laying some significant groundwork and seeing some inroads made in certain parts of the market. The broader market's still coming. So, Brad, I do have one more question for you. When we look at really the financials of, you know, the data center, if we go out a couple of years from now, is networking a smaller piece of the pie? Does it move over to applications, kind of that mix of hardware versus software? You know, what does it look like in a couple of years? I think increasingly, and people have said this for a long time, the skill set of network professionals has to be extended, has to be expanded. You know, they're trying to learn more about virtualization, more about server-side automation tools like Chef and Puppet and CF Engine. They are developing architectural skills, thought architect skills. And I think those changes are consonant with some of the changes we're seeing in the technology side. Obviously, if software will not eat the world, it certainly is recasting it. And I think this is a significant, it's going to be with us to stay. Software is changing. Mark Andreessen's running down the hallway to tell you it is eating the world. Now, my last question for you is, you know, the telcos, you know, in a couple of years from now, do we see them playing a much larger role?    Yeah, that's, you know, Stu, that's exactly the right question. In fact, I'm working as part of my plans this years to look at the different business models because some telcos, like Take Verizon or even CenturyLink, say we're building out data centers, they have made acquisitions, we've seen that for the last few years, NDT, others telcos are going to be, we're going to be almost like over the top. They're going to use other infrastructure and sell services and value, and then you have the content itself. So one of the things that I think you're going to see is a lot of partnering between content providers, like what Comcast did with Netflix, George Telecom doing in Europe with Spotify where there's revenue sharing deals, Cisco's doing it with AWS for VPNs. So I think you're going to see some very creative models. The key question I ask is not all of these telecom service providers are going to survive, you're going to see more M&A action over the years as wireless and wire line infrastructure also converges. So you've got lots of moving parts, and SDN and NFV are two of the, I call it two of the wheels of the gear of third one being orchestration that I like to draw that all three are really important for the telecom providers. You shouldn't have said M&A, I saw some investment dentures turn on. Oh, okay. Yeah, so rapid real quick, last question, NAV first and then Brad, coolest either startup or technology or project that you see at this show or in your recent travels that people should keep a close eye on? Whoa, that's an interesting one. I mean, I think I've seen, I've been really impressed with TLF, which has happened to be one of the companies that AT&T announced, and I got to meet them some time ago and I've seen and heard evidence of success.  I mean, their platform is completely open. It's northbound, southbound, multi-vendor. I mean, it has all the things. And it's not based in the US, which is interesting too, because you could think of everybody being here at Silicon Valley. So that's one of, that's an example. I think it's definitely a cool company. I've been watching them. Right, and Brad? Yeah, I think there's a number of companies that I think are very interesting. And I think there's beyond what we're seeing today, there'll be a wave of very interesting analytics that'll come about in the next stage. But right now I'd have to say the company that's made some significant strides. And I think the recent announcement that they had with Dell, I'd have to say Cumulus, mainly it's not strictly an SDN company. It's more about network disaggregation. But I think that announcement is very significant and it's indicative of the power of software in the network industry. Well, Brad and Nav, thank you for sharing with us everything that you think about SDN. So this is Stu Miniman with Silicon Angles, the CUBE live coverage from the Open Networking Summit 2014. We'll be right back with our next guest.


This is Classics of Liberty from Libertarianism.org and the Cato Institute, narrated by Caleb Brown. Today's classic, Selections from Speeches and Writings on Free Trade, by Richard Cobden. Richard Cobden is one of history's best proponents of free trade, at the forefront of popular agitation against harmful protectionist policies in his native England during the middle part of the 19th century. A successful businessman deeply committed to liberal ideas, Cobden said in a letter to his brother that he did not intend to dedicate the whole of his life merely to heaping up money, but hoped to pursue more rational and worthy exertions. Still, while he aspired to effect some change in favor of free trade, Cobden was nonetheless reluctant to enter the parliamentary fray, perhaps preferring to continue his advocacy exclusively through his anti-corn law league. Cobden's friends prevailed over this apparent resistance and he began his career in the House of Commons in 1841. In the following selections from his speeches and writings, Cobden confronts the fallacies that surround free trade even today. He demonstrates that beyond increasing the wealth and prosperity of participating nations, free trade also fosters peace and goodwill among them. Cobden argued that the interests of mutually beneficial commerce and a commitment to non-intervention in the political affairs of other nations ought to guide foreign policy, not schoolboy rhetoric, upon the balance of power. A century and a half after his death, Cobden's eloquent explanations of the many benefits of trade remain relevant and can help us understand an increasingly globalized economic climate. I have been accused of looking too much at material interests. Nevertheless, I can say that I have taken as large and as great a view of the effects of this mighty principle as ever did any man who dreamt over it in his own study. I believe that the physical gain will be the smallest gain to humanity from the success of this principle. I look farther. I see in the free trade principle that which shall act on the moral world as the principle of gravitation in the universe, drawing men together, thrusting aside the antagonism of race and creed and language, and uniting us in the bonds of eternal peace. I have looked even farther. I have speculated and probably dreamt in the dim future, I, a thousand years hence, I have speculated on what the effect of the triumph of this principle may be. I believe that the effect will be to change the face of the world so as to introduce a system of government entirely distinct from that which now prevails. I believe that the desire and the motive for large and mighty empires for gigantic armies and great navies, for those materials which are used for the destruction of life and the desolation of the rewards of labor will die away. I believe that such things will cease to be necessary or to be used when man becomes one family and freely exchanges the fruits of his labor with his brother man. I believe that if we could be allowed to reappear on this subliminary scene, we should see at a far distant period the governing system of this world revert to something like the municipal system. And I believe that the speculative philosopher of a thousand years hence will date the greatest revolution that ever happened in the world's history from the triumph of the principle which we have met here to advocate. I believe these things, but whatever may have been my dreams and speculations, I have never obtruded them upon others. I have never acted upon personal or interested motives in this question. I seek no alliance with parties or favors from parties, and I will take none. But having the feeling I have of the sacredness of the principle, I can say that I can never agree to tamper with it. I, at least, will never be suspected of doing otherwise than pursuing it disinterestedly, honestly, and resolutely. Free trade in the widest definition of the term means only the division of labor by which the productive powers of the whole earth are brought into mutual cooperation. If this scheme of universal independence is to be liable to sudden dislocation whenever two governments choose to go to war, it converts a manufacturing industry such as ours into a lottery in which the lives and fortunes of multitudes of men are at stake. I do not comprehend how any British statesman who consults the interests of his country and understands the revolution which free trade is affecting in the relations of the world can advocate the maintenance of commercial blockades. If I shared their views, I would shrink from promoting the indefinite growth of a population whose means of subsistence would be liable to be cut off at any moment by a belligerent power, against whom we should have no right of resistance or even of complaint. It must be in mere irony that the advocates of such a policy as this ask of what use would our navy be in case of war if commercial blockades were abolished? Surely, for a nation that has no access to the rest of the world but by sea, and a large part of whose population is dependent for food on foreign countries, the chief use of a navy should be to keep open its communications, not to close them. I will only add that I regard these changes as the necessary corollary of the repeal of the navigation laws, the abolition of the corn laws, and the abandonment of our colonial monopoly. We have thrown away the scepter of force to confide in the principle of freedom, uncovenanted, unconditional freedom. Under the new regime of our national fortunes have prospered beyond all precedent. During the last 14 years, the increase in our commerce has exceeded its entire growth during the previous thousand years of reliance on force, cunning, and monopoly. This should encourage us to go forward in the full faith that every fresh impediment removed from the path of commerce, whether by sea or land, and whether in peace or war, will augment our prosperity. At the same time, it will promote the general interests of humanity. It will suffice on this head if we observe that to enable any one of our manufacturers to conduct the simplest branch of his mechanical and chemical industry, it is requisite that he be duly supplied with materials, the growth of every corner of the globe. The commonest printed calico, worn by the poorest peasants wife, is the united product of four quarters of the earth. The cotton of America, the indigo of Asia, the gum of Africa, and the matter of Europe must all be brought from those remote regions and be made to combine with 50 other as apparently heterogeneous commodities by ingenious arts and processes, the results of 10,000 philosophical experiments, and all to produce a rustic's gownpiece. Whilst such are the exigencies of manufacturing industry, binding us in abject dependence upon all the countries of the earth, may we not hope that freedom of commerce as an exemption from warfare will be the inevitable fruits of the future growth of that mechanical and chemical improvement, the germ of which has only been planted in our day. Need we add one word to prove that Russia could not, unless she were to discover another chemistry, which should wholly alter the properties of matter, at the same time seclude herself from the trade of the rest of the world and become a rich and great manufacturing or commercial nation? Wherever a country is found to favor foreign commerce, whether it be the United States, Russia, Holland, China, or Brazil, we speak only of commercial nations and, of course, do not include France. It may infallibly be assumed that England partakes more largely of the advantages of the traffic than any other state, and the same rule will continue to apply to the increase of the commerce of the world in whatever quarter it might be, so long as the British people are distinguished by their industry, energy, and ingenuity, and provided that their rulers shall keep pace in wise reforms and severe economy with the governments of their rivals. It follows then that with reference to trade, there can be no ground of apprehension from Russia. If that people were to attempt to exclude all foreign traffic, they would enter it once upon the high road to barbarism, from which career there is no danger threatened to rich and civilized nations. If, on the other hand, that state continued to pursue a system favorable to foreign trade, then England would be found at Constantinople, as she has already been at St. Petersburg, reaping the great harvest of riches and power from the augmentation of Russian imports. By far, the greatest proportion of the writers and speakers upon the subject of the power of Russia either do not understand or lose sight of the all-important question, what is the true source of national greatness? If government desires to serve the interests of our commerce, it has but one way, war, conquest, and standing armaments cannot aid but only oppress trade. Diplomacy will never assist it. Commercial treaties can only embarrass it. The only mode by which the government can protect and extend our commerce is by retrenchment, and a reduction of the duties and taxes upon the ingredients of our manufacturers and the food of our artisans. I believe that the progress of freedom depends more on the maintenance of peace, the spread of commerce, and the diffusion of education than upon the labors of cabinets or foreign offices. And if you can prevent those perturbations which have recently taken place abroad in consequence of your foreign policy, and if you will leave other nations in greater tranquility, those ideas of freedom will continue to progress, and you need not trouble yourselves about them. That was Selections from Speeches and Writings on Free Trade by Richard Cobden. Find more classics of liberty at libertarianism.org.


So, I am now allied with all four city-states, thanks to those barbarians and my marble. I am heavily allied with them. I've got so much happiness, I don't even know what to do with it. Everyone's at War with Scott, and hopefully I can push the game toward his conclusion. I'm actually going to retreat all my guys over because I can upgrade them to Pykemen and I'll very soon be able to upgrade these companion cavalry to Knights, which is going to be great. I'm going to crank out as soon as I finish the Temple of Artemis and this workshop, you see, I'm going to start building settlers just to start settling. I'm going to settle at least a fourth city, just to 100% ensure victory. Otherwise, everything's just coming up millhouse. Let's see, I at least take an eye on this. Ah, I should upgrade these guys as well to Pykemen because I'm running at a reasonable surplus right now. I guess I'm building ranged units. That's something I haven't bothered with yet in this game. You hang out there. But otherwise, yeah, check all this out. I'm pretty much good to go. No one's even targeting all the quests. I don't even need to bother with these quests anymore. Let's see, Ur wants me to build the Temple of Artemis. I'm going to finish that real soon, so that'll keep them. And there's a barbarian camp. Which one does Ur care about? I imagine that one. It's the only one that's nearby that I know about. Yeah! Nice! I'll go take that out for you, Ur. You'll be even more my allies. Everything is great, and Scott is in real trouble now. I'm going to back off on harassing him, and just build up an overwhelming economic force. Alright, so this is the last turn I'm going to take in this game. I'm done. I mean, I haven't lost, right? It's like I could still theoretically win and keep fighting.  And it's not fun, right? So basically here's what happened. I chose Songhai, which means I have to go around killing barbarians to get money.  It's a military-based game, we need to do a duel, nothing else matters but military, right? Okay, so that's what I tried to do.    So basically it was really slow to move my units out to where the barbarians were.  I couldn't kill as many barbarians as I wanted to and couldn't get as much money as I wanted to. Meanwhile, RIM is Greece, so Greece, you know, on this size map, about the time when you're reaching the opponent, right, you know, they get their special spearmans and they have special, the other thing, right, they get two special units at the same time, I guess their moment. You know, it's pretty, it's like early, it's like at just the right time. I think Greece is like, you know, is okay in a general game but in a duel, Greece is hot because you can just, at the right moment, get those amazing units that the other player can't really compete with, right, better spearman, whatever. So, I think the other one's a better chariot archer or something, I don't remember but, so just as the moment, you know, I was ready to do some stuff, RIM had these amazing units and he moved them across the board and he locked me in here, right, so, you know, he destroyed my pearls and whatever, that's not a big deal. The big deal is that I couldn't get money, right, I wanted, I could caravan here and caravan here but in order to do that, I'd have to send my caravans forward which means my armies need to be even more forward than that so that he would have to go through my army to get to the caravan to stop it. I couldn't get my armies that far forward, right, so because of that, he just befriended all the city-states because he's also Greece which is like super city-state power, right, notice all four city-states are at war with me and allied with RIM. And what, there's no one else, it's a duel, there's no one else to caravan with, so how else do you make money, right, the only way to make money is by having markets or, you know, roads and resources and, you know, it's not enough money, six from connections, 21 from cities, no from trade routes, those three ways to make money and one of those ways I can't use, right, and of course if you want to fight because it's a military-based game, you know, unit maintenance is the thing, right, you need money to pay the unit maintenance, so it's pretty much get money to pay for military, right, that's why I did well when I was China because China, you build a library which is actually their, their upgraded library, the paper maker, gives you money and science plus money, usually a library costs you money to have, China it's plus two money which is effectively plus three because it's minus one for everyone else, and that's how you make money just by building paper makers, also the game where I beat RIM, the city-states were behind me in the water and I was able to cargo ship with them this to get a huge pile of money and I built the Colossus even more money and he wasn't able to interfere with that, right, this game I actually did build the Colossus which gives you plus five gold but I'm not able to do the trade routes without the players generate plus two gold, there isn't another player who is there to trade with, right, and actually I did trade with these city-states, I had some caravans going but he just came over and pillaged them and even though I tried to push my military forward to create like a line like so right, it's like he just touches that camel just like on one turn, that's it, it's your whole your whole thing is over, you got to build another one, you know, I couldn't, you know, so, you know, I just want to show you like here watch, he killed that already, right, I play the guy, shoot that at least, not in range of my, and it's not really worth playing this game just to, you know, long drawn out nothing, I have nowhere to expand to, what am I gonna put the settlement like down here, I get money, I can't expand, he's already got a whole bunch of cities over here and all four city-states helping him, it's just, you know, yeah, not really any point, you know, I don't see a catch-up mechanism available to me here, you know, it's like I can hold out and survive, but I don't think I can achieve any of the victory, I've never seen this before, my American only sport 29 units, I'm over that limit by two, which decreases production in my cities by 20%, not running out of deficit anymore, however, thanks to these policies, oh I better deal with those barbarians, I guess, just in case, I guess that's because of my population, let's see, I think you need a large enough population, yeah, number of cities and population, so I'd be as like inscripted my entire civilization into this war, and it's over, the world has been convulsed by war, many great and powerful civilizations have fallen, but you have survived and emerged victorious, the world will long remember your glorious triumph, so where did Scott go wrong? So let's see, here's the map, let's watch the game as it progressed, it's both expanding, see, look, I built a city pretty early as always, turn 41, alright Scott built a city but in a really shitty place, yep, and then I got my hold here, and he never tried to push over to settle up here, I would have settled here if this was a real game, and that's all BS in the end, so Scott quit right there, so that's when Scott quit, our scores are actually pretty close, this was when I just actually pushed the attack, wow, once again, check out these city states, I'll put the white one there, our scores weren't comparable to city states until I got my boost for building a city, and then Scott got a boost for building a city, right here where I just kept growing and he didn't, I was always beating him on culture, I got rid of these city states, pretty substantial, oh reasonably, I was always ahead of him for all intents and purposes, oh we were even, his economy actually wasn't worse than mine, until here, but look it dipped, his economy was not nearly as bad as he was making it out to be, huh, that kind of seals it though because remember I kind of just surrounded him and prevented him from expanding out and harassed him and he didn't really push through in any particular direction, I kept his caravans and everything away from the city states, I can see that show here in military might and that were pretty even, I mean I got a slightly better army, but then he catches up, everything's fine, but then I built enough of an army to hold him at bay for the entire rest of the game, don't remember what was going on right there, science-wise pretty even, in fact he was ahead of me for most of the game, which is interesting, and while I got a boost and I was ahead of him on culture, he was keeping step with me, he never fell behind, I didn't pull away there until I had a third city and he out-produced me, look at this, he out-produced me for basically the entire game, well I guess in the very very early days I out-produced him, but now he was out-producing me and had an okay economy throughout that whole span which is real interesting, he also had more gold than me, look this is when I took out his caravans, really messed him up, he never recovered from that, that seems to be it, it seems like all his stuff was going fine, I guess I can play the game when I'm the only civilization, well my economy's okay and my unhappiness isn't unreasonable, I could basically keep this going, I did not put myself into a burn everything situation, I could basically at this point, station of military units around this board to make sure barbarians never spawn and then disband the rest of them and just play forever in a perfect utopia, so by killing Scott and all of his people I made a perfect utopia, nice, but yeah it seems to me that the only reason I won was that Scott did not at any point really try to break out and even though Prague was right here, he never secured this area, he should have settled down here, I mean look, look at all this iron and stone and stuff, he should have built a city like here somewhere and he shouldn't have built Timbuktu there, he should have built it up here somewhere or he should have pushed through and tried to build over here, because these city states were right next to him, look at this, he had direct access to Lhasa and direct access to Prague, he should have pushed through, he needed this city, this game would have made more sense if he had built a city here, but he didn't, he was afraid of the actually admittedly relatively weak military presence that I had up at these edges because while my military was bigger than his, it was spread among two completely separate fronts, he should have just pushed on one and broken through, because there's a great spot to settle there and so it goes and that's the end of game four, I'm now up three to one and I think Scott is not going to play any more duels or at least not any duels on this Inland Sea map, I'm gonna see if we can get a game going that's actually four players, so still a small game to go quick, but four civilizations, either me and Scott in two AIs or I'll see if we can get some of our friends to jump in, in which case Scott will probably try to convince them to all gang up on me and then they'll all instead gang up on him because it's funny


Hell, so it goes that way. So, I like it. And then on, and I always like something like this. How high does it go? It goes pretty good. It looks like fun. It would work a lot better if it was wider. How about this, baby? How much is all these bowls now? See, it wouldn't work because any of your air would come out of here. I was waiting for you to say, well that won't work. That won't work. I used the jigsaw to cut this. It was right off when I wanted to push it all out. And then I cut off the jigsaw. I was going to put it in your jigsaw, but I tried that with a different one, and it didn't work. So I just used what I wanted to do. A thinner cardboard would probably be a little better. It would be a little less room resistant. The cloth is not too bad. If you made the nose comb just a little bit, it would make it look a little better. It's kind of hard to get through that. I'd like you to say, the biggest thing would be the thinner piece. Which one is the smaller one? The thinner piece there, and you've got to make it. Well, that's a good idea. And because you made it all yourself, I'm impressed. It isn't the prettiest? Yeah. But it shows... I think I understand this today, because I didn't have time, but I was thinking about saving it or something. But that's really nice. I'm trying to think of what else it could do up there. I had to put this here. No. But I'll also give you a blue ribbon, because I think we showed some thought into that. Okay?


In this next demo, our partner, Okta, will introduce the concept of Zero Trust Security, centered on identity. In our multi-service world, people are the new security promote. According to recent studies, the adoption of modern technologies is resulting in an explosive growth in identities. This is not only a challenge to manage, but identity has become a critical element in any security strategy. Users are targeted as the weakest link in any security chain, responsible for 20% of breaches with stolen credentials being the most common initial attack vector. But why does that matter? The problem isn't just managing the users themselves. When an account gets compromised, it impacts the overall business. Did you know the average cost of a breach was more than $5 million? It's clear that a critical element to addressing this area is to have a solution that provides the ability to establish a trust relationship with users before access is granted. And where can you start building that trust? Let's take a look. When we're talking about identities from various different entities, what it boils down to is people and groups, and bringing them into Okta's universal directory. Here at the Okta dashboard, let's head over to directories and groups. We can see here we have groups of users from various different entities represented by their source icon. Some are Okta groups, or Workday groups in our HR system. We could also bring in identities from directories as well. Let's jump over to directory integrations. And you can see we can connect to Active Directory and LDAP as well as a CSV directory. Regardless of your user source, be it Active Directory or Workday, policy controls and application access can be centrally managed in Okta. Let's take a look at that in action. I'll jump over to my box app. Here I can see which users have been assigned to this app as well as which groups. This app as well as all apps have their own set of sign-on policies so we can get very granular with access at the app level. We can see here a set of sign-on policies specific to this app, and each policy has its own set of rules. Let's take a look at those rules. Here we can see the various different conditions that can be applied to access decisions, be it people, location, or client restrictions, such as mobile or web requests. Based on these conditions, we have the options to specify whether or not they were prompted for a second factor. So as you can see, user identities can come into Okta from several different locations, including existing directories, apps, or third-party identity providers. But regardless of their location, the same set of policies apply. Let's take a look at the sign-on experience. Welcome to the login page. The policy for this particular login page only asks for the user's username, but also allows authentication via a PIV card. We'll enter the username and hit Next. You'll see we're prompted for Okta Verify Push. This is the first factor requested. Once accepted, the user can be allowed access or move on to the next factor based on the determined risk. In this case, it's determined that this is a risky login, so now it's going to prompt for a password. I'll enter the password, and we're now in the Okta dashboard, where we have access to all our applications. With Okta, working from anywhere is made seamless for your users, no matter what they're accessing. It could be a cloud app, an on-prem app, or a server. And it all starts with app access. App access starts with integration. There are several ways to integrate apps with Okta. The first being the Okta integration network, which has over 7,000 integrated apps, each with their own unique set of step-by-step instructions. Okta also supports deep integrations for more than 18 different protocols, one being Radeus, which is most commonly used with Cisco ASA. We can also integrate with other network appliances such as Palo Alto Networks, Akamai, and F5. This covers your cloud apps and VPNs. For apps that aren't in the cloud, Okta Access Gateway provides a method to gate access to on-prem apps without the need for VPN, apps such as Oracle EBS. And finally, the same access controls used for apps expands onto servers with Okta Advanced Server Access. Giving you zero-trust access decisions for your server fleet. Let's take a look at this in action. We'll start by logging into the Okta dashboard. From here, we can see all of our assigned applications, things like Cisco Umbrella or on-prem apps like Oracle EBS. Now, let's jump over to our PC and fire up a VPN session with Palo Alto Global Protect. As you can see, the Okta logging experience here is the same experience you have when accessing via the Okta dashboard. And finally, let's log into a server. This can be done from the Okta dashboard, but for this demo, I'll start it from a terminal window. I'll establish an SSH connection here. You can see I'm redirected to Okta. I'm prompted for MFA, and now I'm granted access to my server.