All right, I am live on Facebook Facebook live on the Facebook mentions, so I Using my iPhone this is a neat new feature that Facebook has and let me see here Okay, there's comments people are free to ask questions. Okay doesn't go sideways. It's only a vertical app Okay, got it straight Got it straight. Okay, so people are I'm just gonna try this out. This is a new feature. It's Facebook live It's sort of like Google Hangouts step. It's just one way only Jeff Tucker introduced me to it and suggested I try this. I am on my iPhone. I'm using a Regular mic your bud mic I was actually gonna use this because you can plug it into a USB adapter to the iPhone But my iPhone is almost out of power. So that lightning port is taken Anyway, so I'm looking forward to anyone typing questions Where they have nine viewers, I guess it's gonna start growing I had mentioned this the other day and some people had suggested some questions So I'll go ahead and start with some of those. I did a show with Tom Woods the other day on Libertarian theory of non the non-aggression principle and we're trying to rebut some of the opposition Some of the arguments against it some of the criticisms of the non-aggression principle I think the show was pretty popular. We did a good job It was only 30 minutes. We only had so much time in the meantime some people like Scott Bowers and others told me that I speak really fast For a southerner, I guess or just in general, I don't know and that is probably true So maybe I need to slow down sometimes. I don't know just my style especially when I know I had a clock and I only have so much time to speak and In any case, I actually had not had much time to prepare on the Issues that Tom and I were going to discuss just because of the way we did it at the last minute So I think I could have been more prepared But anyway, I was pretty happy with it. One of my friends Sebastian Ortiz mentioned that Excuse me He mentioned that he thinks at the end I shouldn't have implied that my views on the positive obligations parents arguably have towards children is I guess plum-line Libertarianism, Rothbardianism, and I didn't mean to I think I Pretty clear that Rothbard and Walter Block, for example have a different view on that It's just my personal view and it's not that fleshed out, but I've written on it and I'm leaning that way Let me put it that way But I also agree that children's The rights of children as against their parents is not really practically that enforceable in most cases you can't Have a legal system or a court compel a parent to be a good parent So it's not really that practical of a right to have or practical of an obligation to have but it does have it could have Some legal implications Someone else on another thread on Facebook when I mentioned I might do this a few days ago Asked me to address Let's see here. I'm looking on Facebook. It's on Facebook now I'm not sure where the comments are supposed to show up Jeff told me they showed up on the iPhone If anyone's typing comments, I do not see any comments, and I'm not sure why let me click on the comments button No, they're hidden Maybe no one's typing comments If anyone could just type a test comment. I see if it comes up. Oh, could ever get while I see a joint message so Let me hit this buttons. Okay, that just turns the camera around Okay, it's pretty cool feature. I gotta say I See your comments Shawn White just posted a comment, but it's on Oh, now I see it. Okay. Yeah, it's working. So good. So if anyone wants to type a question I'd be happy to address it any libertarian theory issue anything you want me to Go into I'd be happy to one person said they wished in the Tom Woods video that I had Discussed the issue of verbal threats in more detail Let me let me just point out something. I think in the Yeah, thumbs up. Hey Jack my Jack my buddy Jack Chris just joined too Jack you need to try this feature out. It's pretty cool. So The issue of verbal threats, when do they arise rise to the level of aggression Here's how I look at it in the law in the common law and in the civil law the two major legal systems There is a a type of crime called Assault now most people are familiar with the term assault and battery And we use that sort of to describe when someone beats someone else up, but technically in the law The offensive touching is the battery Okay, thumbs up on Jack's point pro thing the An offensive touching is a battery and that can include by the way noxious gas or fumes Any any basically physical interference with someone's body that they don't appreciate an offensive touching and of course including more Serious touchings like hitting someone in the face or stabbing them or shooting them or molesting them or whatever That's a battery assault is coupled with battery because assault is Related to it, but it is separate Assault is defined in the law Now I'm just telling you what it's defined in the positive law Then we can discuss whether that should be also a type of crime in libertarianism assault is The is one of two things. It's the it's the The attempt to Commit a battery now since battery is an intentional action Every time you batter someone you always assaulted them because you have to intend to batter them to actually intentionally batter them So every time you batter someone there's always there's also a salt of that type the first type intention the intent or the attempt to batter someone but if you attempt if you try to hit someone That's a salt, but it's not battery because you didn't succeed, but it's still a salt. It's an attempt at battering someone Okay Now the other question I'm gonna have is can I scroll down on these comments? Oh, I can good So I can see them once it go by that. I'm not talking about now. Hello, Sebastian. I see you've joined I just mentioned you earlier Now the other type of assault in the law is Intentionally put placing someone in in fear of receiving a battery So the example I gave in Tom Woods is the classical example on the law If I have a friend who's sleeping and I swing an axe at their head trying to kill them But I miss that is a salt of the first type It's an attempt at battery and that is a crime and the law and I think it should be a crime in libertarian law, too and I can explain why if I Have a friend and I point a blank gun at them and I pretend to pull the trigger or I pull the trigger and I make them believe I'm about to shoot them But it's really an unloaded gun or it's a fake gun And I know this but they don't then it's not really an attempted murder, but it is still Placing the victim in fear Reasonably placed in reasonable fear of receiving a battery and that is also a crime under under most Western legal systems that I I understand at least the civil law in Louisiana so I Think of those both as types of threat and so the question is why in libertarianism would a threat be a crime And then you can go you can use that to other other cases like stalking, right or verbal threats Why should these or should they be considered? Aggression under libertarianism, and I think they should I actually think the common law crimes of Assault of both types are species of aggression and the common law is right to classify them as types of crimes And the reason I give is something I go into in some of my writings like my my 19 I think 95 if you go to my website Stephen can sell a comm you'll see I have some articles from the Journal of Libertarian Studies and One in the Loyola of Los Angeles law review on a stop-all and a punishment Theory of rights a libertarian theory of rights based upon a stop-all and punishment And I go into examples there about why we would consider assault or threats Including some verbal threats and including stalking to be types of aggression and the basic answer is In my view is that My thinking of rights the the non-aggression principle as first formulated for libertarians Is that you have the right to you don't have the right to initiate force against others But you do have the right to retaliate against others and you see there's a certain symmetry there The symmetry is that force is permissible only if it's in response to force But if someone did not use force against you you can't use force against them If they just insult you with their words, then you can insult them back with your words So there's again a type of symmetry, but you can't use force to stop them from insulting you Etc. There are some interesting side cases or not really exceptions. They sound like exceptions at first But I like I believe for example the the traditional doctrine of fighting words is not completely libertarian. That is that Certain words you say to someone are so provocative that if they sock you in the jaw because they're upset Then it's not really a crime Now I think you could actually score that with libertarian doctrine based upon sort of an implied consent notion so for example if If two boxers going to the ring to box then they both assented or consented to Receiving each other's blows if a girl could lean their head towards her boyfriend to kiss him Then she's consenting towards him actually kissing her So there are certain things you can do that demonstrate your consent Playing football etc.  You're you're you're saying you're saying in unspoken language Let's go fight So if he punches you I don't think it's unconsented to or you could argue that so it's not that fighting words justify violence Or that speech justifies violence is that certain actions and types of speech manifest your consent to Being hit being kissed whatever So anyway, that's a tangent but in any case before I go further Let me see what some of the questions are Sebastian says how much what percentage of the legal categories or principles of the positive law would go away by Implementing libertarian law. I think the answer today would be far different than the answer from 200 years ago say 200 years ago the great bulk of The positive law that is the law actually enforced in most legal systems. Let's say the the great Western systems England Europe the great bulk of that law was was private law. There were some public international law Which I think is also largely compatible with international with libertarian principles There were some so so-called public law like exceptions from private law By private law, we mean all the law that governs relations between private individuals. So that would include contract law property theory law about marriage ownership of children inheritance law Torts and even private crime that great body of law that developed in the last couple of thousand years in the Roman system in the common law system in England Up until a couple hundred years ago Was largely largely compatible with libertarianism I'd say a good at least half maybe 75 80 80 percent maybe more would compatible with what you would It seems like a reasonable working out of the abstract libertarian principles put it that way And the exceptions would be public law exceptions giving the king or the crown certain exceptions the right of imminent domain Exempting the exempting that the the actors of the state from the operation of the law with sovereign immunity The kind of thing that Basquiat complained about So accepting the public law that the state exceptions You know conscription The rules of war things like that So I would say the great bulk of the private law was was very compatible with libertarian principles because it was a spinning out of Intuitive principles of justice and property rights that everyone faces practically on a day-to-day basis and the mission of these courts and The mission of the law finders in Rome The mission was to try to find a resolution to a situation Compatible with justice try to find the just for the right result They didn't always succeed. They weren't always guided by purely libertarian principles There was all there were sometimes legislative encroachments were sometimes pressured by the crown But by and large the rules they did develop over time that were systematized and codified by private codifiers Legislation was a really private but okay. It was a codification of what had gone before Napoleon Blackstone coke Restatements of the law in the US These principles are largely compatible, but since about a hundred years ago We've had legislation has risen to become a dominant if not the dominant source of private law in most developed legal systems so basically the the private under framework of Property rights and private law that was developed more or less in a libertarian way has been gradually supplanted by huge legislative and statutory schemes and regulations Promulgated by administrative agencies of these bureaucratic states that we have now So I would say right now. I mean the code of federal regulations in the US, which is just the administrative regulations and the the the United States code USC, which is the codification of all Congressional legislation that's still in force are huge thousands and thousands and thousands of pages and Those regulate more and more areas of private law and life so we're to the point now where Much higher percentage of what's called positive law the law enforced by the state is sourced in the Constitution or legislation or regulations Rather than the organic private law that is left over from the Golden Age of law. I Don't know the percentage. I would I would I would venture to say Over hat well over half of law Has been supplanted by legislative law of one form or another if not if not 75 percent And I would say well over two-thirds of that legislative law is unjust if not almost all of it So at this point, I would say you you can only give presumptive just status to a smaller fraction of the whole body of positive law Let's say in the West Maybe 20 percent something like that and that's primarily going to be where the private law the common law rules still operate And that's primarily in the state legal systems Which which largely have embodied the uniform commercial code and codes that did codify Largely libertarian common law principles from the past. Anyway, I can't think that's enough on that topic Let me see if we have any other questions. Maybe you have a question. Let me know I can go back for a minute to the question We were on which was the And by the way, feel free to type a comment below I think I am getting comments if I missed one just retype it I don't know if I missed any because I'm getting used to this interface I'm a little surprised at the scale. This looks like I have to hold the phone vertically. So it's not a widescreen thing That's fine a little odd Okay, so we were talking about assault, right and Well, let me let me go into a little tangent this gets a little bit into one issue I've written a bet about with my friend Pat tinsley, which is talks about the the concept of Causality in the law how important it is to have a solid view of causation and causality This does tie in with again why I keep saying that to have a solid understanding of the Principles of justice and libertarian principles. You you really have to be informed by economics and in particular Austrian and in particular Misesian Praxeological economics and the reason is because Mises quite properly recognizes the role of causality, right that we have to we have to recognize that all human action Is based upon a certain understanding of the laws of cause and effect in the world, right? There's a causal realm this was a natural sciences study and then there there's a There's a teleological realm, that's right the the the rules that apply to the study of the consequences of Decisions that human actors make that's what we basically call economics, right? So we have Purpose of action and analysis of that and we have an understanding of the causal laws of nature and the reason this is important is because Mises explains that the structure of human action is to Be an actor who's aware of his status as an actor and the wearer of the The nature of other human beings to the extent that they exist in society with them as being fellow actors with their own purposes you have a purpose in mind and a purpose means an in an end state that you want to achieve Which implies that you have a vision or a forecast or an understanding of what you believe Or think might happen in some time in the future And you think that what's going to happen in the future is not what you want to happen, right? You're dissatisfied you're made as Mises calls it uneasy with the prospect of what's going to happen Okay, so the whole purpose of you the whole nature of human action is that people Have a awareness of their of their status in the world and they have some idea that we're traveling through time And there's something that's going to happen in the future Unless they intervene somehow now the intervention Requires the use of the employment of scarce means in the world, right? But you have to employ them according to their nature, right? So you have to have some knowledge in your mind about the way the world is you have to have some Forecast of the way the world will be if you don't intervene and you have to have some knowledge of what's available to you to make a change Right, so you have to have knowledge about what the causal laws are what the laws of physics are What what tools what means are in your environment that are available to you to manipulate to grapple with to grasp To handle to somehow change the course of events So this is the entire essence of human action. This is what we do. It's breaking it down into a very analytical Structure so we use our knowledge about the way the world is and the way the causal laws are that we think to Imagine what will happen in the future. We imagine possible things that we can do in the future, right? This is where the economic idea of opportunity cost comes in you can only do one thing and The other things that you have to be sacrificed would be the opportunity cost of that So you choose your most valued end and you pursue it by selecting and using means That you believe with your knowledge are calculated to help you obtain The end so this is why causation is is embedded in the entire Understanding of what we do every second of our lives when we act we are operating on some kind of understanding of what causality is And calls the laws okay, so this why causation and libertarian theory is also important when we want to ascribe Responsibility to someone for committing an act that we think is wrong that needs to be protected against or Defended against or punished or retaliated against or condemned is wrong Number one we have to view these other people as human actors that is not Robotic automatons with no purpose it's best to understand fellow humans not as robots but as fellow humans like we are with ends and purposes and then from our understanding of the way our lives work and the way What we've experienced in terms of interaction with others we develop a sense of What their intention? probably is To fully characterize someone else's action you need to understand what their purpose is or their end So you need to characterize them as actors you need to characterize what they're doing as an action Which means there's an end. There's a means employed. There's a certain purpose So you have to you have to try to use what means is called verse to him It's the German word meaning the understanding you have to characterize what they're doing in a certain way So doing that is what the legal system does in a more formal way. For example, that's why the legal system Distinguishes different types of murder, right? So there's first degree murder secondary murder negligent homicide manslaughter things like that vehicular homicide they they they generally They generally characterize the action as the same In some sense that is the outcome is the same someone was killed. There's a homicide the death of a man And it was an intentional action if it was totally unintentional It wouldn't be a tort at all. You wouldn't be responsible for it. You know if an asteroid falls on my neighbor and kills him It's not a tort by the asteroid or by me because I had nothing to do with it And the asteroid didn't have any intentionality no mens rea So it wouldn't be an action. There's no there's no responsibility to be ascribed Likewise if I have a seizure, you know, I'm sitting next to someone at a movie and I might I just have a seizure and My hand just starts flailing wildly and strikes this other person and harms them It's not really an intentional action. So arguably I'm not responsible for that It let's assume it's the first time and I had no reason to think so You have to have some degree of intentionality now the way I look at it is and you have a spectrum or continuum going from fully intentional down to Sort of intentional which is what we call in the long negligence Okay, so if I don't want to kill you, but I'm just not being careful enough and my car accidentally runs into you and I kill you It's partially intentional Not fully intentional the outcome is still the same if there's a death, but the intentionality is lower So my view is sort of you have to imagine the way we classify the the severity of the crimes and therefore the the severity of the retaliation or the restitution that could be a response to that is like a product of the of the outcome and the intentionality and so It's worse to intentionally murder someone than to merc tend to accidentally kill them So you're because your intentionality is like one thousandth of that of the murder or something like that So you have to take these things into account and that's roughly what the law does and having a lower lower punishment For someone who accidentally commits homicide As to someone who commits first-degree murder and it's why second-degree murder and manslaughter Don't have the severe penalties as first-degree murder And I think that makes sense and I go into that in that causality article and also in my punishment proportionality article if anyone Okay, we have another question Tony Vincent. What do you think of the HHH physical removal service? That's very funny. There's a Facebook site called HHH, which means hoppa physical removal service just kind of Not sure if it's making fun of hoppa or making fun of his critics. I can't tell it's just a funny irreverent site Sort of riffing on a common hoppa made about private property communities private covenant orders Having to exclude certain types of people. I don't know what I could what can I say? It's private. It's a free world people can Riff as they want. It's I think it's sometimes kind of funny. I Don't know who's behind it by the way, and I don't care Sebastian, do you know Sebastian has a question and I'm gonna stop this shortly because it'll have been 25 minutes already I'll go a few more minutes. I don't do much past half an hour Do you know of any further research on your blog post the Catholic Church is a voluntarily funded elective monarchy and therefore not a state What potential avenues for the propulsion see here? Let me stop there because I can't read all that right now Look, I don't have a lot of detailed study of the Catholic Church My my only point in that post which was from a few years ago in the Lou Rockwell blog. I believe I Notice I'm talking fast again. I'm gonna slow down My only point was that all the criticism of the Catholic Church Not the recent criticism about these pederasty scandals. That's that's a different matter Those are sound like legitimate crimes that That should be classified that way and dealt with a certain way but People criticize the Catholic Church because it says you can't use Contraception or because and it and it and it and it So-called coerces people with the threat of hell if they don't obey certain dictates now as a as a libertarian I don't give that any credence whatsoever. It's ridiculous people are free to leave the church They're free to do whatever they want if they want to believe those teachings they can They don't have to so it's not an act of aggression. It's not an issue of libertarianism And If that's all the the state did to me if the state just hectered me all the time Told me I had to pay my taxes or I would go to hell Right, then I would just ignore them. They wouldn't be a Criminal organization then I actually would be happy to have an organization that that that Demanded tribute on the pain of condemning me to hell in the afterlife because I would just ignore them And I wouldn't pay any taxes The state does more the state actually threatens you with going to jail in this life If you don't pay taxes, that's real aggression So I think we need to focus on what real aggression is and my only point was it's kind of amazing that this The the Holy See Vatican City, which is which isn't recognized as a sort of actor under international law Not quite a full state, but has some Treaties with it so it's seen as an international actor It's kind of interesting that the Holy See the Catholic Church Is in effect a state within a sense over I don't know about a billion Quote-unquote citizens right Catholics around the world now their citizens of their own states really but they pledge Alleges to the Catholic Church to give tribute to it. They pay it. My point is they whatever they pay is paid voluntarily and As far as I know in today's times the Catholic Church doesn't commit any aggression whatsoever except for the actions of the priests and With the young altar boys Which is a different issue I Was an altar boy for three or four years and I don't recall anything anything bad happening. Maybe I've blinked it out I'm just kidding. It was fine So the Catholic Church is basically a quasi state with a billion citizens Which doesn't impose any taxes doesn't cause any wars Doesn't put anyone in jail for anything doesn't outlaw anything with a threat of of any kind of physical force So that was my only point that it's in a sense the most libertarian state in the world right now Okay Let's see what else we have here Gotta comment no taxes in hell sounds decent That's true, and that's where all the fun people will be right Oliver Westcott has a question Do you see a practical difference between a world of states and a world of private homeowners associations? Absolutely Millions of differences Primarily a Difference in terms of justice right states are not just and private associations would be just So that's the primary difference in terms of justice in terms of ethics But in terms of the way the world would look it would be greatly different for several reasons number one You would have instead of 200 states you would have Tens of millions of these associations so the numbers would be so much greater and the size would be so much smaller Right, so that's a huge difference right there and their purpose would be to satisfy the customer. It wouldn't be to You know set up a propaganda organization whose whose function is to exist and survive and To exploit the people As much as possible, and I would recommend you look at Hoppe's great book on banking in nation states a Great article which is in the recue at the review of Austrian economics. It's also in one of his books I think it may be in Economics and ethics of private property or in the Great Fiction. I forgot which book it's in He taught he discusses there the process by which the state gradually monopolizes areas of human life to exert more and more control over Over the the population that it basically is exploiting You know it sets up control of money roads defense police the law Even language in some cases right and and education to education of the children So it does he seems insidiously Whereas a homeowner association would have no ability to monopolize anything like that so yes There'd be any number of differences there could there could arise Private associations or covenant communities as Hoppe calls them that you wouldn't personally like But you know if you stayed there you would actually be consenting to the rules And if you didn't like it you could join one of the other 10 million in the world So it would be a completely different landscape much more liberty much more prosperity much more free markets much more freedom and You know corruption as we know it now Would be orders of magnitude different and less in my in my view I Think I'm going to shut this down now. This was an experiment. I hope it didn't go too badly I think it was okay next time. I'll use a proper microphone. I'll just get my phone charged ahead of time Like I said in the beginning I could actually use this. I've tried it on my phone This is the one I use my audio technique for my computer and it actually works on My iPhone if you have an adapter Which I have you have to have a USB adapter, but the problem is this adapter has no power a Little power plug-in so you can't have power going to your phone at the same time So next time I'm going to try a proper microphone Anyway If this works out, all right, we'll try it again. I hope everyone enjoyed it Thanks so much. Feel free to post any questions and maybe I'll get to them in another FaceTime Facebook live Video. Thank you. Bye. Bye


