 so sweet thanks thanks for coming out and I appreciate that you're all still finishing you know the coffee break I've got a coffee over there but if I drink the coffee it causes the microphone to get knocked off of my face so I will I will not be I'll not be drinking in front of you although probably if it was it was a beer break I think I would I would just not care about the microphone anymore and just drink beer but that wasn't that wasn't an option yet I think that's later today so cool so I'm gonna I'm going to hopefully I'm gonna hopefully say all sorts of incendiary and negative things and cause everyone to to tweet angrily at me I believe people are already tweeting angrily at me due to yesterday's TC meeting but but maybe we can give you some more ammunition to show how much you love me on the internet so if you'd like to do that my Twitter handle is up there I'm James Cormonti that seems to be how people will get feedback or if you just want to post a photo of a cat and and then say something funny about me that's that's cool too these slides if you if you decide that you you like them you want to show them to your to your wife or your husband or whatever when you get home there you're on the internet actually I have I made a couple of changes this morning and I have not run getting pushed yet so so there is a version of these slides at that link but a couple of the slides will be in a different location and you know but I'll I'll get around to doing get push here any minute finally while I'm talking about the topic of talking about topics the source code for these is also in get as I might have just mentioned you're free to clone it it's all creative commons licensed except I believe for any quotes that I have on the screen because I did not own the copyright to quotes from other people so the slides themselves are copyrighted that the content of the slides itself might be evil in some way sort of like I might be but that's okay so I'm up here babbling that's a great I suppose but you it's possible you don't know me it probably it's it's certain you don't know me because if you knew me would be sitting here in the in the seats so I work for for international business machines I don't know if you've heard of us we do computers and other things amongst things in our history we have we invented the automated traffic signal which I think is extremely important otherwise cars would you know just run into each other and nobody wants that they've made me a distinguished engineer there which is terrifying for the entire world of technology but I guess I guess that means something positive I also spend all of my time on open stack so I just run around saying open stack open stack open stack open stack people at least that's what my wife says that I do I said in the open stack technical committee which you again if you follow Twitter things you might be aware of given yesterday's DC meeting I also sit in the foundation board of directors which is another vector by which I can make people angry and and finally I work on the open stack developer in the core team of the OBSAC developer infrastructure systems which is a third way in which I can I can I can piss you off and make things hard on you so so hopefully I've got enough enough ways in which I can I can bring pain misery and suffering into your life which which I believe is clearly my intent I also you may have noticed tend to ramble on any particular topic and it's it's not uncommon for me to not get to the end of the talk in the appropriate amount of time because I just do this so I've decided for this talk that I'm going to put the main points of the talk first and then then I can just sort of ramble and if we get to we get all the way through it great if we don't you've got the so so let's get started so number one is good sure yeah it's great fantastic is not bad no it's not do you need to write cloud native apps to use cloud no are you a bad person if you don't write cloud native apps no you are not that's it that's the basic thing that I want to get across here I will say that in many more words but if you if you take away nothing other than than those four things that I think we've had a successful day and and we have all learned drinking more beer so that's great so so what is what is about me it's a word that gets tossed around a whole bunch I thought I'd give you a few a few potential definitions walk through that a little bit and we'll talk about why it may or may not be for you or reasonable or whatnot so first of all there's this wonderful quote from Information Week that talks about what cloud native is and says you know it's a that's in a world where computing is ubiquitous they can be developed on a cloud platform deployed different clouds and I quite literally think that this Information Week quote does what my wife says that I do at these conferences which is just to say to work cloud over and over again so in this case the definition of cloud native is cloud cloud cloud cloud cloud cloud cloud cloud which is really useful we'll have native computing foundation which are a wonderful set of people who do Kubernetes related things say this new mission statement I don't want to pick on other people's mission statements because I have been involved in mission statements and it turns out it's entirely impossible to put together one that is clear and crisp but in this particular case cloud native is going to harmonize emerging technologies and foster innovation so I think it's good that we're gonna foster innovation nobody wants to squash innovation unless you read Twitter things about me apparently I do and probably it's going to be container packaged it's gonna be dynamically scheduled there's gonna be microservices involved in it and that's that's great like that's that's a that's a little bit clear that gives me a few more actual salient bullet points I'm gonna I'd like to sort of put this in a bullet point form rather than mission statement or or tech article things first of all it's our architectural and an operational approach it it defines both how you write and organize your software and how you deploy a left right that both of those two things are are affected if you if you decide you want to do it it does assume cloud it would be really silly if it was cloud native and it also did not assume cloud it would be very poorly named at least it in theory assumes failures so there's a bunch of things multiple copies of things and load balancers and auto failover and stuff like that you should build in there something with microservices something containerized people like to say that we talked about that a lot this morning I saw the you know saw the resiliency of the Kubernetes deploy approach of thinking about things as all individual units of pods that can be contained containerized is an interesting question there's a lot of people these days that sort of assume it has to be containerized I would argue with them I'm gonna argue with them about a lot of things but I think I would argue that that's that's a thing that should be up for debate but most of the normal cloud native people would argue that needs to be containerized in order to be positive the folks at Pivotal have this really nice slide this is one of the slides where when I say these slides are creative commons licensed this one not so much because this is my slide I just told this blatantly from their from their website so sorry for all of the people who are angry about that but they sort of get this this sort of stack of things and there's a thing in particular that I would also like to thank them for sticking their logo here that's very nice you know not all the time you don't necessarily see that in all of the slides where you have to next to the logos next to it but we've got we've got some different things here we got we got some infrastructure we got some automation and then we've got the applications and platform that you're gonna run on top of that and if you got these nice little you know human icons over on the left to show us the gray ox people and the blue dev people and sort of the differentiation of of their tasks and it's like to sort of keep in keep in mind that that sort of cultural cultural fit that that's being sort of shown there it's either the next slide or the slide after I'm gonna I'm gonna apologize in advance I I decided to get exciting this morning and add a pop-up of a quote into the talk which is either going to go very well or very poorly so we get to that point it's let's hope that goes properly so from the from the clock foundry people as well they're really big into this one of the best definitions of cloud native that I think it's really specific as it's all factor application fact you'll hear a lot of people use those two completely interchangeably like it's it can't be called native unless you've unless you've done your your application in 12 factor manner and in general I think these are all really great ideas right like almost everything on this list is completely fantastic you should number one is a really good example your code should be in inversion control if your code is not in version control you have many other problems other than please please for the love of God put your code in diversion control I would argue get but like if you really want to do you know clear case or whatever it is that other people like to do that's great you should you should probably deal with config I'll talk about in a second but like a bunch of this stuff is good things usually they're good things to keep in mind right I in fact I suggest strongly going to 12 factor dot net that's one to factor not 12 spelled out but to go to the 12 factor dot net each one of these you can click on and you can read like a big long thing and we could I'm sure do an entire conference just on on explaining 12 factor applications I'm not gonna I'm gonna dive into into it too much but I just want to point out that it has been annotated and there's some really good practices in here so this is this is absolutely fantastic right I don't really like three personally number three in the 12 factor says you should store all of your config and environment variables and that seems kind of strong to me like that's that's not really how how I deal with config at least not in any of my cloud applications but but apparently somebody else thinks that's really important so they put it into a list so I guess I am back out in some sort of way six is also says it has to be states right so so all your stuff has to be cloud native then none of your stuff should store any data or at least it should it should use an external service to store the data so that's great unless you're the person running the external service that needs to store the data in which case then your external service itself can't be cloud native because it needs to be stateless so I hope that everybody has seen the wonderful MongoDB thing if you haven't I highly recommend going in googling the phrase MongoDB as a web scale this is not to pick on MongoDB MongoDB is a great piece of technology but the cartoon is quite funny and I think speaks to the particular concept that that is there at point so so which is the Python style guide has has this line foolish consistency is the hobgoblin of little markets you can go read Pepe it's it's got lots of stuff in it but but we don't put this in or action my name Guido but they put this in to sort of remind you that these are guidelines not absolute rules right amusingly enough that is in fact a quote drawn from somewhere else I'm not going to read the entire quote but if you'd like to at some point go turns out Ralph Waldo Emerson is the fellow from from back in English literature who said this the top of the top of a much longer thing and what he's getting at sort of later on in here is that is that you should you should say you should say the hard words today and you should also say the hard words that are correct tomorrow and they might be different they might conflict with each other but you need to you need to dive into the hard situation on each day and deal with that and you know that might not work out for you really well every day but completely avoiding the hard problems is is not particularly a great way to live your life so so probably even in 12-factor I think are a fantastic approach but they're they're a great approach right you still have to think and you still have to think about whether or not they make sense for for your application and for how your your application is going to interact with the internet with your users with your business and all of those sorts of things and here's where I can so on the side of the building out here is this book the tragedy of modern man is that he knows less and less not that he knows less about the meaning of life but that it bothers him less and less and the reason I put that out is that I think that what I find these days more and more in technology is this is the tragedy of modern technologies not that he knows less and less about computers work but that bothers him less and less we we see more and more things trying to separate people who are writing in computer code for a living from needing to understand the computer that runs underneath them ultimately when you get into the hard problems that are at hand you need to understand some of those things depending on what you're writing maybe you don't if you're writing the next angry birds okay you know maybe maybe it's not important that you understand everything about the thing but actually angry birds got really really popular and and all of a sudden had some really hard scaling problems and so probably there's some engineers there somewhere needed to deal with those those problems so depending on who you are depending on what you're doing I would I would urge you to to at the very least not just say okay well if I adopt this one blueprint of how to do things it will solve all of my problems and I won't have to think about them and I can I can just make billions of dollars throwing birds and sheep or pigs sheep I didn't really run so so I'm talking about a couple things that I do with cloud as it relates to this and then how that relates to to quality of things so I think that having a cloud and somebody said this this morning as well like it's it's it's not just having a cloud is at the point it's your application what you want to do with the cloud right how I'm going to use this to serve my customers and and my use right so for me as an application developer I I want to deploy my application the internet I'm not really big into things that don't run on the internet personally that might but this is just me and so that my customers all over right and and also this is really important to me as an operator of software that I probably also wrote I wanted to play that application across multiple clouds so that if I have an issue in one of the clouds my service still survives not just it turns out that when when you can't watch when you can't watch episodes of things at least in the US I'm not sure how it works here but when there's an Amazon outage that causes people to not be able to watch the Netflix people get really really annoyed and I think it's what what they care more about is not whether or not it was the service provider upstream but but rather can I watch the episode of friends that I'm really excited about watching so this is the thing that I do currently and I do this and there's actually other people in the audience here as well that helped me with this we we work as I mentioned on the open sector over infrastructure we we spin up and tear down between 10 and 20,000 m's a day in service of the fine developers of open stack this is spread across 12 10 cloud regions that span seven clouds which I think is a really great testament to open stack being being pretty fantastic and that's all done using nothing but the open stack APIs as the people who who support the project we find using things that aren't open stack to be strange it's possible possibly really important that we use open stack to get things done because then we can give feedback to developers this is the second for team as I mentioned it's the two-linked automation our VMs are kind of spread out which I think is also really cool we have we have three different data centers worth of VMs from rack space fine folks at internet have given us some some VMs in their New York data center which amusingly enough the region code for is NYJ so I believe it's actually a new Jersey but they call it New York which I'm sure both upset the people in New York and New Jersey it's not good for anybody there there are two different regions we have for for OVH which is a European open stack public health provider based based in France and I cannot pronounce the name of those of those places perfectly so I'm not going to try Vexos does another cloud provider for us they're based in Montreal the open stack innovation center is a joint venture between rack space and Intel they've donated things and I'm pretty sure those machines are in San Antonio although it could be wrong about that those are the public health those are just open stack public health who have donated resources to us we also have a managed private cloud from from blue box that the blue box donated to us which is in San Jose and Red Hat is running a team of Red Hat is running a cloud that we used to test triple O things which I believe are in Phoenix we treat all of this as one big thing also I forgot about this and I shouldn't we also serve us so you like your enterprises donated a couple of racks of servers in a data center and we have a community effort to run open stack on that also to put into the same the same pool of things this is this is a sort of a simplified version of the architecture of what we've got going on here and it's not how it works is not particularly important in terms of what all of these pieces do the thing that I want to point out there's a couple things I want to point out you'll see these sort of gray boxes those are external services that we don't run that we have to interact with these are a thing that show up in lots of architectures you're like well you know I'm gonna do this but I'm gonna I'm gonna use you know data dog or for pager duty or some sort of run an external managed service we have we have some things that are they're sort of more normal nodes they sit there we run we upgrade them we care for them we have a set of things that are their scale out we've got 10 12 of them 14 of them if one dies we just make another one they're not really elastic in the sense that they're responding to demand because we don't need them to be but they're they're sort of more capacity plan to scale out architecture and then sort of here in the middle there's two of them partially because I lost the original source of this image and so I'm just sort of you know gimping over top of it but that's actually where our seven clouds sit and this is completely dynamic dynamic thing that stuff all works together to make a coherent service and the fact that some of these things are our individual servers some of them are scale out servers some of them are elastic services and some of them are external services shouldn't be interesting to our end users right it should be to them they should be using the services that we're providing and we do the things we need to I want to call it two specific pieces of this as by way of example so one of the things we run is a thing called Garrett it's where the code review and codes it could not possibly be more of a traditional enterprise job application in tribe it's big it's kind of monolithic it sort of sits there you scale it by getting a bigger machine you hopefully tune the JVM then you cry you know all of all of those sorts of things go on with it we run it on a nova beam we run it on a cinder volume and we have a trove database that that that services that's it we treat it like it's running on a computer and it's been running that way for four or five years now it's a different VM than it was five years ago but but it's pretty much that we have a scale up farm of get replicas that replicates to get repositories are inside of it because it turns out that serving get is actually a CPU intensive task and so it doesn't really scale to just have one month of the job application serving out get replicas to two thousand developers it also has the wonderful quality that many that many traditional enterprise job applications there are administrative tasks that we might want to perform one of the times that involve hours of downtime and there is nothing we can do about that so we schedule them in advance and we do them at best you know once every few months but they do that we've talked in the past about you know how do we so if I took this and I stuck it into a into a Kubernetes for instance Kubernetes is fantastic I stuck this into Kubernetes it would solve nothing it would sit there very nicely in the one container that I still can't turn off because it's going to be couple of hours of downtime for me to do the migrations right it doesn't help me with this this is the thing I have to run I could rewrite this and that would take me probably about five or six years to do so there's a cost benefit in this particular case we've chosen that it is not in our best interest to spend the time to rewrite it so that we don't have those down times because maybe for us two hours of downtime every three months is acceptable for this application and that says that's a call that we had to make and we continue to have to make on a daily basis we have a different piece of software called node tool which manages the dynamic thing that I talked about it's a bit more cloud native especially in the sense that literally what it does is operate cloud resources so it's kind of hard to get more cloud native all it does is talk about it's purpose built for this purpose in Python and it keeps a pool of ready-to-go nodes so all of those clouds I was talking about they span we we have this application treat machines in across each of those clouds we don't really care whether the Ubuntu trustee node comes from Vexos or from Rackspace we want the Ubuntu trustee node to be in the boot to trustee node and behave that way and so that's what node pool does for us as I mentioned it's multi-cloud and allows us to treat all of those clouds as one large thing it's also completely and fully elastic right so this is this is responding when you you know upload a new patch into the system that is going to cause VMs to be created and destroyed in fact you do that right now if you patch bomb Garrett it will it will in fact spin up and tear down VMs which is which is kind of cool except what we can quote us and you know ultimately the end of the day physics takes over and there are only so many VMs you can spit into particular things the reason I'm talking about all that and the thing about Talonado is that I think that one of the biggest benefits to cloud and why why we're all excited about it is that allows you to run what you want right if you want to run a 12-factor application on Kubernetes that's fantastic courier is in open stack it helps to integrate the network from Docker in with with neutron so you've got you can have your containers alongside your VMs of the same network that's that's been but it's truly astounding right it's really really cool stuff if you want to run a traditional job application behind that you can do that in cloud there's absolutely nothing about cloud that's stopping you from doing that I'm doing that in production right now if you want to run a Kerber server for the love of God on the internet with an actual fixed IP and proper reverse DNS you can do that in cloud too and in fact we do that and if you wanted if you wanted to get bare metal because you've got some really specific things a really good example of where where this comes up is people wanting to do like video transcoding using special special hardware cards that are in the they're in the bare metal great you can do that in cloud as well ironic plugs into in a Nova and you can use the exact same Nova calls to get a bare metal as you use to get a VM and you can do all of those things depending on which of those things makes sense for your application for your customers and that's ultimately the thing that's the most important one final word on this that I'd like to like to get back to and I have 10 seconds left so that's probably not gonna happen but but I want to point out again this sort of this sort of differentiation here with the blue people and the gray people over the side where you've got that the ops and the deaf people and the deaf people only have to think about their application in their application framework and ops people only have to think about the infrastructure with kind of my understanding that we've made some progress in the last several years and that the dev ops is about the depths of the ops collaborating so I will I'm concerned I don't think this is actually what they're worth trying to say on that previous slide but I do concern that people people take certain things out of context and seeing this as oh the depths in the ops don't have to talk because that's enough talking to each other is really frustrating and annoying the depths can go to focus on code and don't have to worry about any of that terrible ops things they think that takes us back a few years right I think I think it's a really big progress that we've made over the last five six years and truly understanding the power of each of these groups of people understanding each other and building a deeper understanding and so finally in summary I think that guidelines are fantastic architectures are fantastic all of these things that we can learn about are great but rigid devotion to them without any human judgment is quite deadly all of the things all of the tools we have such an amazing pile of tools at our disposal but we have to apply judgment we have to apply thinking to them and about which ones of them actually solve the problem at hand isn't working to us and with that I'm only over by zero seconds because I don't believe it counts down that way so I'm gonna call that pretty good so thanks for listening to me