Cloud Native Computing Foundation CloudNativeDay 2016 (Toronto), 6 Sep 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Architecture of Cloud Native - Brandon Philips, CoreOS

Description

Architecture of Cloud Native: Open Source Projects Powering Pluggable Infrastructure

CoreOS is building the components needed for a cloud native architecture. Cloud native applications require the strength of trustworthy infrastructure developed and supported by a thriving community. Independently useful, pluggable pieces of infrastructure allow for the flexibility to move applications in a multi-cloud environment, from cloud to data center.

In a deep dive into the open source projects that are pushing cloud native infrastructure forward from the container formats, container engines, and clustering software, this talk will share how various pieces developed by CoreOS can help to run a cloud native application.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Alright, thank you. So what I want to talk about today is the architecture that we're seeing emerge around Clark cloud native and how, at every kind of level of this architecture, the we're designing for various options for users and customers to plug in into their infrastructure into their existing infrastructure, maybe perhaps making new infrastructure choices, so first I want to introduce core OS and what we're doing core OS is a company with a mission of securing the internet.

A

This mission is not something that will accomplish tomorrow or in the next year or two, it's more a SpaceX style, we're going to go to Mars sort of thing and we're currently in low-earth orbit, and the architecture that we're going to be describing here is the first step that we feel towards achieving this mission and there's a few strategies in this whole cloud native thing that we feel are important in order to accomplish this mission. The first is the separation between applications and the operating system.

A

Of course, everyone who is interested in the term cloud native has already heard of containers, and this is what the mechanism that allows us to do. This it's about making servers, really really consistent, so that when I deploy an app to a server and I, take it back off or I, deploy two apps next to each other.

A

Those apps operate the same and can be removed without any trouble and then hopefully, through that consistency, we're able to actually improve the way that we do upgrades and manage the deployments of our servers to the end that we finally are able to simplify the management and overall way that we deploy applications into the infrastructure and the goal here is that we're not trying to create a platform that only runs behind the firewall or inside of some cloud environment where all these fancy api's already exist, but to do it on top of any infrastructure.

A

And so that's that's our mission and kind of what plays into this architecture and the things that we're thinking about in this architecture. These these, these major strategy points, and so the first thing I want to talk about- is really how we see people thinking about cloud native and roughing out the edges of what cloud native means and there's really three major components that we think about. The first is application packaging.

A

The second is Linux at scale or operating systems, virtual machines and physical gear at scale in order to support these applications, and the final is clustering, which allows us to mitigate the potential uptime risks to create systems that are able to achieve density and are easy to manage through AP is so. The first is about application packaging, and it's about consistency, and we win here because of this abstraction. This is something that we've never really had in the past.

A

In the past, our linux distributions have tightly coupled the idea of the application of the OS, which is a bit of a problem, because it means that people don't actually end up upgrading their their systems, and so what we've done with containers over the last few years is we've opened up this opportunity for building smaller Linux operating systems that have smaller pieces and less components to actually worry about, which means that you have the opportunity to not only reduce the footprint the potential attack surface area, but then also because of this abstraction, potentially upgrade them over time, and so the first kind of plug-in interface that can be achieved here in this whole cloud native space is through a shared image format.

A

So we have this idea of a container this container, that you can consistently pull down between any host and run, and in order for that to be successful, we need to have an entire ecosystem of tools that can package and build these containers tools that can host and upload and download these containers and hopefully verify those containers once they are landing on a machine and really run those on top of any container engine.

A

That's available, and this is work that's going on today, inside of the open container initiative, there's currently draft specifications for the oci image spec and we're hoping to get the image effect wrapped up into a 10 over the next few weeks and months.

A

Experts is Linux at scale and really this is a plug-in of a sort as well a place that people can make their infrastructure choice and still be able to adopt this style of infrastructure, because the requirements have shrunk down. So much of what linux operating system is we've kind of seen.

A

This explosion of you know container focused operating systems, obviously I'm particularly partial to our first product, which is core OS Linux, but it this this style of infrastructure means that people are able to take their exact same application as long as it's consuming the Linux ABI and they're able to move it around and they're able to kind of make that infrastructure choice for themselves, either late or early as they're, making decisions about what they want.

A

They're sort of cloud native infrastructure could look like, and it's all again a were able to do this because of this abstraction layer and the linux operating system starts to shrink and its responsibilities and comes down to the point of really just focusing on over the next few years, just a container engine.

A

That's able to take one of these open container image, specs and download it and execute it, and then the Linux kernel and some ancillary other systems like a management system through ssh and then a paid one which today is inevitably systemd and the advantage and the end the thing that choosing a Linux operating system and building the sought the Linux gives us is the advantage that Linux has had, and the reason that it's had such wild success over the last 25 years is that Linux is in a spot where it runs on top of any infrastructure.