All right, it's 9 o'clock. So I think we'll get started with the next session here. So thank you all for coming to join us. Hopefully, we have a topic that everybody here finds of interest. We're going to talk a little bit about building a cloud environment with open networking and software defined storage technologies. My name is Paul Speciale. I'm the VP of Product Management for Scalely. I'm actually here on behalf of our CTO, Georgio Regni, who couldn't make the trip. But I'm fortunate to be joined by Nolan Leak, who's the co-founder of Chemos Networks. So we'll kind of co-present this session here. And we'll kind of take you guys through a little bit of the problem statement and description of the various technologies and how we feel the two combine to make a synergy and make life easier. OK, so as a mini agenda, we do want to make this interactive. But we'll kind of set up the talk here with a little bit of a couple of slides about the data center, how we build a big storage system for storing hundreds of terabytes or potentially petabytes of data in an open stack environment. And I'll have Nolan talk a little bit about open networking, what it is, what are its key capabilities, and then again, we'll kind of close with some of the advantages and ask you to participate. So I think much of this is very obvious to us, but a couple of things I want to throw in. We're obviously trying to build new data center infrastructures based on kind of the technologies that we know the giants are using. And that's one of the reasons why OpenStack is around. Certainly one of the things it introduces is a lot of variables. We're going to have lots of different applications, hopefully running in OpenStack. That's really sort of the core goal, is to support our businesses so that we can run applications and different kinds of workloads. That's going to have a huge bearing on storage infrastructures and on networking infrastructures. But moreover, one of the things that we believe is the problem is that there's lots of disparate management frameworks that are starting to appear. And we'd like to make that common. So one of the approaches here is to make this very open and to be able to leverage kind of common management frameworks, things like Puppet, Chef, Ansible, and all of that. From a storage management perspective, which is what we're focused on, we've certainly seen the cloud impact data storage at scale and also at type. We're seeing lots of explosion in virtual machines. That means you need virtual machine storage, you need file storage, you need object storage. It just creates a big mess, and ultimately, one of the things that we feel it results in is an explosion of storage silos. We'll talk about a solution for managing the big unstructured data. That is a scale-out, typically addressed now by a scale-out technology, which requires very flexible networking technologies. So that's kind of the heart of what we'll talk about. Big storage solutions today, people are certainly very interested in object storage. In the world of OpenStack, that means Swift, right? So Swift provides the verbs for doing large-scale puts and deletes and gets against data, stored as objects in the cloud. But there are competing technologies. There's, of course, Amazon as a growing force. Their S3 spec is something that we're tracking and a lot of people are embracing. Ultimately, we feel that this drives a big increase in complexity of network typology and also for managing these infrastructures. So that's where we feel we can come in with kind of these open platform technologies to really make life simpler. So I mentioned the fact that distributed storage is now becoming kind of the normal model. So what does this mean? It means scale-out in two dimensions. I may need my application to talk to various protocol services. REST protocols are now very common, of course, for accessing big data. That's where Swift comes in, certainly. But the need to address an incoming larger and larger load may mean that I need to dial up the number of interface servers, the number of protocol servers. In our model, we call these connectors. They can serve NFS traffic. They can serve REST traffic. But the key is that I need to be able to scale them out as my load grows over time. Very commonly in the Swift model, we have the notion of object storage demons or storage nodes. As capacity needs grow, I want to be able to add these incrementally and sort of grow the capacity of my system. And all of that, of course, is glued together by an expandable network fabric. So what's the heart of a software-defined storage offering is really the intelligent storage services. This is really the glue, right? So the model these days is I don't want to buy hardware appliances or arrays that embed the software or the intelligence for storage management. I really want data durability services to be in the software. I want things that route around failures when they occur. If a drive fails, it shouldn't be an abnormal condition, right? In the old world of RAID controllers, as soon as a drive failed, some administrator received an alert and you had to go hurry in there and repair and replace the disk. That goes away now. So we'll talk about how we do self-healing in the face of these types of failures. And then, of course, growth should happen without disruption. I want to be able to add resources on the fly. The service remains available. And moreover, I want flexibility of choice. I want to be able to choose what hardware I run on in terms of both the server side, the storage side, and also the network platform. And ultimately, certainly users want to be able to manage these things over APIs so that they can monitor the health, the performance, and also to do management, to do provisioning of these systems over APIs from all their common tools. Okay, so with that said, there are some challenges in distributed storage. Certainly management is one of them, but the two I want to point out that are very, very relevant to the choice of networking technology that you select are really failure domains and data proximity. So these are data placement considerations. So as you move to a distributed storage system, you start having considerations about where you place the data. So again, this isn't the model of having a RAID controller that manages eight or 10 drives and all of those drives are local. What we're doing instead now is taking a big file or a big object and distributing it across the system. And there's really two considerations that drive that. The first is the notion of a failure domain. I want to be able to take either replication chunks, multiple copies of a file, and distribute those across my servers, my disks, my racks, and ultimately, I might even have multiple data centers that I need to think about placing these chunks across. Modern systems currently support things like replication schemes that are variable. So that lets me dial in how many copies of an object I want to store. More sophisticated ones implement erasure coding. So this is a variable parity scheme where rather than storing multiple instances of an object, I'm actually doing a parity scheme and I'm breaking the object up into chunks, storing some data chunks and some parity chunks across these different failure domains. So in the example here, if I have four data chunks, each representing a replica, I want to ensure that they're all on different servers, on different drives, and potentially on different racks, right? Because the racks might be a failure domain of their own, given how power is distributed. Okay, so that's dispersal of the data so that I can ensure that if I have a failure, I'm not impacting multiple copies or multiple chunks at one time, but that fights against the other need that I have, which is data proximity, right? So in order to get performance, I need to be able to access the data rather quickly, right? And this usually means that one of my protocol servers, a REST server that's fetching data, needs to be fairly close in terms of number of network hops to the actual chunks. So we'd like this to be bounded, right? And this becomes a problem as I scale up the number of racks. Traditional topologies really start increasing the number of hops that I need to cross in order to get the data. So maybe with that, I can hand it to Nolan with some comments about the networking side of this. Thank you. So before we get into how we solve those challenges that Paul brought up, I'll give a brief overview of Kemal's Linux. Who here is heard of Kemalus? Okay, who here has used the product? Okay, fewer, so I'll get into how it works a bit. So we're best known for open networking, and so that's the idea that you don't buy servers with an OS on them anymore, right? You no longer buy a Spark server with Solaris, right? You buy an HP server running RHEL, or you buy a Dell server running Windows, right? But in networking, it's still kind of common to buy everything together in an appliance, right? You go buy your Cisco switch and it comes with a Cisco OS, and if that's not working for you, well, you're just kind of out of luck. So the idea of open networking is to decouple that hardware from the software. So unlike NXOS that only runs on Cisco switches, Kemalus Linux runs on switches from seven different hardware makers, and each one has a wide variety of different kind of switch designs. So you can pick one that really does exactly what you need from the kind of vendor you want. Maybe you want global reach from a large OEM, but maybe you are building a large-scale data center and maybe you're okay with a kind of smaller OEM because you get more appropriate pricing or whatever. So it provides that flexibility. And the other kind of difference from what you may be used to in more traditional switches is that it really is just Linux. Almost all network OSes today have a Linux kernel in them, but you would never know it, right?  You can't use open-source tools on it. The interaction through it is either through CLI or some sort of proprietary that switch API if they give you one. So beyond that, it is a switch, right? It does VLANs, VXLANs, bridges, routing, protocols, all the kind of normal stuff you'd expect. So you don't have to learn some new protocol like OpenFlow to manage this. Like all the concepts you already know from networking still apply. It's just with a slightly different interface to it. So there's a lot going on in this diagram. So I'll try to break it down. But so Paul talked about kind of the locality and the tension between wanting the replicas to be distributed widely across the data center, across the different racks so that if you lose an entire rack, you don't lose multiple copies. But at the same time, you want the data to be co-located close to each other for write so you don't have to replicate across a huge distance and also to the consumers of it. So they don't have to go talk to some server that has very low bandwidth to it because it's far away. And so to facilitate that, we use a topology called a factory. It has some other names as well. But the basic idea is, unlike your kind of traditional network where you have a pair of core switches and then top-of-rack switches connecting up to it with oversubscription through the core, we have a larger number of small spine switches. Usually in a full mesh topology, you would have half as many spine switches as you have top-of-rack switches. And the interesting property that that topology gives you is when the techie term is full bisection bandwidth, but what it essentially means is you have the same amount of bandwidth to a server 10 racks over as you do to the server directly below you in the same rack. So now you no longer have to think about the network location of a server or disk because they're all the same. And so that allows us to resolve the tension between wanting locality but also wanting distribution by removing locality as a constraint so then we can focus just on distribution. There's no longer any tension between two. So the way we realize this is through building an IP fabric, a layer three fabric, usually with protocols like OSPF or BGP, typically these days EBGP. And if you're familiar with networking, you may be thinking, well, I mean, technically, I could do that with any switch. But as a practical matter, we've done some things that make this far easier and far more practical, both for technical reasons and for non-technical reasons. The first is that that open supply chain means you're no longer paying obscene prices for your switches. You can shop around and get a reasonable price, which means you can afford to have a lot more switches. What enables this extreme amount of bandwidth is the fact that you just physically have more switches. So you have more capacity. And the other thing, the other challenge you might run into is then, if we have more switches to get this more bandwidth, you have to manage these more switches. So if you have your traditional switch, you'd have to SSH into each one and upload a config file or build some tool that kind of manages templates and blows them out to various switches over SSH pretending to be a human, right? And so we'll get into kind of how we can help out with that with automation tools in a second. And then the third is that we've implemented some technologies that make this a little easier. I don't want to get too far into the gory details. I'll be getting into like config files and the real gory details on Thursday in a different talks. If you want to see that, come for that one. But the basic idea is instead of having to manage a huge number of IP addresses for all these little links, we give you the ability to assign one IP address to each switch and have that be the entire config. And so this makes it super easy to write a single config, usually about that long, that you can then just blow out across all of the switches. And the final thing that's kind of cool here, and this is maybe hard to see. So you can see the <IP_ADDRESS> IP address floating around. So in this model, that's the connector service that Paul was talking about. And this is kind of what the client interacts with. And then it in turn goes and talks to all the storage servers. And so you want several of these for availability and for distributing load. And so what we've done here is we can configure something called anycast. And the idea is, since we're using a routed network here, all of those connector nodes can announce a IP address into the fabric. And so that way anytime someone asks for that IP address of the connector, they get routed to the closest one, automatically by the network. And if that fails, they will be routed to a different one. And so we implemented some technology around that. This is not a trick we invented, right? Other people have done this in the past, but it in the past has had a problem which is that the flows are distributed to all these servers based on a hash of the source IP, desk IP, source port, desk port, and some other stuff as well. But the problem with that is, if one of these fails, you were hashing across four servers, this hash function is stateless. It doesn't know which flows are going to which servers. So if one of those fails, and now you're talking to three, all those flows get redistributed at random to all the servers. And so if these are TCP flows, which they are in this case, that causes broken connections. So what we did is implemented something we call resilient hashing. And so the way this works is, if you have those same four servers, if one of them fails, only the traffic going to that failed server is redistributed to the three remaining servers. And so that way, only the traffic that was going to be broken anyway, because it was going to a server that failed is affected by the outage. Okay, so we were talking earlier about the config management challenge of all of these large number of switches. So if you talk about a big deployment and you've got hundreds of switches, that number is fairly small actually compared to the number of servers you probably have, because you probably have thousands of servers. So in terms of managing things, we should look to how people manage very large number of servers to draw lessons that we can then apply to managing large, but smaller numbers of switches. And so in this case, instead of learning lessons, we just wholesale stole the technologies people have developed and open sourced for this. And so there's lots of great tools out there, Chef, Puppet, Ansible, Saltstack, they're more, people roll their own. And because all of these speak and they're designed to deal with the common language of Linux, the Linux commands, Linux APIs, we can just reuse them. We don't have to port them. We don't have to do anything. In fact, when we were a very small company, often we found out that one of these tools worked on our switch because one of our customers just did it. They downloaded it, installed it, and said, hey, it works great. And similarly, they're monitoring tools, collectee, graphite, Nagios, all of these tools that have been used for years, decades, even in some cases, on servers are now applicable to switches. And I don't know how many people here have used SNMP, but all of these tools are a huge improvement on SNMP. And I think that's it. We wanna throw it up in four questions. Yeah, and I just add that the level of scale that we're starting to see for managing some of these large clusters starts ranging into hundreds of servers, thousands of disk drives. So certainly the collection of statistics and logs is becoming a problem at another level of magnitude. So embracing things like elastic search and log stash, that seems to be kind of the paradigm that users want us to take. So that's the technology that we're starting to embed. So it's a very open approach. We actually use Saltstack, Chef, Puppet for deployment, but you can see that sort of the synergy starts getting created when you put multiple technologies together that work this way. So we'd be happy to take any comments, any feedback from the audience or, okay? Question? Yeah, so the question was, are we trying to maintain state, network state behind something like file services, right? So I think the networking technology that we're talking about here is both the back end fabric and the front end. If you're talking about front end connectivity to something like an NFS server, the technology that you use could certainly could be applied here, right? The technology that you discussed, but really what we're talking about is sort of simplifying the back end fabric, right? The management of these large topologies that glue together hundreds of storage servers and lots of protocol servers.  So you're gonna have standard technologies that do load balancing and failover on the front end servers. Yeah, so I mean, when we were talking about anycast earlier, the idea there is, you know, if I'm a client, I would connect to a single one of these connectors. If it fails, I would then have to reconnect. But, you know, most storage protocols expect to be able to reconnect and then reissue the pending IO. So it is kind of designed to handle transient failures. Right, so it doesn't change the nature of NFS retries and timeouts in that respect, but there are stateless protocols now, like REST, which you can just naturally load balance and retry a question. And the great thing about stateless protocols like that is then, you know, with anycast trick, you know, it's active, active, active across all the servers, right? So you just kind of get connected to whichever one happens to be closest. So if the clients are evenly distributed and the load gets evenly distributed across all of them. Right, so if you have an S3 protocol server or a Swift protocol server, you can run, you know, a dozen of them, access any resource from any of them, and if one of them fails, there's no interruption to the service. Yeah, and convergence is sub-second. Well, I mean, on the back end, the storage software is aware of the multiple replicas. So it takes care of that. It's the clients that may not be aware. They think they're talking to a single service endpoint. And so that's where the kind of cluster comes in and hiding the cluster behind a single IP address and kind of trying to load balance the traffic between or the connections between these various... And we'll provide back end redundancy with multiple paths to the different nodes. If there's a failure of a node, there's somebody else that can take over for that. So all of that sort of built into the SDS layer. Yeah, okay. Anybody else? All right, so Nolan and I will stick around. If you have any questions for us more one-on-one, please come up and chat with us. And we have a booth as well on the show floor, as the accumulist does, so there's lots of access to us. There's also a paper available for download on the Scalody website, as you see here on this URL, that talks about kind of the nature of the discussion we had here, a little bit more detail on some of the underlying technologies. So thanks very much for your attendance. Thank you.


