 The Battle of Infrastructure, 2017. Nell Shemrel Harrington, my name is Nell Shemrel Harrington and there's a million deploys I haven't done, but just you wait, just you wait. Now you may have no control over who lives, who dies, who tells your story, but the rumors of the death of any technology are greatly exaggerated. I've had people say to me, why do people still use on-premises? Why do people still use bare metal? Isn't bare metal infrastructure dead? And the answer to this is definitely no. If you're dealing with processing a lot of video, if you're dealing with mining whatever cryptocurrency is invoked today, you still need the raw compute power of bare metal. Now I've also heard, isn't virtual machine infrastructure dead? I mean, isn't everything serverless now? Why are you still spinning up VMs like you're running out of time? And the answer to this is no, it's not dead. There are a lot of parts of your application which don't work well in serverless and you still need that VM. Now this one's the big one. Doesn't everyone just run everything in containers now? And the answer to this is also no, despite what the hype may lead you to believe that containers are not the best solution for everything. This is because containers are for the stateless parts of an application, things like web servers or even short-lived caches, things where it doesn't matter if that container goes away and we spin up a new one from that container image. Now by contrast, containers are not for the stateful parts of an application, things like production databases. If you try to run a production database in a container, you are in for a world of hurt. Now when I say stateful, what I mean by that is something is stateful when it has persistent data, when it has data that needs to stick around from deploy to deploy and throughout the lifetime of the application. That means something is stateful and that means it should not go in a container. Now if you store persistent data in a container, you will get a giant container that is locked into a host. It's not young, scrappy, and hungry and you are throwing away your shot with containers if you do this. Now in addition to having that giant non-portable container, you're also going to be locked into a particular host. It's going to be very difficult to spin up a new container and get all that persistent data out of the old container into the new one and if that container goes away, you're pretty much screwed. It turns the world of containers upside down. Now I mentioned this last week and someone said to me, well isn't running a giant container that's locked to a host just the same thing as running my database in a virtual machine? And the answer to this is also no. There's some big differences. The two biggest are that you don't back up a container and you don't patch a container. Containers, the idea of them is that you don't change the software running in them. You update the container image and then you make a new container to do that. Keeping the persistent data out of your containers keeps them portable. That's the reason containers were created in the first place to have that wonderful ephemeral flexibility to spin up a new version of that application piece anywhere. Now what about Kubernetes? I mean there's a lot of really smart people at Google. Haven't they figured out this problem of stateful data in containers? And the answer is yes, but there are stateful sets in Kubernetes and they are very, very cool. But the thing about them is they still keep the persistent data out of the containers. They keep it on a separate volume that is then automatically mounted on each container as it's spun up within that stateful set. Now how do I know what parts of my application go where? I mean is my infrastructure even something I can control? Is it unimitable? Is it an original? Well I can't give you the 10 Commandments of Infrastructure but I can give you three general guidelines to help you when you're deciding where to run your application parts. The first is that stateless parts should go in containers. Again, anything where it doesn't matter if it goes away and comes back up again, you'll get a lot of benefit from having those in containers. Now if you have a persistent data store, something like a production database, those generally should go in virtual machines if you wanna keep that wonderful power and flexibility of the cloud and have the ability to easily back it up and or spin up a new virtual machine. Now if you're dealing with anything with a heavy compute load, again, processing video, doing cryptocurrency, anything where it would be bad for your host to be sharing its resources with other applications running on it, those generally do best on bare metal. There is definitely still a place for bare metal in this work. And so the DevOps experiment begins with my servers not scattered to the winds. Again, I'm Nell Shamrell Harrington. My name is Nell Shamrell Harrington. That's my info and thank you.