davidbgk
/
larlet-fr-david-cache

title: It’s The Future
url: http://blog.circleci.com/its-the-future/
hash_url: c49c76ef1aea72cabf73a382c7900429

<p><em>[Editor Note: At the risk of spoiling the joke a bit, we want to make sure that everyone knows that the following is satire, and we’re actually quite fond of the companies we mention. Docker, CoreOS, Google, Vagrant/Hashicorp, Heroku, Aphyr, Amazon, Mongo, Redis—we love you really and mean you no harm. <img src="http://blog.circleci.com/wp-includes/images/smilies/simple-smile.png" alt=":)" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Enjoy!]</em></p>
<p><img src="http://blog.circleci.com/wp-content/uploads/2015/06/rabbit_hole.jpg" alt="rabbit_hole" /></p>
<p>Hey, my boss said to talk to you &#8211; I hear you know a lot about web apps?</p>
<p><em>-Yeah, I’m more of a distributed systems guy now. I’m just back from ContainerCamp and Gluecon and I’m going to Dockercon next week. Really excited about the way the industry is moving &#8211; making everything simpler and more reliable. It’s the future!</em></p>
<p>Cool. I’m just building a simple web app at the moment &#8211; a normal CRUD app using Rails, going to deploy to Heroku. Is that still the way to go?</p>
<p><em>-Oh no. That’s old school. Heroku is dead &#8211; no-one uses it anymore. You need to use Docker now. It’s the future.</em></p>
<p>Oh, OK. What’s that?</p>
<p><em>-Docker is this new way of doing containerization. It’s like LXC, but it’s also a packaging format, a distribution platform, and tools to make distributed systems really easy.</em></p>
<p>Containeri.. — what now? What’s LXE?</p>
<p><em>-It’s LXC. It’s like chroot on steroids!</em></p>
<p>What’s cher-oot?</p>
<p><em>-OK, look. Docker. Containerization. It’s the future. It’s like virtualization but faster and cheaper.</em></p>
<p>Oh, so like Vagrant.</p>
<p><em>-No, Vagrant is dead. Everything is going to be containerized now, it’s the future.</em></p>
<p>OK, so I don’t need to know anything about virtualization?</p>
<p><em>-No, you still need virtualization, because containers don’t provide a full security story just yet. So if you want to run anything in a multi-tenant environment, you need to make sure you can’t escape the sandbox.</em></p>
<p>OK, I’m getting a little lost here. Let’s back it up. So there’s a thing like virtualization, called containers. And I can use this on Heroku?</p>
<p><em>-Well, Heroku has some support for docker, but I told you: Heroku’s dead. You want to run your containers on CoreOS.</em></p>
<p>OK, what’s that?</p>
<p><em>-It’s this cool Host OS you can use with Docker. Hell, you don’t even need Docker, you can use rkt.</em></p>
<p>Rocket?</p>
<p><em>-No, rkt.</em></p>
<p>Right, Rocket.</p>
<p><em>-No, it’s called rkt now. Totally different. It’s an alternative containerization format that isn’t as bundled together as Docker is, and so it’s more composable.</em></p>
<p>Is that good?</p>
<p><em>-Of course it’s good. Composability is the future.</em></p>
<p>OK, how do you use it?</p>
<p><em>-I don’t know. I don’t think anyone uses it.</em></p>
<p>Sigh. You were saying something about CoreOS?</p>
<p><em>-Yeah, so it’s a Host OS you use with Docker.</em></p>
<p>What’s a Host OS?</p>
<p><em>-A Host OS runs all your containers.</em></p>
<p>Runs my containers?</p>
<p><em>-Yeah, you gotta have something run your containers. So you set up like an EC2 instance, you put CoreOS on it, then run the Docker daemon, and then you can deploy Docker images to it.</em></p>
<p>Which part of that is the container?</p>
<p><em>-All of it. Look, you take your app, write a Dockerfile, turn it into an image locally, then you can push that to any Docker host.</em></p>
<p>Ah, like Heroku?</p>
<p><em>-No, not Heroku. I told you. Heroku is dead. You run your own cloud now using Docker.</em></p>
<p>What?</p>
<p><em>-Yeah, it’s real easy. Look up #gifee.</em></p>
<p>Gify?</p>
<p><em>-&#8220;Google’s infrastructure for everyone else&#8221;. You take some off the shelf tools and stacks, using containers, and you can have the same infrastructure Google has.</em></p>
<p>Why don’t I just use Google’s thing?</p>
<p><em>-You think that’s going to be around in 6 months?</em></p>
<p>OK, doesn’t someone else do hosting of this stuff? I really don’t want to host my own stuff.</p>
<p><em>-Well, Amazon has ECS, but you gotta write XML or some shit.</em></p>
<p>What about something on OpenStack?</p>
<p><em>-Ew.</em></p>
<p>Ew?</p>
<p><em>-Ew.</em></p>
<p>Look I really don’t want to host my own stuff.</p>
<p><em>-No, it’s really easy. You just set up a Kubernetes cluster.</em></p>
<p>I need a cluster?</p>
<p><em>-Kubernetes cluster. It’ll manage the deployments of all your services.</em></p>
<p>I only have one service.</p>
<p><em>-What do you mean? You have an app right, so you gotta have at least 8-12 services?</em></p>
<p>What? No, just one app. Service, whatever. Just one of them.</p>
<p><em>-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do.</em></p>
<p>That seems excessive.</p>
<p><em>-It’s the only way to make sure it’s reliable. So if your authentication service goes down…</em></p>
<p>Authentication service? I was just going to use this gem I’ve used a few times before.</p>
<p><em>-Great. Use the gem. Put it into it’s own project. Put a RESTful API on it. Then your other services use that API, and gracefully handle failure and stuff. Put it in a container and continuously deliver that shit.</em></p>
<p>OK, so now that I’ve got dozens of unmanageable services, now what?</p>
<p><em>-Yeah, I was saying about Kubernetes. That let’s you orchestrate all your services.</em></p>
<p>Orchestrate them?</p>
<p><em>-Yeah, so you’ve got these services and they have to be reliable so you need multiple copies of them. So Kubernetes makes sure that you have enough of them, and that they’re distributed across multiple hosts in your fleet, so it’s always available.</em></p>
<p>I need a fleet now?</p>
<p><em>-Yeah, for reliability. But Kubernetes manages it for you. And you know Kubernetes works cause Google built it and it runs on etcd.</em></p>
<p>What’s etcd?</p>
<p><em>-It’s an implementation of RAFT.</em></p>
<p>OK, so what’s Raft?</p>
<p><em>-It’s like Paxos.</em></p>
<p>Christ, how deep down this fucking rabbit hole are we going? I just want to launch an app. Sigh. Fuck, OK, deep breaths. Jesus. OK, what’s Paxos?</p>
<p><em>-Paxos is like this really old distributed consensus protocol from the 70s that no-one understands or uses.</em></p>
<p>Great, thanks for telling me about it then. And Raft is what?</p>
<p><em>-Since no-one understands Paxos, this guy Diego&#8230;</em></p>
<p>Oh, you know him?</p>
<p><em>-No, he works at CoreOS. Anyway, Diego built Raft for his PhD thesis cause Paxos was too hard. Wicked smart dude. And then he wrote etcd as an implementation, and Aphyr said it wasn’t shit.</em></p>
<p>What’s Aphyr?</p>
<p><em>-Aphyr is that guy who wrote, &#8216;Call Me Maybe.&#8217; You know, the distributed systems and BDSM guy?</em></p>
<p>What? Did you say BDSM?</p>
<p><em>-Yeah, BDSM. It’s San Francisco. Everyone’s into distributed systems and BDSM.</em></p>
<p>Uh, OK. And he wrote that Katy Perry song?</p>
<p><em>-No, he wrote a set of blog posts about how every database fails CAP.</em></p>
<p>What’s CAP?</p>
<p><em>-The CAP theorem. It says that you can only have 2 out of 3 of Consistency, Availability and Partition tolerance.</em></p>
<p>OK, and all DBs fail CAP? What does that even mean?</p>
<p><em>-It means they’re shit. Like Mongo.</em></p>
<p>I thought Mongo was web scale?</p>
<p><em>-No one else did.</em></p>
<p>OK, so etcd?</p>
<p><em>-Yeah, etcd is a distributed key-value store.</em></p>
<p>Oh, like Redis.</p>
<p><em>-No, nothing like Redis. etcd is distributed. Redis loses half its writes if the network partitions.</em></p>
<p>OK, so it’s a <em>distributed</em> key-value store. Why is this useful?</p>
<p><em>-Kubernetes sets up a standard 5-node cluster using etcd as a message bus. It combines with a few of Kubernetes’ own services to provide a pretty resilient orchestration system.</em></p>
<p>5 nodes? I have one app. How many machines am I gonna need with all this?</p>
<p><em>-Well, you’re going to have about 12 services, and of course you need a few redundant copies of each, a few load balancers, the etcd cluster, your database, and the kubernetes cluster. So that’s like maybe 50 running containers.</em></p>
<p>WTF!</p>
<p><em>-No big deal! Containers are really efficient, so you should be able to distribute these across like 8 machines! Isn’t that amazing?</em></p>
<p>That’s one way to put it. And with all this, I’ll be able to simply deploy my app?</p>
<p><em>-Sure. I mean, storage is still an open question with Docker and Kubernetes, and networking will take a bit of work, but you’re basically there!</em></p>
<p>I see. OK, I think I’m getting it.</p>
<p><em>-Great!</em></p>
<p>Thanks for explaining it.</p>
<p><em>-No problem.</em></p>
<p>Let me just repeat it back to see if I’ve got it right.</p>
<p><em>-Sure!</em></p>
<p>So I just need to split my simple CRUD app into 12 microservices, each with their own APIs which call each others&#8217; APIs but handle failure resiliently, put them into Docker containers, launch a fleet of 8 machines which are Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes cluster running etcd, figure out the “open questions” of networking and storage, and then I continuously deliver multiple redundant copies of each microservice to my fleet. Is that it?</p>
<p><em>-Yes! Isn’t it glorious?</em></p>
<p>I’m going back to Heroku.</p>