Hey everybody, Randy here.
So, it looks like we've got a good amount of people in here, so we're going to get started right now. Hi, everyone. Welcome to today's webinar, the evolution of today's cloud native systems. This is the first in a series of three that is going to be presented by Randy Abernethy, the managing partner at RX-M, which is a leading cloud native consulting firm based in San Francisco. Before Randy does get started, I just have a couple of housekeeping items to go over.
During this webinar, you might have noticed that your phones are muted. If you have any questions, please enter them into the chatbox on the left, and we'll answer those at the end. Today's webinar is being recorded and we will be sending the link out to all of our registrants afterwards. Now, let's get started. Randy, you can take it away.
Great. Thanks for joining everybody. We've got a fun-filled hour of cloud natives to discuss, and there's a lot to talk about so let's just go ahead and dive in. This is presented by ExitCertified and Tech Data, a leading training provider in the global space, and RX-M in partnership with Tech Data and ExitCertified, and we focus on the cloud native space, which is often characterized as being microservice oriented and container packaged and dynamically managed. These are sort of the three legs of the stool that most people think about when they think cloud native.
This is really what we're going to be talking about. What is microservice oriented? Which is the architectural piece. What's container packaging? What's that bringing to the table, and then finally, the dynamic management piece, which is really the last thing to have developed in the open-source space that has been the key enabler, allowing us to drive forward with this technology in a lot of environments. Defining cloud native, it can be done lots of ways. Many people also characterize cloud native as being generally open-source.
Obviously, you can build cloud native system with commercial systems, if those systems were available, but it's been just sort of a natural evolution that people have been moving more and more from a platform standpoint to open source. When you look at this space microservices are just an architectural style, but the container technology that's out there is really pretty exclusively open source. You've got Docker of course, the 800 pound gorilla in that space, but you've also got rkt. You've got Garden and the Cloud Foundry space. You've got various other tools. You've got the Mesos Containerizer in the Mesos space. There's lots of container tech out there, but every single one of those things that I just mentioned is open-source.
There's really no reason to build something closed source because you'd be competing with a $0 and high quality field. Dynamically orchestrated, on the other hand, is something that has been traditionally handled by commercial solutions. VMware has been really important in helping people deploy workloads with virtualization and manage them, and they've got a lot of great tools in that space and that's been a really key market for them, but slowly and progressively, open-source solutions have been cropping up.
A number of cloud provider kinds of solutions in the open-source space have come and went, but OpenStack has sort of stuck a little bit. That's all open source, KVM, other tools on the hypervisor side of things, but the cloud native solutions kind of move up a whole nother level. Part of the idea here is that infrastructure as a service is great and being able to just provision a platform dynamically is a key facility in cloud native systems. Platform as a service is great, but platform as a service is ... It's more about the CICD continuous deployment types of things, and there's some pieces missing. There's a few pieces missing in a past solution to give you a complete cloud native system.
Then software as a service, of course, just being able to offer software over the internet, through APIs, that's obviously a key part of the whole equation. What we're going to do is kind of break all this down and take a look at the key players in each of the tiers and how things are all kind of working together. I really like to present this slide to give people a mental model for why you would want to do something in a cloud native space, the traditional approach, maybe a decade or more ago, was to install software on the host and then make that computer the package, right?
That computer was the package that you used. You had a computer in a data center and software is installed on that. When somebody else says, "Hey, I'd like to install my app on your computer because you're not using all of it." The person who was in charge of that app would say, Forget it. You're not installing anything on my computer. I don't want it to get wrecked." Folks like Gartner estimated that firms were using 15%, maybe 30% of their actual capacity. The next thing that happened is we started packaging things up in virtual machines, but both bare metal and virtual machines, you've got an operating system installed, you've got a fair amount of overhead there, and if you're installing a small application, there is still probably going to be under utilizing of that system.
So, people ended up packaging, either large apps, or many copies of different smaller apps in the system. Whenever you're in a situation where you want to deploy something, install something on the host, you're kind of doing this, you're tearing the street up. Hey, let's plant a tree here. Okay, great, but what if there's a water main down there? What if there's some power lines? You could be affected by other things because you're trying to plant your software in an environment where the things exist. One of the approaches to fixing that problem was the DevOps of old or configuration management, where we would use puppet or chef or Ansible or salt or something to automate the installation, so it was "repeatable."
But the problem is it wasn't repeatable because you install app A with these scripts and it's perfect. And you install that be with these scripts and it's perfect. And then when you install A and B with those exact scripts on the same machine, things blow up, and we have interaction issues and things like that. What the real world really needs and has wanted all this time is a planter. You can pick that up with a forklift and put it anywhere in the city you want. You know what? Once you decide, hey, gee, you know what? This is not the best corner for this tree. It'd be better if we had this tire swing somewhere else. You could just pick it up and put it somewhere else.
It's portable, it's flexible, it's self-contained, and it's also lightweight. It's designed perfectly for that tree. In the world of software development, our trees are applications. They're not computers. Nobody cares about computers. Nobody cares about operating systems. We care about applications. Companies, enterprises, people want to create applications, and containers are the perfect size thing to package up applications. Basically, as firms are looking for speed of innovation and scalability, these are really the two key factors, speed of innovation and scalability, that we need in the modern world to compete.
Your only competitive advantage is your ability to out innovate your competition, and so with these two factors, we've got a lot going for us. Realizing the vision of Agile means being able to build software like this, where we can just drop it in, and you know what? If this tree is not exactly right, we can just destroy this container, grab it, get rid of it and drop a new one in. That's what we want. We want rapid cycle times, we want low friction. We don't want to have to tear up the street. We don't want to have to get permits in order to install this thing. We want to be able to just drop it out there.
Those are some of the key thoughts that have sort of empowered this movement, but just like most things that are revolutionary, the revolution is something very simple that just combines stuff that we've already got. For example, Agile, test automation, CICD, public cloud, all of these things have been around for a long time. Clustering databases that can scale the same [inaudible 00:08:39] tech, all of these things have combined together to give us this cloud native nexus, but the piece that sort of brings it all together is orchestration. At least that's sort how I look at it. Container technology was incredibly important, but we've had that for a little while.
What we haven't had is great orchestration, but that is actually being developed. There are other pieces that plug in, software defined networking, pretty critical, and that's more or less a solved problem. Software-defined storage, I would say is not a completely solved problem. There's some vendors who've got it down, but as far as standards and wrap-ability, and consistent approaches, there's some room for improvement, as far as reliable open-source solutions, again, room for improvement. So, there's still frontiers out there. It's not like this is old hat.
We're still actively developing this space and there's a lot going on. So, when you think about what we've got today and how we might do cloud native, how we might break something down into microservices, container package it, and then deploy it in some sort of an orchestration environment, there's a big range of possibilities. We've got some of the early basic types of things. By the way, there's a lot of borrowing here and we try to credit everybody that got some great models that produce a good mental picture. So, this came from the IEEE Computing Now in October of 2015.
But it's a really nice mental model because you can basically take a computer, turn it into a virtual machine, and run it in an infrastructure as a service cloud without a lot of impact. But that also only buys you so much benefit. You now have the ability to run that machine without managing your own infrastructure. You have the ability to move it around [inaudible 00:10:34] rapid application development. You didn't buy yourself a lot there really. You got to the point where you can now click a button and create a new machine, but the way that your application is architected is probably going to constrain you from doing a whole lot of the things that are going to make an organization really nimble.
The next thing that we need to sort of start looking at is some of these other techniques like DevOps, where we break down the barriers between IT and dev. We create cross-functional teams that can bring something completely to production independent of a lot of handoffs so that we can shorten cycle times, one piece flow, all of that kind of stuff. But there's still some challenges, even when you implement DevOps, because if your package is the size of a virtual machine where you've got an operating system in there, the thing that you're putting in that package needs to be sizeable.
If the OS is 200 megs, or even, for example, VMware's photon designed specifically to work in this container space is still 60, 70 megs, your application's got to be pretty decent size just to make it 50% of the workload. If you want to make your application take up more than 50% of the actual overhead of the packaging, your app's going to have to be 200, 300 megs, and that starts meaning that many teams are going to be involved in coordinating and releasing that thing, and that coordination is exactly what Agile is trying to cut down on. Getting rid of the mood, or getting rid of the waste, lean, and all of that sort of stuff.
We have to start thinking about API-centric solutions, service-oriented architecture, and breaking down the application by business concerns. That's a big one. Somewhere right in here, a lot of people hit the wall. A lot of applications are layered. They're designed based on this is the data tier, this is the application tier, this is the UI tier. We use certain technologies here, certain technologies, and certain technologies here. When you want a business feature, it goes like this, and you tear up the whole street, and everybody's involved and trying to figure out how to coordinate all of these things up and down through the stack.
It's because of the stacks broken down by technologies and business people don't care about the technologies. They want functionality. They want applications. Users don't care about the technologies. We need to break applications up by the business components if we truly want to be able to be actually agile. If somebody from the business says, "I need this," it's going to be very specific to a particular part of the business most of the time. If your applications decompose that way, you'll only affect a small part of the application in improving it, or adding that new feature. That's a pretty big deal. Then microservices sort of follow this concept.
If you're gonna break the application down by business concerns, microservices are a great way to organize your application because microservices give you the ability to have a single responsibility and then to collaborate all these individual responsibilities together to form the application, and the decoupling that microservices bring to the table give you agility, give you the ability to scale, give the ability to innovate quickly, to try things without having a large event horizon. You can try something in a microservice, and if it doesn't work, there's a small area within which it's contained.
So, bounding context, some of the concepts from Evans' domain-driven design. All of these things have driven us to this sort of new point. So, it's not just technology. It doesn't have anything to do in the large with Docker, or Kubernetes, or any of these tools. They are a manifestation of the changing in processes and the way that we attack problems in order to get rapid innovation and scale, and that's what cloud native is all about. Monitoring tools, auto-scaling, all of these things come in the kit, but the motivation is all about improved business process. When we look at the platform evolution, and again, credit where credit is due. This I stole from Dan Kohn, the executive director of the Cloud Native Computing Foundation, a force of nature, traveling the world espousing cloud native, and also a fantastic landlord in the property space here.
He produced this slide, which I thought was incredibly insightful. With his permission, stole. You can see here, this, this kind of shows some of the key brands that have come along over time that truly made their mark. None of these brands were probably the firms that invented this particular thing, but they're the ones that made the difference. They're the ones that caused everybody to realize, wow, this is something new. This is something important and they got huge adoption because of it. We had the dotcom era where we were all about bare metal servers.
We had the web 2.0 era, infrastructure as a service gave us liberation and the ability to cheaply try things and experiment, and to scale rapidly when we got a hit. APIs and platform as a service, that was a big era. Then finally, we got to cloud native here. This is sort of the progression, and the players that made the difference were Sun. Back in the two thousands, this was non-virtualized hardware, but they were the ones who really gave us the first client server and workstation scale out kind of a model in computing. VMware brought us virtualization and changed the world as well.
Amazon brought us infrastructure as a service at scale, and that was in 2006. It's shocking to think, that was 10 years ago. It's not that long ago, and things just keep going faster and faster. Heroku, other people were trying platform as a service, but Heroku was the one that figured out, or got lucky, whichever it was, and figured out that Ruby on Rails was this incredibly transformative way of building web apps really rapidly, and that you don't care about the database, you don't care about the messaging, you don't care about the web server. You just want to build your app.
So, if somebody could provide you all that stuff and let you just push your code, you could have apps running in live in seconds. That was a huge thing. This was the beginning of the ability to have a rapid deployment cycle and CICD, and that sort of things. Other people were working towards that by packaging things up in VMs and pushing VMs, but VMs were big and heavy and kind of slow in the process. In platform as a service, we push code and everything starts going faster.
You want something, boom, update the code, push it, it's live. Open-source. All up to this point, open-source was sort of important, but maybe not instrumental. There were a lot of amazing things happening in open-source in the '90s, and it got more and more intense, but from a platform standpoint, people were using other stuff. Open-source for your apps, but from a platform standpoint, we're using Heroku, we're using Amazon. OpenStack shows up and says, hey, by the way, your whole entire cloud can be open-source. Wow, everybody got behind it and it was a huge success.
Then Cloud Foundry comes along and says, and by the way, your platform can be open-source as well. Pivotal and everybody involved there produced the Cloud Foundry platform to accolades. Then finally, Docker shows up in 2013 with container tech, and they didn't invent containers, it'd been part of the Linux Kernel for a while, but they made it easy. That's something that's magical. Companies that can just make stuff easy, make it accessible, make it usable, make it such that we can focus on what we really want to do, which is applications, not the needing of worrying about the platform. Cloud native then shows up as sort of the culmination of a lot of these things informed by all of these big components.
The Cloud Native Computing Foundation is the host for Kubernetes, pretty much the fastest growing, and by many measures, maybe not all of them, many measures, the most widely adopted orchestration platform, which is that third leg of the stool. So, a little bit more on some of these pieces then. Let's start with microservices. Microservices are ... I mean, you could define them lots of ways, but this is not a bad definition right here. A fine-grained, so small, right? Smaller than a service-oriented architecture service probably. Atomically deployable. That's really important, and a lot of people don't get what that means.
If you're going to have something that's robust like a highly available big iron and database that is running on really super reliable machines, you're going to pay a lot of money for that reliable ability and it's not going to scale, because you can only buy a computer so big, and at some point, it can't handle the load. Nobody at internet scale, nobody at hyper-scale manages state in a relational database backend. Sure, you copy data into them for analytics. They're super powerful for data warehouses, and that's good stuff, but for production applications, robustness doesn't get you there. You need resilience.
Because in the cloud, things aren't that dependable. You can't guarantee T that you've got high end hardware. Sometimes things break. Atomically deployable things make systems resilient. When I deploy a service, it starts up and it runs, and if it needs some other service, it tries to discover it, and if it can't find it, it just keep looking. It's atomically deployable. It stands alone. Even if it has dependencies, it just keeps waiting until it finds those things. It's looking for storage and storage isn't there. It keeps trying.
By making it resilient in this way, when it crashes, you can restart it, making things ephemeral, making them stateless, keeping the state in the platform gives you this atomic deployability, which is pretty important. Microservices, in the architectural pattern, are part of this cloud native thing, a deep and a critical part of it, and it's not just containers and orchestration. It's the way you build things. If you don't design something to be atomically deployable, it won't be, and no system can help you. Services are accessed by a platform agnostic API.
We use APIs that don't wire us to a platform, not windows, not Linux. We use implementation interfaces that don't wire us to a language, not the JVM, not .Net, not anything else. No matter what language you're using, no matter what platform you're on, you should be able to consume these services. The idea of microservices is pretty fundamental to this whole cloud native thing. It's an architectural pattern and you business align these services, and by making them small and symmetric, where they can just talk to whoever they need within your context, they can evolve and self-organize.
The idea is to define an application. A lot of enterprises build Mongo databases and have tons of different applications that are all kind of cross-wired together, linked through the database tables. It makes it very hard because you create this giant gridlock. In a microservice solution, all of the stuff is one application. If you want to talk to it, you have to go into its context through a well-defined contract, which is a coarse-grained highly abstract facility that gives you the services that you'd expect when your application is being accessed at the boundary.
These little guys can talk to each other directly, of course, and you might even create subsystems within your application, and this context might have its gateway where there's a contract, and this guy over here might have its gateway where there's a contract, and so this guy can talk to this context through its gateway, but he can talk to that service directly. In this way, if I want to reorganize my entire context, I can change everything in that sub system without breaking the outside world as long as I maintain this contract. So, each service, each microservice has its own contract, each subsystem has its own contract, and each application has its own contract.
But something that's fundamentally important about these microservices is that they maintain their own state. State is decomposed by microservice, not centralized. That means that if this guy wants to use a key value store, and this guy wants to use a document store, they should be able to. Now, people worry that this is going to be a runaway mess. I'm going to be supporting an application with 17 databases all over the place. Well, 17 databases you might have, but you won't have 17 database servers, and you probably won't even have to manage them. Because if you're an enterprise moving to the cloud, every cloud provider provides you the hard stuff, the state management.
If you want messaging at scale, the state management that's going to bring that to the table for you is maybe Apache Kafka. You can get Kafka as a service from Amazon, Kinesis Streams. You can get it from Bluemix in their, what do they call it? Their message hub. Everybody's got something that gives you the stateful messaging, and they've also got something that gives you the database facilities. If you want to use those platforms, you can just consume these services. You don't need to build them. If you like Cassandra, you can use [Cila 00:23:47] on Bluemix, it's a C++ implementation of Cassandra. If you want to use DynamoDB on Amazon, and it's a document store and works nicely as a key value as well.
You can create aggregates for each of your microservices using this same platform and it will scale to the, to the internet side of things. You've got great tools that are starting to become very rich and developed. That means that in each one of these microservices, you've got your own schema, your own model, your own style of storage. This guy right here might be using DynamoDB, and then might want to switch over to MongoDB, or something like that, or maybe even go back to a relational database for whatever reason. So, you've got the choice there without creating a huge burden on the IT side of the management side, because you're getting these things in a platform most of the time.
Now, some companies like Netflix run their own database servers, and there's nothing wrong with that, but they don't give people the ability to just go nuts. They use a Cassandra reign for a lot of things, and different applications use that same cluster, but create different key spaces. So, each service essentially has its own database, but the platform, whether it's being outsourced, or whether you're running it, can be limited. You might think about, let's give the applications a key value store, a document store, and maybe some relational services, and then they can create whichever databases they want in any of those, but from an IT service standpoint, we're just going to support that stuff.
A lot of the components of these platforms are built around very well-defined interfaces. They're technology agnostic, they're polyglot friendly. Again, loosely coupled. So, our interfaces are capable of being evolved. We can change them and improve them. So, we use things like Jason and XML, more Jason, of course, to give us the flexibility to maintain our contract, but to add things to it down the road that doesn't break the backwards compatibility. Each service itself has a single responsibility. By making them loosely coupled and capable of evolving, and by keeping them internally, highly cohesive, we've got this Liskov's substitution principle working for us.
We can change out the internals of a microservice without violating that contract and without anybody knowing. The next thing that we can maybe talk about is, what do we get when we do microservices? When you get the ability to deliver software faster, do you ... Well, if you do it right, and if your application is well-suited. This isn't always the case. There are times where you shouldn't do this, but we'll talk about that in a second. But if it's right, if microservices are right for you, and if your culture is ready and you invest in it, and you get it done correctly, as demonstrated by a number of companies, but not everybody, you can deliver faster.
It's because you have a one to one relationship between the team that's building the thing, because one team can own a microservice, should own a microservice, whether that's a scrum team, or what-have-you, working with Kanban, or any of these agile technologies. The idea is that a single group can release a product that can go to market. Because it's atomically deployable, even if your service provides some cool new functionality, but none of your consumers know how to use it just yet, it doesn't matter. You've deployed it. That feature is in production, and people can test it, experiment with it. Maybe you roll it into staging first, but these guys can actually get it out in front of people who can start commenting so that they can get feedback on it.
They can move that thing through the whole system instead of hitting a wall right here, because their one thing that they're releasing is not atomically deployable. It's a module that's part of a large thing that needs to be integrated, and 15 teams are going to need to come together before it gets released. So, we want lots of small risks, not one big, giant risk. So, fine-grain scaling is another feature. If you've got a monolith like this, and this thing, you need 17 copies of, but this thing you need one copy of, and this thing you need two copies of, well, you're in trouble. It's a monolith.
You're going to have to have 17 copies of it if you need to get 17 copies of this one little piece, but if you've broken this up into microservices, you can have 17 copies of this guy, two copies of that guy, and one copy of that guy. That's really a useful feature to some. Flexibility to embrace newer technologies. If I'm using a microservice, I can try some new frameworks, some new programming language, some new technology inside this microservice, and it can be implemented quickly and easily, because a developer who knows what they're doing should be able to rewrite a microservice in about two weeks. So, it's not a giant endeavor to try something. It doesn't risk your whole entire application.
If it doesn't work, we should be able to easily roll back and it shouldn't be a giant cost. If it does work, it could be a game changer for us. Companies usually are kind of scared off of new technologies because of risk. So, it's all about lowering the risk, taking small risks so that we can move forward, rather than avoiding the risks because they're too big. Organizational alignment is another key factor, breaking things down by the business, responding faster to change. Being able to compose applications. Object technology promised us reuse, and a lot of people haven't seen a lot of that. Some have, but a lot haven't.
Composability is something that is a hallmark of microservices. One of the great things about microservices is they're atomically deployable. If you have a service, you can actually stand it up and use it by itself, and if that's true, then you can drop it into lots of different settings and use it. If it's got a generic, single responsibility, it's more likely that you'll be able to reuse it. Then resilience, of course. Since we're always going to have two or more copies of these little services running, if one fails, we're not out of business. The design of an application that's microservice oriented is going to help us with that resilience. We're going to focus on that in the architecture, not just trying to be robust. Well, there are downsides, right?
What are the challenges? What do we need to prepare for if we're going to try this? Well, there's a lot of strategies that companies take. Some hold off until they've got a Greenfield project to try this with. Some take a particularly problematic brownfield project and pick a piece of it to try to peel out and break into microservices to see if they can get better scalability, faster innovation on that one part. There's no reason you need to redo your whole architecture. If something's working, don't fix it if it ain't broke. But if you've got problems in a certain place, you might want to try.
But here's what could happen to you if you're not ready, an explosion in the number of processes. This is the pets and the cattle analogy. This thing, this big giant thing right here, a VM is a pet, and everybody knows its IP address, its domain name. We care for it, we look after it, we monitor it very, very closely. It's a known entity. On the other hand, if you took this piece of it and the state that that thing uses, and you put that into a microservice and you ran 50 of them, there's 50 of them and they're just individual services, and we really don't care too much about them.
One crashes, another ones starts back up somewhere else. That's what dynamic orchestration does for us. They're cattle. We just care that we have enough to produce the 50 gallons of milk that we're supposed to produce every day, or whatever it is. You get tons of these things. If you don't have the tools to handle hundreds or thousands of individual services running around in your infrastructure, then you're not ready for this. Also, this is all pretty new. A lot of teams haven't really gotten agile working with the old stuff.
Now, you might be more successful with microservices, but it's still a new thing. Books are just starting to come out to help us with some guidance and some ideas, and we're starting to get some actual, in the industry, real practical experience in the enterprise. There are pioneers who've done this and done fantastic with it. There are startups who have done this and done fantastic with it, but enterprises with systems that are running on mainframes, and mid sizes, and servers, and virtualization, and all of this stuff, and the cloud, they're all over the place and trying to evolve, and then they buy somebody else who's got a whole bunch of other stuff, and we're dealing with enterprise service buses, and things from 15 different generations of software. Those hard problems.
There's hard problems ... A foot here if you're going to try to tackle this stuff and you need to sort of fence off an area to try it with, rather than trying to do any sort of holistic approach to this. Heavy network utilization. This function calls this function, calls this function. Over here, this guy makes a network call to this guy, which makes a network call to this guy. If you don't have robust data center networking, like you get in the cloud and that sort of thing, this is not going to work.
Small to medium applications can be harder to build and deploy this way. If you're building something small, that's the easiest way to do it, build it as a monolith and grab a database, grab a SQL database. It's the best understood database out there. Grab MySQL, code it up from end to end until it works, and you're done. Simple applications are going to be much easier to build in one piece than by trying to create all these containers and orchestration for something that's more or less trivial. A lot of people make that mistake. You may even want to start with a monolith, even when you know it's going to grow big and you're going to need microservices down the road, because you'll better understand the application after you've taken a look at it, and you'll be able to start down the road to microservices with a better set of scopes and bounding contexts and ideas for which services you need.
Then finally, integration is no longer anyone in devs problem, right? You can't release this thing until all of these teams have figured out how to make it work. You can release this thing anytime you decide you'd like to, and it may of course, break the world. Now, if you do it right, of course, that won't happen. You'll have backwards compatible APIs and your new features won't hurt anybody else, but you know how it goes. It takes an organization a while to develop the discipline, the technologies, and the workflows, and the business practices that get us there. So, there's challenges. One of the biggest things that hits teams is really that, it's the culture, it's the workflow, it's the process.
The business has to be on board for this because it's going to change everything in the way that the organization works. All of these companies, eBay, Twitter, Amazon, and the list goes on, but these guys spoke at a conference and did a talk about how they evolved to microservices. You used to have a UI team, a middleware team, a set of DBAs, and where all of these guys have gone is to teams that are cross-functional, truly cross-functional. Not just in name, not agile teams that just live here, because how can you produce anything that anybody can use when you only have a piece of the stack?
These guys build supply based microservices. They understand that domain in the business. They are responsible for several probably services in that space, and maybe even in entire subsections of the application. These guys handle the order stuff, these guys handle the recommender. They all have their expertise and their disciplines, and they all have things to learn. You don't just come from a UI team and hop into a cross functional team and know everything. You need meet other players with other perspectives in order to get it right. But the beauty is, when you bring all of these disciplines together and you do it right, that's when you actually get the fruit from the promises of agile.
If we're building all of these little services, that's great, but when you deploy a service and you install it on the host, it's going to interact with all sorts of stuff. If these services are small, you need to deploy a lot on the host in order to make it make sense, and now all these interactions are going to kill you. We need a better way of deploying things. Well, one approach was to really lock down our apps and then to do infrastructure as code, and use puppet or chef or whatever, and have these guys do the deployment of our software and all the dependencies.
But then the problem is, when somebody else wants to install something in that same environment, they interact, and again, we have an explosion. What we need is a package that's isolated from everything else that we can deploy like that tree in the picture, where you can have all of these boxes running on the same server, but each one of them has its own file system, its own network namespace, its own process namespace, its own inter-process communications namespace. If this guy creates a chunk of shared memory, no one sees it, but him. If this guy creates a file, no one sees it for him.
That's what virtual machines gave us, but at the cost of running an operating system in every single one of these boxes, and the operating system generally had more overhead than the app. So, inter containers. Containers are lightweight Linux environments, and as of 2016, Windows got in the game, and Microsoft, not always early to the table, but when they show up, they show up big. They went crazy, and in amazingly short period of time, augmented in Windows 10, Windows Server and Windows 10 with a full-blown Docker support. So, we're now in a world where the two key operating systems, Linux and windows, give us the ability to run containers, and there [inaudible 00:37:47].
That's the magic. All of that stuff in that tree planner, we can just drop onto a system and run. Because everything that you need to run that app is inside that box, except the Linux Kernel or the Windows Executive, and that's already there. That's the heavy piece. Everything else is pretty lightweight. When you Docker run a container, like say an Ubuntu environment, and you execute your program, in this case, just a simple example, it's going to happen fast, 319 milliseconds up and down. If you compare that to the time it takes to boot a VM, well, that's pretty impressive.
Also, the is only going to take up about 100K on disc about one and a half megs of RAM. Remember, the smallest kernel that VMware, a bunch of really smart people, could build with 68 megs. This is an incredible improvement in the ability to pack things onto a server that do work you care about. Operating systems don't do work you care about, applications do. If I can have one operating system and 70 applications versus 30 VMs with operating systems and applications in them, I'll take the 70 in one every day.
That's what people are seeing. They're getting huge server density improvements by going to containers. They get a greatly increased improvement in reliability because they're deploying everything that they need inside that container compared to installing things with scripts. Docker made this stuff popular, but they're really just using the Linux technology that's already there. If you're running Docker and you start up 40 containers and Docker crashes, the containers don't care. They're just processes running on Linux, and Docker just is responsible for starting them and for monitoring them and controlling them.
There's a lot of stuff happening out there in this space and we've got standards cropping up, but this is sort of a model. When you compare, and this is a courtesy of IBM, when you compare a virtual machine running at a hypervisor to a container running on an operating system, you can see there's only one operating system here. You've got Linux, and then however many containers you've got, 50 a hundred, but every time you start up a VM, you're starting up another OS. Now, there's pros and cons to this. VMs have been around a long time. The Intel processor didn't originally support virtualization, really.
If there was an error here, there was a hardware error, we would shut the whole system down. But progressively, Intel has added features to the Intel processors at the point now, where if you were trying to attack this VM from this VM, it would probably be no easier than if you were on a completely different computer on the same network. We have multi-tendency and these VMs that is really powerful. The isolation's powerful. So, you're going to use a cloud. Basically you're going to be creating VMs if it's a public cloud, because you need that multi-tendency isolation.
Then inside those VMs, you can run your containers. Of course, you're not getting as much benefit because your VM is still running an operating system, but you can pack many, many containers onto that OS, perhaps, if you size up your VMs right. The other thing that happens when you run containers in the public cloud on VMs is you're also getting that reliable deployment, that fungibility, where you can move things around readily, and the benefits of the model, the statelessness and all of those types of things.
Docker really has a cool functionality here. It's providing this [inaudible 00:41:14] that lets us start up containers. It has a REST API we can interact with, client tools, and it has scripts that allow us to automate the build of these containers, all pretty important features. The old package management, where we install things on systems, whether it's a RPM that we install with yum, or a DEB that we install with apt, or whether we're using some of these scripts, the world started changing here. We're seeing every single cloud out there provide container registries now.
Bluemix has a container registry, AWS has a container registry, Google has a container registry, Amazon has a container registry, Azure has a container registry, and you can run your own container registries. Of course, Docker hub, sort of the home of all container registry, so the mother of all container registries with its massive selection of open-source, you can just Docker run or Docker pull these containers, and they drop down onto the computer and they run. Folks are moving to a minimal base OS. We don't care about the operating system. We don't care about the hardware. We just want to run our containers.
So, we run Docker and we run a super stripped down Linux, because we don't need anything from the OS, except the ability to run containers. Those OS's are being provided by everybody. Ubuntu has Ubuntu Core, stripped down minimal Linux OS, smaller attack surface, faster to boot, red hat has atomic. Again, super lean and mean, easy to deploy. CoreOS has Container OS. Used to call it CoreOS, now it's a Container OS. VMware has photon. Windows, even Microsoft has Nano, which is Windows without Windows. It's a stripped down super minimal server operating system without Windows.
Obviously, the windows executive, but not a GUI. This is the model. Stripped down minimum Linux or Windows, a container manager, Docker, probably, and then you just to have some sort of scheduling system that deploys containers on these nodes and moves them around. There's a whole ecosystem of registry servers that we can buy or borrow and deploy containers to all sorts of different environments, and there's also standardization that makes it very easy for us to trust that we're not going to be locked in. The open container initiative started in 2015, and as of 2017, we've reached 1.0, and we've got a runtime standard.
If you drop a container on a system that supports the OCI, it can run that container. It doesn't matter who built it or where it came from. There's an image spec that identifies the way that the actual container files will be organized and laid out. This is the interoperability that everybody looks for, and that's why everybody is behind this. Amazon, IBM, Google, you name it, they're all there. This is an old list. The list is much larger by today. We've got standards. We've got really useful open-source tools like Docker, and you've got huge benefit, and we're changing the world here. We're seeing some fundamental shifts in the way people do things. Rather than installing RPMs, they're pulling container images.
Rather than building applications that are chunky and fill up entire VMs, they're breaking applications down into small parts, but we're still missing a really critical piece. It's great that you can run a container on a system where you've got Docker, but what happens when that system blows up? To really be resilient, you need a cluster of computers. No one computer can be resilient, and so we need to have lots of computers that we can run containers on, and those containers, when a system fails, have to be relocated. So, there's got to be some mothership, some orchestrator that watches over all of this stuff, and indeed there are.
These orchestrators pull images from registries, schedule them to node somewhere in the cluster, and take care of logging, and scaling, and rolling forward and rolling back as versions need to be patched and replaced, and also dealing with service discovery and high availability and load balancing, the routing meshes and things like that. This is the most complicated piece of the kit that you need to actually get this stuff done, and it's why it's the last one to show up. A year ago, my firm was not probably going to recommend that too many people do cloud native in production just yet. Because the orchestration platforms, a year ago, literally just a year ago, were kind of just getting there.
I think today the view is very different. We've got some pretty mature solutions. When you look at what's out there Docker has Swarm, and Swarm has matured a lot. It's a completely different thing than what it was two years ago. Kubernetes was contributed to the Cloud Native Compute Foundation by Google, and it, at its 1.0 mark, was great, but maybe not what you'd want for production. It was a good thing that showed you where the world was going. You could develop on it, maybe use it for testing, but unless you were deploying pretty small apps, I probably wouldn't use it for something huge in production when it first hit 1.0.
Mesos has been capable of running really big stuff for a long time, because it's been around for a long time, but it's been focused on big data. It took Twitter and the Aurora project to actually start doing containers on Mesos, then Mesosphere shows up and provides Marathon, which is pretty cool, but Kubernetes has been growing like crazy. Today, it's hard to argue, I believe, that there's anything as rich and feature complete and mature for container orchestration as Kubernetes. That's why it's got the rating that it's got in surveys, and different solutions are out there that you could look at, but you can tell pretty clearly, this is the darling in the space at the moment.
Why not platform as a service? What about Heroku, or Cloud Foundry, or OpenShift or any of these things? Well, there's nothing wrong with any of those things, as a matter of fact, they're wonderful. But these systems were based around pushing code, and when you push code, then the system's going to have to build that code and package it somehow, and so we have to have build packs and that sort of thing. What if I'm building my app in Erlang? You're not going to find too many paths that are Erlang friendly, or that are OCaml friendly, or that are even Go friendly, frankly, until fairly recently.
You had to have the right build packs, you had to have the right tooling, and then this thing is building in its environment. So, your developers are doing one thing over here, and then they push their code and it blows up, and then they're saying, it works on my machine. Well, that's something we hear a lot. These systems say, hey, once you build this artifact and you test it, make sure that same artifact is what you push forward. Never rebuild it. That's true. But you also shouldn't be rebuilding the package that it lives in with all of its dependencies and things. So, we get containers as a service.
Containers, as a service is the exact same idea as platform as a service, and all of the platforms as a services nowadays support containers, if they're worth their salt. So OpenShift, for example, which didn't use to is now based on Docker and Kubernetes. Cloud Foundry uses the OCI and has the Guardian container manager and Greenhouse on Windows, which is container-based. All of these passes have provided all the rich functionality that they've been providing, but now give you the ability to program in any language you want, package your application the way you need to and hand that off for testing, and containers as a service then run these things in production at scale.
We've got a lot of great technology out there provided by many different players. Amazon's kind of the only cloud left doing their own container manager. They have the EC2 container service, but the big news is, a couple of weeks ago, Amazon joined the Cloud Native Compute Foundation, which is the foundation that owns and curates Kubernetes. So, we may see some shifts there. Stay tuned, I would say, for Amazon reinvent coming up here. Google Container Engine is Kubernetes as a service. OpenStack Magnum can deploy Kubernetes as a service. Azure container service. Microsoft bought DiUS from Engine Yard, which was a Kubernetes-based pass basically.
These guys joined the Cloud Native Computing Foundation. Yeah, you heard that right. Microsoft joined the Linux Foundation. In November of last year, Microsoft joined the Linux Foundation, which they had to do to join the Cloud Native Computing Foundation, which was announced a few weeks back as well. Kubernetes has a lot of wind at its back, and there's a whole lot of really great sort of provisional container tech out there. It's just like what happened with VMs. Intel got behind it and it got better and better. Other vendors started producing stuff, it got open-source with KVM and Zen. Same thing going on over here, you've got clear Linux, which is ... And the clear container project where VT extensions and things like that are being used to make the Linux Kernel even better and better with containers, more security, more isolation.
VMware has VIC, which is vSphere Integrated Containers. If you love your VMware platform and all the tooling, but you want to do containers, there you go. They've provided you with the ability to literally run containers right in your vSphere environment. RunV is a hypervisor based solution for OCI so it's basically like VIC more or less, but using KVM and Zen, and you've got LinuxKit from Docker, which gives you the ability to build custom Linux solutions that you can then run in a container or with various models, or run containers on. A lot of ancillary tools.
The late bloomers out here, Oracle announced, I believe, two or three days ago, that they're joining the Cloud Native Compute Foundation, and they also announced back in June that they're going to be basing a lot of their new tooling on Kubernetes. Microsoft, Amazon, everybody is jumping on board with this model. It is not a fad. There's huge energy behind it. Containers at scale, can we do it? Yes, we can. Pokemon Go is a GKE based app that runs on Kubernetes as a service from Google. They have an average of 30,000 containers running in their cluster, spike's probably much higher than that, 50,000, something like that. Google has been doing this for a decade. They've been doing it for a decade, right?
They run Docker on machines in their GKE environment, but in their own world, they've got their own container manager, and they run Kubernetes in order to execute containers in their GKE cloud, but in their own environment, they've been using Borg for on a decade. Now they've actually got a successor to that called Omega. There are some great white papers that are documented down here. There's the Borg paper, the Omega paper, the Google paper that talked about Pokemon Go going live. A lot of great stuff you can read on very high scale, highly demanding workloads. Netflix is a complete microservice solution, though they built their own tooling because they kind of came into the game early when we didn't have these great open-source tools.
I'll leave this for your reference. This is a little timeline. Google Borg shows up in 2004. Container technology hits the Linux Kernel. Docker gets to 1.0, Kubernetes shows up at 1.0 in 2015. It just gets really compressed, and things are moving so fast. We've got Kubernetes one-seven, and one-eight's coming. All of this open cloud native stuff has a center, a center of gravity, I feel anyway, and it's the Cloud Native Computing Foundation. Full disclosure, my firm's a member of the Cloud Native Computing Foundation. We're in the graduating class of Kubernetes managed service providers, but I am also personally, an Apache Thrift PMC member in committer.
I love Apache, I love CNCF. But CNCF has got huge momentum in this cloud native space. Apache's doing all sorts of wonderful stuff, but where this area is concerned, the Cloud Native Compute Foundation is just a real force for good, and there's tons of members. I mean, everybody's joined by this point. Everybody that really matters is joined. Apple's not in there, but they don't care about any of this stuff. They're focused on the front end. There's a great landscape slide from the Cloud Native Compute Foundation that kind of breaks things into layers. If you're going to run cloud native stuff, you might want a cloud to back it on, which would be an infrastructure as a service solution that you could just stand up. If you automate the provisioning of all that stuff with Terraform or Heat CloudFormation, something like that, then you can change clouds if you want to, or you can go hybrid and run in two clouds in case you don't trust any of them.
All of these players are options, OpenStack, VMware, or Bluemix, what-have-you. Then you've got provisioning tools and systems of that nature. You've got your run times. So, we have your compute runtime bits, which rkt open CI, or open container initiative Docker. Then you've got your storage components, S3 and GlusterFS and Ceph, and so on. You've got your software defined networking components that fit into this world. Your Calicos, your Canals, your Flannels, your Docker overlay networking, things like that. Then you've got at the orchestration tier, you've got Kubernetes, but there's also Docker Swarm, which is great for some people. There's Mesos, which is awesome for a lot of people, Nomad from HashiCorp, and then ECS.
There's alternatives too. It's not just a one horse game. You've got a lot of sort of highly consistent key value stores and solutions that work with these cluster services. Service management gateway types of services, Envoy, by the way, project just joined the Cloud Native Computing Foundation, Linkerd, a project in the Cloud Native Compute Foundation. GRPC, a project in the Cloud Native Computing Foundation, etcd, I would imagine is in the pipeline and is been looked at. Might make it in at some point.
There's a lot of projects that are kind of coming in, and being CI'd together to make sure they're interoperable, and that's another feature that the Cloud Native Computing Foundation is bringing to the table. Then lots of high level stuff. Then there's also complete stacks. Many enterprises don't want to figure this stuff out, right? And this is a simple model. There's a newer version that has lots and lots more logos on it, but you could, for example, buy a complete solution from Apprenda, you could buy a complete from that, Apcera, you could buy a complete solution from Microsoft like these. You could get Kubernetes outsourced it as a service. You could use DCOS. DCOS is the Data Center Operating system from Mesosphere, which is based on Mesos, but they've announced Kubernetes running on Mesos, so you can run your big data frameworks and have your Kubernetes too.
There's all sorts of great options out there and it's a growing space with lots of service offered from professional vendors. A lot to talk about in a short period of time, but hopefully, what the seminar did is it got you some insight into how important and dynamic this space is and how many really cool and interesting things are happening, and what the possible fruits are from really, truly being cloud native. I thank everybody for coming. Thank you for your time, and I will hand it back to our wonderful host at ExitCertified.
Thanks, Randy. We are running a little bit short of time, but if you have a minute or two, we have a couple of questions that you could address. For everyone on the phone, if you do have other questions, you can still put them into the chatbox and we'll be sure to reach out later with the answers. Randy, could you please point to you some recommended online resources for additional cloud native information?
Absolutely. One of the best places to get some opinionated views is the cncf.io. So, cncf.io, that's the website for the Cloud Native Compute Foundation. Another place that you could go is there's a little trade rag, and if you Google for it, it's called the Microservices Weekly. I really liked that, lot of great insights from the Microservices Weekly in this space focused on the microservice side. Then there's The New Stack. The New Stack. I love those guys too. Those guys write up a lot of great articles on this whole space, the cloud native space, and they cover a lot of sides of the story, the pros and the cons, the different vendors. It's a good rag. I love that. Another thing that you might want to subscribe to, or check out their website.
They also have a lot of great little eBooks that you can download. They have one on the Docker ecosystem, or using Kubernetes, or getting started with microservices, stuff like that. Really great reads that have been contributed to by lots of different vendors.
Okay. Then we just have one more question here right now. When you were talking about the microservices attributes, you referenced contracts, could you define that word in that setting? Back on slides 10 and 11.
Got it, 10 and 11. Could you repeat the question one more time?
Could you just define what you mean by the word contracts when you were talking about that there?
Contracts. Gotcha. If I'm building a microservice and it's got an API and somebody's using that API, that API is a contract. If I violate that contract, they're going to break, or maybe many of them might be using this thing, and so it kind of breaks the world. So, you want to be very careful about what you expose, first of all, because if you get into a contract, it's binding, and you want to provide just the features that are needed. The fewer things that you provide in that contract, the more flexibility you've got internally, of course. There's different ways that you can define that contract. If it's a REST API, REST API, and many people say that's schemaless, and you can just go crazy and throw whatever you want out there, and people just sort of figure it out and consume it, but I think that's something that people figure out is not true really quickly.
There's a lot of ways to define that contract in a way that is completely implementation independent, for example, OAI. In the world, there's Swagger, RAML, and Blueprint, and other things that you can use to abstractly describe a RESTful service interface, but OAI, in my opinion, sort of has the wind at its back, and Swagger too, got contributed to the open API initiative, and now you've got Google and, I want to say IBM, and a bunch of others. I don't have the list in front of me, but there's a huge number of vendors behind OAI. OpenStack interfaces are now all OAI, like Kubernetes interfaces are OAI described. So, there's a lot of momentum towards describing your interfaces in OAI, and that then becomes your contract.
You say, I will do these things, and these are the semantics associated with them. The other two big microservice interfaces are GRPC, which is a CNCF project. GRPC is the Google Remote Procedure Call, and that runs over HTTP/2, which has a lot of awesome properties, and GRPC is based on protobuf. So, you describe those interfaces with protocol buffers. Another thing that you could use would be Apache Thrift, which I'm particularly fond of, as you might guess. Apache thrift has its own IDL, the Thrift IDL, so use that to describe your contract. In all these cases, Thrift IDL, protocol buffer, IDL, or OAI, you've got a abstract purely interface descriptive way of saying what the contract is that your microservice is going to adhere to, and in all of those cases, you can add functionality and extend without breaking backwards compatibility.
These are all sort of the new generation tools. If you use like DCE/RPC, for example, you can't change anything or you break the world, and you have to recompile the whole world, and that's exactly what we don't want in a microservice environment, where we want to be able to independently and atomically deploy that one service. So, if we upgrade this guy from V1 to V2, we want to be able to deploy V2 without anybody else breaking, and to do that, we've got to know what this contract is, so that we can maintain the V1 contract, but add the features for V2.
Okay. Thanks, Randy, and thank you everyone for joining us today. Just as a reminder, we will be sending this recording out after, and we hope you enjoyed. This concludes today's webinar, and you may now disconnect. Thanks.