Hello, and welcome to another Tech and Talk, Diane Mueller with Red Hat, and I run the OpenShift Commons and do a lot of stuff in the cloud native space. And I've been doing these Tech and Talks for about the past three months now and trying to bring in interesting folks from different aspects of the cloud native world and Kubernetes world. And one of the people that I've most admired for a number of years is Ann Curry, who's with us here today. And she's been working with the gang at Container Solutions and doing a lot of research on cloud native use cases. And I was gonna get her to unravel the mystery of cloud native today. So, Ann, if you could introduce yourself and give us your presentation, we're gonna have a little Q&A at the end of this too. So stay tuned to the end. Hi, thanks, Diane. So my name is Ann Curry and I've met Diane at many conferences in the past. It's always been a pleasure to chat about what's going on in the industry. So I, like Diane, I've been in the industry for quite a long time. So I've been around for more than 20 years, which means that, as an engineer and as a manager, I'm doing various things, which means that you end up seeing lots and lots of new ideas and fads of fashions come and go and then often come again and then go again and then come again. So I was extremely interested in the phenomenon of cloud native. So I've been involved in containers and orchestrators and investigating them for various and involved with them in the startup world for a couple of years. And I was very interested in the way that cloud native was pulling those concepts together, containers and orchestrators and microservices. And I wanted to know a little bit more about it. So the past six months, I've been working very closely with the folk at Container Solutions and they've been sponsoring and cooperating with me on producing a book, which is what's going on in the cloud native world. So yes, for me, cloud native is not a very clear concept. There's loads of things going on in it and it's really not clear what people mean by it. And in fact, I think if you talk to 10 different people, you'll get 10 different meanings of cloud native. And I really wanted to try and pull it down.  I like to have things to be a bit clearer. I like to have things clear in my mind, at least like, okay, there are five meanings and different people mean this by it. So what I wanted to do was kind of ask the question, what is cloud native? And not just from vendors, because as a startup I end up spending a lot of time talking to vendors, I ended up and I used to work for a vendor, but I've also worked for customers and users of technology. And in the end, there's often quite a difference between how vendors think technology is going to be used and how customers actually do use it and what they're interested in. And I think cloud native is one of those things where there's potentially, there's the possibility of quite significant disconnects between what we as academic type vendors and researchers think about what cloud native is going to be used for versus what is it actually used for. And so that was really what I wanted to go out and talk about. The where I started from was the CNCF, the cloud native computing foundation definition of cloud native, which is container packaged, dynamically managed and microservice oriented architectures. And that's quite good. I mean, that describes, so that describes the how, doesn't it? That describes a set of tools, which is containers, Docker or equivalent, but probably mostly Docker. Dynamic management is really orchestrators like Kubernetes or Swarm or Mazos. And microservice oriented is just on microservice architectures, distributed systems, small decoupled, single use applications. And that is all cool. And there's no doubt that that stuff is all very cool. And I've used it myself and I found it very good. It's a really, really interesting set of technologies together. But being cool to my mind is not sufficient reason to use it because they're also quite difficult technologies to get your head around. There's lots of stuff for people to learn there. Lots of training would have to go on. Lots of potential rearchitecture. It's expensive. And it kind of cuts against what a lot of companies already have, which is a monolith. And we didn't choose to go with monoliths because we were fools. We went with monoliths because they were easier to operate. They were easy to manage. They were easy to develop in the first place. So you don't necessarily want to throw them out the window just because some new technology looks cool. You need to have a more definite reason for using that technology. So what I was interested in is what is the reason? Now, theoretically, when I look at those technologies, and I'll talk a little bit more about this as we go on, when I look at the technologies of containers and orchestrators and microservices, I can see three potential reasons why companies might use it. You can definitely use it to go faster, by which I mean increase your development speed. So feature velocity. Minimize the time between an idea coming into somebody's head and actually being in front of customers. That's certainly one use case for these technologies together. Another use case is scale, which is that you can have much, much bigger systems. So you can effectively, by scale, I mean that your systems can potentially handle more users in more geographic regions without impacting them. Without impacting your SLA. So that's from by scale. And also margin, they have, using these technologies together could have the benefit of, and theoretically, certainly through it, theoretically, and I've seen it, be able to cut your hosting costs quite significantly. But the interesting thing about these three use cases is that I wouldn't approach them in the same way. I would use cloud native, I would use containers, I would use orchestrators, I would use microservices to attack all three of these goals, but I wouldn't do it in the same way. So that's quite interesting. So what is it for? Is it for these three goals? If I wouldn't actually use the technologies in the same way to achieve them? And that was the question that I had in my mind when we started working on this book. And we really wanted to go out and interview a lot of people and find out what they were really using for. It was all of those use cases, perfectly good use cases. In advance, I didn't know which would be the one. In fact, I spent two years of my life basing my assumptions on margin being the thing that people were interested in, but it turned out it wasn't. Which goes to show that you can't assume anything. So if you go to the CNCF, they have a definition for cloud native, which is distributed systems capable of scaling to tens of thousands of self-healing multi-tenant nodes. Now, to me, that implies, or I strongly infer, that they believe that the use case for cloud native is scale because tens of thousands of self-healing multi-tenant nodes, that's as far as I'm concerned, that's all about scale. You know, we haven't said it's cheaper. They haven't said that it's faster to deploy things. They've said that you can run really big systems. So they seem to be nailing their colors to the mast of scale being the reason why people will use CNCF, not CNCF, cloud native. But I really wanted to know whether that was actually correct. And so I went out and spoke to quite a lot of users. Now, when it comes to conferences, a lot of the users who are ahead on cloud native are hyperscale users, like Google or Facebook or Netflix. And when they talk about cloud native, they are generally talking about using it to achieve scale and to cut their hosting costs. And that would tend to point you towards the CNCF definition in my mind, you know, it's all about scale. But actually, you know, there aren't that many of us who are huge hyperscale companies. That isn't the normal way. That isn't the average company. They happen to be big companies and they happen to be companies that have a lot of money and they happen to do companies that speak a lot at conferences. But on average, most companies are not hyperscale. Now, I didn't want to go out and talk to, well, I did actually. I talked to quite a lot of startups and quite a lot of medium-sized enterprises. I mean, I still mean that they were global, millions of users, enterprises, but they were not as big as Netflix, for example. And I asked them, and I went out and found people who were using a cloud native approach and maybe and often have been for years and years and years before it was actually called cloud native, but they were using containers, they were using orchestrators and they were using microservices. And when I asked them why, they often came up with an analogy called OODA loops. Well, with a statement, which is we wanted to move faster. We wanted to move faster and we were very inspired by work like Captain, Colonel John Boyd during the Korean War about OODA loops, which is all about going faster, deploying faster, making changes. And his famous quote was speed of iteration beats quality of iteration. You just need to, if you want to win, if you want to be successful, you just need to take a lot of shots at a goal. If you want goals, take a lot of shots at goal. So I thought that was very interesting. So they, everybody I spoke to who wasn't hyperscale, which let's face it, is the vast majority of us, where they were using cloud native, they were using it for feature velocity. They're using it to go faster. They then subsequently always used it to scale better and to reduce their hosting costs to improve their margin. But that wasn't the reason why they had chosen it. The reason they chose it was in order to put features live more quickly. And they made architectural choices that were slightly different to the architectural choices you'd make for scale or margin, as a result of the fact that actually that wasn't their primary concern. Their primary concern was to go faster. So my conclusion from talking to all of these folk, this is what, this was companies of all sizes, really up to, but not including hyperscale, was that they were really interested in cloud native for speed, not for scale or margin, unfortunately. Well, that's probably, yeah. There we go. Yes, and I learned from my startup, not from margin. But I did conclude that CNTF were right about, well, they were mostly right about the technology. They were right. Everybody was using containers. Well, actually the people who were on Windows were thinking about containers, but hadn't quite moved there yet. But containers all contain a like function, orchestrators, microservices, but something that isn't mentioned by CNTF. I think just because they're assuming it, but I hate assumptions. I like to make things explicit is vast automation. So in the same way that's, that's got to prep a wall before you paint it, you've got to have really good automation in place before you can effectively use containers, orchestrators and microservices to live on any of those goals.  And of course, I mean, I guess this is kind of implicit in the name, but I don't think it's, again, I think you always need to be explicit. Everybody who was doing this successfully was running on flexible infrastructure, by which I mean cloud. Now, you can build your own cloud, but nobody was doing that. I think the hyperscale folk sometimes do that, sometimes don't. I mean, Google have, Netflix haven't, Apple, Facebook have, but not everybody. Even in that hyperscale group, we've got one key player who was running on AWS. Everybody I spoke to was running on a cloud. They were not often, they had started building their own private cloud, but realized that that required an enormous amount of energy and effort from them. And it was not a business differentiator for them. So for example, I spoke to The Financial Times, who are probably the most successful online newspaper at least in the UK. They started with their own private cloud, but moved to AWS because, and actually started to use more and more AWS services because they realized that that was, that was just far better for their business. There was no need for them to reinvent that particular wheel. So everybody was using it for going faster. What, how were they doing that? What were they, what particular aspects of these technologies that they're using? Well, for containers, it was really, the containerization makes it easier to automate your DevOps handovers. So fundamentally, they've all got good value out of containerizing applications in order to automate the DevOps handovers really, reduce friction there. Orchestration, although orchestrators are phenomenally powerful tool in production for minimizing your hosting costs and improving your scalability and resilience. Primarily, that was originally why people were using them. They were really using them now in order to go faster, which means that they were really using them to get their applications into production faster. So they were using things like rolling updates with Kubernetes. And that was quite interesting. If it slightly feels like using a sledgehammer to crack an arts, I'm a bit disappointed. Eventually, everybody did then use their orchestrators for what they're actually designed for, which is improved runtime automation. But in this context, really, they were using their orchestrators to get things deployed more easily. Microservices, again, massively powerful potential in there as an architecture for scalability and for cost cutting. But initially, people were using it in order to parallelize their development so that rather than have a large team all chipping away at one monolith and constantly getting into it in one another's way and having an awful lot of code to learn, they were breaking everything down into smaller packages that were easier to learn and where multiple teams could be working on those packages simultaneously and then deploying, provided they had solid APIs. So none of this is easy, but they were doing it and they were getting good results and they were very happy because they could deploy much faster. And I saw people, so the FT, for example, they improved their deployment speed by a factor of 10,000. Now it took them five years to do that, but they did do it and they were very happy with improving their, speeding up the deployment by a factor of 10,000. So there's definitely, it's a lot of effort, a lot of pain, a lot of investment that they had to make to get to this point, but the payoff for them is absolutely huge. They really cared about that. Automation, obviously, you can't do these speedy DevOps handovers without automating those speedy DevOps handovers and cloud, it's easy to forget that 10 years ago, you might have to wait six months for a new machine to appear and that really slowed you down quite a lot. If you can just turn on a new machine, get out your credit card and you've got your new machine there in the cloud, that again causes you to go a lot faster and all of these folk had moved into the cloud more or less for that reason. So that was my conclusion that actually there are lots and lots of different reasons why you might want to use cloud native. It certainly can and does deliver feature velocity and scale and margin, but for smaller businesses and non-hyperscale businesses, they all seem to be seeing it as delivering speed primarily and the others is nice to have. But I don't know, Diane, what's your take on that? Is that what you're saying? I agree. It's interesting to see what the research came up with because we are, we do look at the Ubers, the Facebooks, the, you know, everybody, the Googles out there and we look at them and Netflix as being the gods of cloud native and of cloud and their use cases is at Red Hat and at OpenShift, we get to see lots of other people deploying cloud native stuff. And what kept popping up in my mind while you were talking was the automation piece. And I came at cloud through platform as a service, the thing formerly known as POS, now as, you know, container application platforms or OCP is what the OpenShift container platform. And really the reason that I loved POS when it first came out was it was so automated and it gave you consistent environments in which you were deploying things. And then as, you know, the LXC technology and the container technology morphed into what became Docker, what became Moby, what's now OCI and Creo and Rocket and all this other container stuff, it's just getting more and more ubiquitous, I think, out there in terms of that's how we package up our microservices and build our applications. And for me, that is what brought, to me, it's what brought the joy back to coding, all right? Because what I didn't like about coding, I got out of coding, I'd been as DBA and assisted men then I went into Python and everything. And then I got out of it and became like, you know, do it, did some R and D stuff in product management because I didn't want to be an ops person, right? So this whole DevOps thing, like I was tired of having to manage my entire stack and tired of throwing stuff over the fence and then getting it thrown back. So it was that whole containerization and this whole movement towards automation that really reinspired me and reinvigorated me to basically continue to code and to get back into coding again and to really help push forward sort of this cloud native thing. So the cloud native for me is just a rebranding of this movement towards automation and towards the paralyzed dev that you talk about a little bit with the microservices. I have been at a number of conferences that you've been at and I've heard like probably 20 different definitions of what cloud native is. But to me, it's never been about the scale. It's always been about the automation and the breaking down of the application into more manageable packets of development processes and the rise of things like Jenkins and other automation tools for CI CD that really change the nature of development. So I think the mystery here is not that it's not at scale. It's not just faster, it's the ease. So I don't know how you add that into the definition but it's the ease that this automation brings to the table and as someone who's managed large projects, programming efforts and initiatives, the ability to compartmentalize the different pieces of it so that you can develop in parallel. You can push out patches and you can do these things that before with a monolithic application, just you had to shut off your service and roll the update out. So it's interesting and I think as we hear more use cases I would expect that piece to be teased out too, not just the faster, I mean, it's an aspect of faster. Yeah, yeah, it's in some ways it makes me a little sad because although I really like the speed aspect of it and that's all very good, I was very keen on the green aspects of cloud native. I really thought that that was what was gonna take off because it's cheaper. You can run your systems more efficiently and they'll be much, much greener and they'll be much, much cheaper to operate. But there was a bit on the greener check box but there are some folks up in Iceland who are running a cloud that's all based on, I can't think of their name but it will come to me at some point, steam and hot water from the earth is running all the energy that runs their cloud. So there is a green cloud out there and they're wonderful guys who are doing that. But the green aspect, that brings up another whole topic. I can remember going to somewhere in Nevada to somebody's server farm for a cloud when it really got brought home how not green clouds are like the physicality, the huge air conditioners, the amount of energy that it takes. So it's only greener to me that in the aspect of saving money the color of money in the US, not in Canada because it's color and lots of multicolored here but the green aspect of cloud is really just about the savings thing. And I don't think many corporations unfortunately really are giving paying enough attention to the green aspect of it. So cloud is always a little, I think it's one of those metaphors that we tagged on somewhere in the marketing of these huge server farms not intentionally, but it makes them seem ethereal like the lightweight. Like there is no there to the cloud when you upload your 1,000 pictures to iCloud and the tangibleness needs and the green aspect of it really should be brought home a little bit more. And I wish that it had come up in your survey but would not have expected it to. No, people don't. And in fact, actually the interesting thing. So I've talked quite a lot of conferences in which I mentioned the stats that data centers alone put aside all other energy uses in the tech industry data centers alone use 2% of the world's electricity which makes them about the same amount of energy data center alone is about the same amount of energy as the entire aviation industry. And whenever I say the shocked nobody, nobody in our industry has any idea, but that is the case. That's all good. And I remember, I think it was the super map facility in Nevada that we've been into and it was beautiful. It was like going into a Terminator movie.  But it was really cool and sort of like when we were talking earlier about getting an MRI it was the technology would be like walking into like an amazing technology place. And but it was the external, they had huge Mack trucks with air conditioners that were pulling up to the sides and that when the air conditions broke they could just ship in another air condition because it's just the heat that they were producing. And I'm not saying there's anything wrong with super map or anything. That's just the myth that we have that the clouds are green or we bought into that they're ethereal, but it's quite interesting. And I also think like for me to bring it back a little bit to the mystery of cloud natives is that the CNCF is doing a great job of promoting a lot of the projects and the toolings and things that we need to make these applications fly in the cloud and to host them. And so it's been quite a very good thing to have them bringing all of them together and trying to get the message out about native stuff. And I'm really looking forward to when is the book that you're doing getting published? That's- Oh, well, it's all written. So I'm hoping that it will go and it's gonna be available for free as a PDF on the Container Solutions website. And then we'll probably have a physical book as well almost certainly for sale on Amazon. But free PDF. Let's get the PDF and read it. It's much greener. It's much greener than printing it. Yeah, I think that's a wonderful thing. And also hopefully it'll be available when we meet again, hopefully at KubeCon in Austin, Texas in December of this year, which is coming sooner than we think. And that was another interesting thing is the CNCF is, I think you were invited to be one of the reviewers for the CFP process for the Berlin event in February. And I just finished doing being a CFP, a call for papers is what CFP stands for, reviewer of the KubeCon entry. And it went from let's say 400, I think in Berlin to just under a thousand submissions. And it was probably the most eye-opening thing I've done in a long time is to get to see all the different topics that people were bringing up that were cloud native. So I'm sure Container Solutions submitted some. There were tons from Red Haters. There were tons from all other, all walks of life. There were so many new projects and so many new tools out there. I'm wondering if there's anything that you're seeing on your radar that has come up recently, especially in the conversations where people are pushing the frontiers of cloud native or there's some other use case that you're curious about. Well, I mean, there's an awful lot to talk about. Security solutions and really that's absolutely. So my old business partner Liz, she now works for Aqua. And there are an awful lot of who do securing containers. And I hear an awful lot of conversations now about how to make containers secure, but also how to make microservice architecture secure because actually you are opening up a lot of surface area that needs to be protected. It's actually really quite difficult to secure a very large scale microservice architecture. Yeah, that's everything in that area is interesting. Project Calico is interesting. The Istio project is interesting. Now, all those new, the only very new project that I heard about, oh, I think they're in stealth mode so I should probably talk about them. But there's another project basically building on the concepts that we were chasing up on microscaling systems, which is about using clever scheduling on top of the orchestrators to use resources more efficiently and cut hosting bills. And I still really like that. I think the problem at the moment is people are more interested in going fast than they are in cutting their hosting costs because developers cost more than machines. I think they hit a certain point and I think that's always an interesting arc as people use the mammoths, AWS, Microsoft, Google, whatever the cloud is that they're using or even the smaller ones. And then they hit a certain point and then they start seeing the larger bills come in and then what I've been seeing is a little bit of a trend towards a more hybrid approach, like bringing some of the things back onto the private cloud. And that's sort of we've been exploring that a lot with OpenShift and OpenStack on-prem with some bursting to cloud for quite a few customers. So that's an interesting aspect of it. The other thing that aside from security that's really been catching my attention is the open tracing, distributed tracing stuff. So like the things our friends that we've scope, we've worked with scope, but also the Yeager project, which as of this recording, I think is now officially an incubation project in CNCF. So you'll see that one, which is based on some of the Zipkin stuff. And it's, but in terms of the surface area and understanding the surface area of your applications, some of the visualization pieces that are being surfaced by tooling like Yeager and others, is really very interesting to me. So I've been kind of watching that space and seeing where that's going. So, but also like the CFP process, there were probably 20 projects in there that I had no idea existed until I read their submissions. And some of them are under the Kubernetes projects, some of them are CNCF, but a whole lack of them are just independent projects, like the one that Liz Rice is working on, CUBE Bench and 20 other security benchmarking things. There's just so much going on and something's new every day, I would think on GitHub out there. So... An area that interests me, that I know I used to rely on, absolutely, that's the problem. I used to do massive amounts of distributed listen stuff in the 90s when things were quite different. But we used to rely really, really heavily on API tracing and API replay, API capture, all of the messages that went across an API, so you capture them all and replay them all in a particular microsecond, well, they weren't similar to microsecond, they were just basically giant model. It's all talking to one another in a distributed fashion. But that was just so incredibly useful. We couldn't have kept these systems going without good API playback. And I don't hear much about it. There's Spectolabs in the UK, but other than that, I don't hear a lot about it, I don't think. I thought I, maybe I'm gonna have to go grab somebody like Alexis at Weave Scope, but I thought I saw some interesting playback stuff. They, yes, they don't... Demo recently, so maybe we're gonna have to get Alexis and some of the folks when we've worked to show us what they're doing, because I know there's a little video floating around the internet, talking about that replay aspect, which would be really cool. So, yeah, it's all, but it's all the tooling around managing that service area, understanding all the relationships between all the microservices and all of the containers out there. And so, you know, going back to the reason I really love Platform as a Service when it first came out was it made the deployment and everything very auto-magic, very simple and doing that. But now we're adding in all of this other complexity too. So my fear is that we need to keep it simple. My fear is that in order to keep that joy of coding and programming and things, the tooling has to come along as well as well as the deployment processes. And it is there to a certain extent. There are lots of beautiful registries with beautiful WordPress containers that I hate, but that are amazing and frozen in time. But, you know, they're out there, but it's still, you know, I still think we're at the beginning of this revolution in a lot of ways, and it's just gonna keep evolving. So, the one thing I always ask people who come on Tech and Talk is, here's my coffee telling me that it's turning itself off in the background, is to tell me who would you recommend we talk to next? Is there someone that you're dying to hear from in some other aspect of cloud native conversations that you'd like to throw under the board and the tires and have me bring on board? Yeah, there is somebody who's very interesting actually. She is the person that I interviewed at FT, and I was really, really impressed with her thinking on real world infrastructure for cloud native infrastructure and architecture. And I've also seen her speak at, I think it was at QCon last year, and she gave a very good talk on monitoring and the dangers of having too much data, too much information coming out of your system, and then getting a little bit of tea. And that is Sarah Wells, she's one of the chief architects at the FT. Absolutely. Cool, that's a great one. There was someone recommended from IT at AM Max recently too, so I'm gonna reach out to them and try and get them on as well. So once again, Anne Curry, thank you very much for coming on today. And we're looking forward, as soon as that PDF is ready and the book is there, let me know, and we will post the link to it with this blog post. I'll go back in and edit it in the future time and add it up there. And I'm looking forward to seeing you again, hopefully at QCon or somewhere before then at one of the upcoming conferences, or again, virtually, if you have another wonderful project to share with us. So thanks again, Anne. Thank you very much for having me. It's been a delightful experience.