A

So people can confidently use pretty much any particular linux distro today and ensure that it runs on top of their cloud platform of choice or inside of the virtualization platform of choice or inside of their bare metal environments.

A

So the next piece is clustering, and this is about enabling people to have a way of managing their applications over time, their cloud native applications over time and then removing this risk of uptime.

A

So really what we want to end up in is this world, where you have a bunch of machines, you have your key performance indicator, which is hey: I, have X number of requests for a second I want to handling and whether the application is healthy or not. So you are able to add more servers and you get more capacity as those servers spin up the container, that's running your application and then, similarly, if the server dies, you lose some capacity, but the application remains healthy.

A

And hopefully, what we'll also get out of this is the ability to upgrade and move from, say one version of the container to the next wall, keeping the application, the overall health of the application. The overall customer experience in good shape, so you'll, be able to say, talk to an API, say: hey I want to remove this copy of the container spin up.

A

This other copy upgrade the system over time and hopefully once you're you're, confident that its operating correctly get a fully healthy system and in the CNC F and four core OS, the technology that we are relying on in order to be able to do this sort of clustering system how these api is to manage. This is cooper Nettie's and we talk about it as sort of operations. Paradise. The things that it's promising are the things that operations teams and engineering teams have been pursuing and often pursue when they're thinking about deploying an application.

A

It's the dream that, as the business requires more of the application they're able to easily scale it out without having to redesign or replan the infrastructure that they've built for it being able to deploy a new code when they find out. Inevitably that there's a security vulnerability and some package that they've chosen and we're being able to fix bugs as they find oh shoot, we actually handled timestamps incorrectly.

A

We need to fix the bug in our applications that were able to make sales again we're able to run or reports again, etc, and then the sort of Holy Grail has always been well. I hope that when I deploy this stuff, it will actually tolerate.

A

If network operations, messes up network configuration or the power supply goes out in my machine or the RAM goes bad etc and at the RMA it that the application keeps running, I don't get paged I can handle it in the morning, and so there's really not a plug-in interface here so much as a shared architecture that we're seeing between all the different options that people are talking about in this cloud native space and the architecture is something that's super familiar to most of us. If we build web application. The architecture almost inevitably looks like this.

A

We have some sort of user on the web browser talking to the API server API server, maybe grabbing additional resources from other machines inside the cluster, there's a probably datastore for the thing, and that's it and I want to like think about this architecture and more more regularly articulate this architecture as we're talking to users about cloud native. One of the things that I think is a bit of an anti-pattern as we engage with customers and explain this stuff.

A

Is it's really easy to show every detail of what like Cooper Nettie's is doing or mezzos is doing inside of your ecosystem, but really it's about having an API that the the system administrator talks to talking to some command line tools and that there's some sort of primary data store that those systems are being backed by and I.

A

Think the the thing that we can get out of that by having this conversation at a higher level with people is to make it not feel so alien and not so unfamiliar. Still. If I talk to people today, you only get like a quarter or less of the room to raise their hands. That they understand what a scheduler is so they've used a scheduler based system and to immediately have the diagram of proxies and network overlays and etc.

A

It's just really overwhelming when really the architecture of cloud native is a pretty straightforward and well-understood architecture, cool and really the like. One thing that is just ever so slightly different than you know. Web application is that, instead of talking to individual Linux machines, we're telling individual Linux machines what to do in order to service the API requests.

A

Okay, so in our in our in our particular architecture inside of core OS, instead of it being some abstract like cloud native command-line tool, we of course use Q Burnett ease and at CD is the primary data store when we're talking about this style architecture. But it holds true for every single other sort of scheduler based orchestra, patient based system. That's emerged over the last five to ten years in the in the open source space.

A

Okay, so those are some like high level things about the value that cloud- actually brings to customers and how you talk about the architecture. But, of course, there's things that we talked about in operations and in how actual compute and infrastructure works that are kind of always Givens. These things are monitoring, storage, networking and authentication, and in this in these four categories, we're actually doing a pretty good job too, as we develop this sort of this style of building infrastructure. The first is kind of export formats around monitoring.

A

Well, so we have this diagram earlier, where there's these key performance indicators that you actually care about in your environment. But how are you actually gathering up this data? Most people are going to have a lot of environments. We have a very static, traditional, say nagios or something like that system, and one of the things that's emerged over the last year or two is the adoption of this cloud native project in the cloud native computing foundation now called prometheus, and what prometheus is done is it's a few things?

A

It's an actual implementation of a monitoring system, so it does monitoring and alerting the actual concrete implementation.