pwd prints the current working directory cd changes to another directory ls lists the directory contents cat lists or prints contents of file cp copy one file to another mv move file or directory to another location also used to rename files mkdir make new directory rmdir remove directory rm remove files and directories touch create blank file or update metadata time info locate locate a file find find a file grep search through file contents sudo perform task as root usually proceeds other command df lists disks with associated disk space info du lists disk usage by files or directories head view first lines of any text file tail view last lines of any text file diff compare two files tar compress files into a smaller size chmod change permissions chown change owner jobs print current processes started by the shell in current session kill terminate a process ping check connectivity by throwing data at a server and waiting for a response wget download files using the command line u name check linux kernel information top list current system information including processes and processor usage history list pass terminal commands man user manual for given command echo print out given data useful for entering data into a file zip compress multiple files into a zip file unzip uncompress a zip file post name print current host name user ad add new user user dl delete a system user pass wd change current user password alias create shortcut for longer command unalias remove an alias from current shell session exit exit current shell environment shut down shut down the computer in one minute reboot reboot the system ps prints the processes of the current shell session which prints out full path of the given shell command or program shred destroy a file by overriding it with other useless data less terminal pager that allows you to scroll through long files inside terminal who am i prints current username what is prints a single line description of given command wc gets word count of given file also helpful for getting number of files in a directory where is prints location of given search term dd disk destroyer copy one disk image to another cal show a calendar mount mount to drive you mount unmounted drive clear clear current terminal contents cmp compares two files and determines if they're identical comm similar to diff compares the files for differences sort sort contents of file and display in terminal export set variables and current shell environment ssh connect to outside connection securely kill all terminate all related processes of given application ln create a link between one file and another similar to shortcuts awk scripting language used to manipulate data bc basic calculator when used with echo bg used to place process or action in background cf disk manage system partitions fdisk manage system partitions chk config used to list all available services chpasswd used to change passwords of multiple users at a time chroot used to change the root directory chsh used to change the current shell chvt used to change between different tty's column display output in neat columns date display current date dir displayed contents of a directory similar to ls eject used to eject removable media like usb sticks and hard drives fc-cash scans font directories fc-list list available fonts free displays total amount of free space along with memory info group add add new group group del delete existing group group mod modify existing group halt stops all cpu processes reboots the system or shuts down the system lsblk display info about connected drives blkid show info about mounted drives ls usb shows info about connected usb devices and buses pinkie displays information about current logged in users power off similar to shut down powers off the computer rename renames files can be used with regex sleep delay execution of a command split split large files into several smaller files tree display recursive directory contents in tree form uptime display how long a computer has been up since its last reboot users show current logged in users chag e change when a password expires chfn change current user details chg rp change group ownership of file or directory env print current list of environment variables rsync backup directories to another location journal ctl used to display system d and kernel logs


It's shocking, Paul. Get me a walker. Hey, guy, you're getting my way. Oh, this way. This way. Right now. Here you go. Here you go. Everybody here to walk with the world, we welcome Mrs. Reagan as well. I just want to say that I was in Washington 105 years ago. I was in the president of the United States, and I welcome him with Mrs. Louie in Walt Disney, his widow to our great wonderful company here. Ladies and gentlemen, the president of the United States, Paul Reagan. Senator Paula Hawkins, Congressman Ireland, Congressman Condi Mack, the column, the distinguished people here, Mr. and Mrs. Eisner. All of you ladies and gentlemen, these wonderful young people. We have come here, our first stop this morning, on this decoration day, was to receive a magnificent gift that I received, and a second and very much warmer inauguration day. I understand that in preparing for this event, more than 2,500 young people work with station and logic. And each of you who helped to make this private sector initiative possible, as my heart felt thanks. Tomorrow evening, I will address the nation about a tremendous amount of life expectancy of Americans has been increasing steadily for 50 years. I've already surpassed my own life expectancy at my birth by 20 years. Now I appreciate it very much. Today we take for granted, take for granted so many inventions that inspired wonder not long ago. The polly doctor, Albert Sabin. Television, first in black and white and now in vivid color. Drought resistant seeds and cold resistant grains. Computers in them land gently on a desert runway. Despite the predictions so many made during the Great Depression, when I was a young man, life in America today is not worse. It's far better. And let us ask them what made itself. During these past five decades, the government has indeed provided vital services and helped improve life for many people. No one doubts the necessity of a strong nation. Likewise, no one doubts the importance of the government's safety net for those in genuine need. Yet our national experience shows that when government grows beyond the ancient people rebelled against oppressive taxation some two centuries ago, the reform that I will announce tomorrow will represent a dramatic you yourselves. It will expand our economic freedom and clear the way for even greater economic vitality than that which we enjoy today. Nor will the benefits be economic alone. With more resources at their disposal, the American people will be able to bring synagogues. As our economy grows, they too will flourish. John Marshall said, the power to tax involves the power to destroy. If so, then the power to cut taxes must surely be the power to create. Friends, thank you again for the gift of this magnificent inaugural parade. May you enjoy all the blessings of a free and bountiful nation. And on this, the eve of the Second American Revolution, may you always remember the injuring and historic first visit to Epcot Center from Columbus, Georgia, directed by the East Greenwich High School Band, directed by Vincenzo Matera.