A

It's been working with other projects, in particular cooper Nettie's, to ensure that not just user applications, but actually the cluster itself is something that can be monitored, monitored and operated. And then what that means is that cuber Nettie's isn't directly integrating with you with Prometheus. It's not like a direct code import.

A

What it means is that there's some rough consensus between Prometheus and Cuban Eddie's around this export format for important metrics and then that's a format that anything can consume, not just Prometheus, but in this particular case, prometheus is used to consume those metrics and exports them as useful time series data to the person operating the cluster and similarly for at CD, we've metrics that can be consumed by Prometheus, so that now your API servers, all the infrastructure around Cooper Nettie's and the primary data store at CD can be consumed and well.

A

We're hoping to see is that through you know this sort of rough consensus building around how these export formats work, that the applications themselves that the customers care about starts, export these style of metrics.

A

We, the community around Prometheus, has built adapters to existing export formats and over time we hope to see the emergence of sort of standards and norms for applications wanting to be monitored in a cloud native way, all right so there's a bunch of other pieces, and this is primarily related to the compute stack, so identity network and storage, pretty fundamental to any IT operation etalk to and all of these things, to be perfectly frank: we're not going to rip and replace everybody's infrastructure in order to adopt cloud native into it.

A

It's going to be a transition they're going to have existing solutions for each of these. These concepts inside of their environment and what our goal here is inside of Coober, Nettie's and inside of cloud native, is ensure that there's a way for those enterprises to interop and interact with these things. So the first is identity inside of Coober Nettie's. We have introduced the thing based on a standard called open, ID connect, which is a thing that is extremely poorly named.

A

They took two brands that are extremely misunderstood, which is open, ID and oh off two, and then they slam. Those two ideas together into yet and even more obscure brand called open, ID connect and but the the technology itself is very sound. It's the thing that is powering identity inside of Salesforce when you log into google, it really is the kind of trust fabric of the internet, and so identity with open ID connect is something that we brought into Cuban Eddie's and we're starting to see.

A

Merge as well inside of cloud foundry and lots of other different projects and the basic architecture is that there's a relying party say to burnet ease in this case? There's the actual open, ID connect protocol and as long as somebody is compliant with that protocol, kuber Nettie's can consume it to be able to say engineer, sally is actually who she says she is and she's allowed to log in the cluster, and this opens up all sorts of opportunities for ways of leveraging existing identity incentive inside of enterprises.

A

So in the case of core OS and our tectonic product, we we implement oh IDC, but we are able to back it with ldap or people can take. Google applications is becoming very, very common for companies they're able to take their Google applications logins, so fubar example.com is able to login to kubernetes cluster, etc, etc. I put it on here.

A

Also, you AAA, which is the identity management system with inside of Cloud Foundry, is starting to there's a bunch of patches that have been going in over the last couple of weeks months to make it a fully compliant oidc implementation, so we're on a good path here to both bridge the world of existing identity inside of companies and that users expect and relying on the new world of you know: cloud-based identity all over the Internet.

A

The next piece is integration with networking infrastructure, so this is a emerging standard that has been worked on. It was first built as part of the rocket container engine that we built at core OS and introduced this open-source about 18 months ago or more, and the idea of the container networking interface is very straightforward.

A

What we're trying to do is inside of a lot of existing network infrastructures. You have this this thing you have one host and then one IP.

A

It's not a very sophisticated network, but that's just the way that the world is and in this container based world a lot of people want to in order to adapt to existing service discovery mechanisms like DNS, an able to use existing load balancing systems, they want to be able to give and I he to each of their containers, and so this is the problem that we were trying to solve and we realize there's a thousand in one different ways of solving this problem, and so, instead of trying to prescribe this is the one solution in order to get routable IP s between a bunch of containers.

A

What we did was we built this interface called scene, I and we've started to at this point. The community is pretty vibrant around scene I. We have a bunch of different networking vendors involved. We have a bunch of different folks like mazes and cloud foundry, using the thing. Kuber Nettie's obviously uses CNI rocket, uses, CNI and there's kind of a collection of vendors and options that are emerging around this thing.

A

The great thing about this is that, without really having to understand cloud native or engage with every single potential solution, around cloud native, the traditional consumers of of networking technology and the traditional vendors and networking technology can just target one piece of technology, ensure that that's something that can be readily consumed by lots of different options and again, like architecture, is pretty straightforward.

A

There's a container networking owner like Cooper Nettie's, it implements CNI and then the user, whoever setting up the system, maybe the network vendor configures the plugins and that's pretty much the end of the story. It's it's a straightforward technology based on really straightforward Linux interfaces, and then this is the the name of this is to be determined. This is in progress, sort of set of discussions that are happening between Cuba Nettie's inside the communities community between a number of different storage projects, etc.

A

People are very insistent that we call it si si, so we've played around with other terms like flex volumes, etc, but I'm going to try my best to get CSI is the name, and the idea here is that we have an interface where scheduling systems are able to tell the storage system. My expectations, around storage I need these qssi need to land inside this data center.

A

It needs to be in this failure, domain, etc, and that, however, those systems care to expose the storage, whether it's at the block level or the file system level of NFS, or maybe it's a cloud provision system like II, bf's or Google's, persistent volumes that those systems are able to consume it and it again it's an interface that keeps everyone kind of sane and having reducing the dependency graph and that the extremely large matrix of support that people have to worry about when they're wanting to select the storage vendor to like put into their cloud native solution all right.

A

So the big ideas here are that we're trying to create interfaces where people are able to rely on things like the of a container image.

A

In order to have a standard application packaging system and rely on that standard to interoperate between the way they host and the way they store, and they way, they eventually run containers building these things on top of Linux and shrinking the footprint of Linux, so that these sorts of technologies can be ran on sort of any sort of infrastructure that exists, whether that the cloud or bare metal, etc and then introducing the patterns of clustering to the customers without actually overwhelming them about what it means- and there is a very, very clear architecture here that we can talk about that is shared across all these different systems.

A

So with that I just wanted to close with what we're actually doing day to day, we have a system called tectonic, which kind of brings these things together brings together.

A

Identity brings through the Ku brunette ease into it kind of brings together core OS Linux into a coherent stack and there's a lot of technologies that are out there today that make all this technology possible, and there are a lot of things that we work on and that we contribute to what we want to do is kind of simplify and curate that stack for people who are interested in running their infrastructure in this way.

A

So, instead of it looking kind of like a sea of open-source projects, it looks like a well understood sort of enterprise stack of software. That is, a combination of both open source and some of our products like quay and and our identity and re identity systems and similar to that story of being able to run linux on it top of any platform. We want to be able to bring this whole stack of software on top of any platform, utilizing containers, open containers, etc.

A

To do that, and we want to always be telling the story of this. This infrastructure is something that's approachable, it can be deployed and be understood and it can be operated at scale without huge amounts of of learnings and complexity at the end of the day. What we're talking about here with all of this technology is we're not reinventing the way applications run, we're not reinventing that Linux process model. These are just processes that are executing network services that are talking to each other.

A

So it's combination of these three things together as a stack in a platform. So the final question, of course, is like. Oh, this all sounds good. Is anyone using this sort of stuff in prod?

A

This is a very, very common story. For me, there is a company that a very dynamic young company adopting this stuff about without talking to anyone. They pick up the instructions on khoros com. They see that it solves a problem. They have they their problem. In particular, was they wanted on-ramp new developers without having to teach them everything about configuration management without everything to teach them about AWS and the api's that are involved there? So they just picked up poros linux, AWS and cooper Nettie's. They deployed it on there.

A

They built their customer appointment systems by just consuming the api's inside of Cuba Nettie's built the dashboard that integrated with their configuration management system and their source control system. So people would understand where they are in the queue when their code was going to go out when they were going to be on call, and it was all automated by the operations team and they have this all running in production today and obviously this is always like harkens back to the harkens back to the old refrain.

A

Oh, this stuff is only good for those san francisco star apps that are always just using the latest technology because that's what they read about on the internet at one time, but we also have very large, publicly traded companies that are using this sort of technology as well using containers adopting chorus Linux.

A

These sorts of things so I FC gave a talk at our at our conference tectonic summit while back, and they were talking about like yes, we're publicly traded options exchange and we use these sort of technologies because we see the advantages of how using containers to move around our workloads actually provides value.

A

So they're they're running these things in both AWS and bare metal, for low-latency lots of transactions in a production environment, and there's lots of lots of other stories that I could tell about people adopting this style of infrastructure and they're adopting it readily because they do recognize that there are multiple vendors in the space.

A

Those multiple vendors have api's and ways to plug in into their existing infrastructures and then also provide advantages as they're thinking about their infrastructure is moving two three five and ten years sales, and it's because of the interfaces and the technologies that we're building today, they're able to paint that vision for themselves and paint the vision inside their organization.

A

So core oasis mission is secure. The Internet we're doing that with a bunch of strategies around separation of the operating system from the apps making service consistent, making it easy to upgrade simplifying application management and doing it on any infrastructure. I have a couple minutes for questions. You can find all of our Doc's up there at Korres compost, / q benetti's. There are people every day, just happily adopting this technology and with that I want to. Thank you thanks.