What is cloud native?

all right it looks like we are broadcasting now this is our first time trying to live stream this from YouTube it seems like some folks are having trouble joining the Hangout so if you give me just a moment here I am going to see if folks can join and so it looks like some folks I've joined have been able to view the link via our YouTube livestream so we're trying this out a bit new where we want to stream this training live to YouTube so anyone anywhere can can join and view in there should be an ability for folks to also join the Hangout so that they can also be on screen it looks like that permission model is not set up so while we're working out the kinks please do type any questions or interactions onto the YouTube chat and I'll also be checking that through the through the live stream today and we'll do Q&A that way as well and as we work out the kinks we'll set that up going forward so I will give a screen share here and today we are chatting about what is cloud native so this will hopefully give a understanding of both the technical bits at a high level of what cloud native is so that whenever you're talking to a customer or prospect about cloud native technologies or about other topics that relate to cloud native it gives you an idea so we do have a website page Gil ab-about Detlev comm slash cloud native these slides are also shared in the description of the YouTube video so you can go and check out the slides and all of the links on the slides will be there today the content is in the slide deck but I am looking to move all of this content on to the web so in the future this will be where you can access all of the get lab content about cloud native so to start out let's talk about what cloud native is not additive it's not simply taking an existing app and running it in the cloud so application architecture has changed over time you can kind of think of this like when the first movies came about really all they did was they took stage plays and recorded them with a video camera well you can do so much more you can shoot from different angles you can take advantage of the fact that it's a different medium and create something so much more complex and different so in the same way applications that run on a server if you just take that application and you're running it in the cloud that's not really a cloud native cloud native is about taking advantage of all the things that you can do when your workloads are in the cloud and architecting your app to run in that way so there are three elements in a nutshell that are described a cloud native architecture so that is they use containers they are dynamically orchestrated and I'll chat through what is orchestration and they use microservices so really at a high level these are the things using a micro services architecture taking advantage of containers and then using container orchestration those elements to an application architecture and how you design your applications is what's referred to as cloud native because it takes advantage of cloud cloud computing models and allows you to extract away the hardware so that you can scale so that you can have more resiliency etc the phrase was first coined probably around 2015 you can see other references to the term cloud native earlier but really this was the Linux Foundation starting the cloud native compute Foundation to propagate and to drive and to evangelize and to Shepherd this type of architecture that uses containers and orchestration and micro-services and I've linked the initial announcements there so let's talk about these three things containers orchestration and micro services and really when you're talking to somebody the orchestration part is really just kubernetes and really from one perspective folks may even just talk about kubernetes so if folks are saying they're using kubernetes odds are you're probably you can't use kubernetes without containers and you probably also have a micro services architecture so really if you're using kubernetes you're building a cloud native application so kubernetes is a bit of a shortcut for saying cloud native I'm just using kubernetes so the Shred about the containers bit what are what are containers and how does that application architecture work the idea here is this is the evolution of application architecture so in the early days you would deploy an application on bare metal you would need a lot of things by bare metal we mean on on a server a physical computer and so you need things like your application you need all of your libraries and all of the operating system that all lives on one server and if you have multiple applications they all live in a same server they don't they all share the same OS so there's not a separation for example well for security or for resource management they're all on the same server and so there can be contention between applications and that's a limitation of that model so then Along Came virtualization where you could have a virtual machine or a VM and that was run by a hypervisor on the on the physical machine but you could have multiple VMs on one machine and this has a lot of advantages you can take a copy of a VM and you conversion it you can roll back but of course it's not perfect because what happens is every single virtual machine includes your application includes your lab it also includes the operating system so every time you're copying that virtual machine you're copying the entire operating system so the newer technology is containers and what containers do is they're very lightweight way to copy your application they essentially copy only the things you need in order to make more duplicates of an application so all of the containers share a common operating system so instead of copy copying that operating system every time you can share that operating system you have a very lightweight way to distribute your applications so you can fit a lot more containers on the same amount of server resources than you can with virtual machines this is a visualization of what I'm talking about here's a physical server it has three applications on it or potentially copies of the application or they might need to be different servers and in order to scale that application you need to add physical Hardware when you're when you come under load and your server can no longer take that load of your application can no longer take the load in order to scale you just have to add more physical machines and it's a it's a lot of heavy lifting and you also then need some other type of software to load balance between those machines it's a inefficient and complex way to run virtual machines make this a lot nicer but of course the operating system is copied so when you want to scale you can run multiple virtual machines on the same machine on the same server you can run multiple VMs on the same server but again it's more resource intensive so when you scale you're still going to need more hardware not as much as it is if you're physically deploying because virtual machines can share resources on a on a machine more efficiently but you still need a lot of you still need more servers to scale so then this comes down to using containers here you can see that a container is going to run inside of a virtual machine on a server and because the duplication the the copies of or container are very lightweight you can run a lot of containers and you need fewer servers in order to scale so this is that one of the advantages of the container based architecture is they're lightweight and easy to copy so in a nutshell a container runs inside of a virtual machine that eventually runs on a physical server so there's always a physical server somewhere there are a lot of different types of containers there are Linux containers there's rocket I've added some links here to the slide where you can read about the histories of containers and more info in a nutshell docker is the most popular type of container and that is what gitlab supports so if it lab does not today have support for other types of containers we focus on building docker support so that then comes down to I have a bunch of containers they're gonna help me scale I'm I'm using that as my application architecture I'm deploying via containers instead of deploying via virtual machines but now I need to schedule or orchestrate those containers so for example if I have a bunch of machines I need to say which containers are going to run on which machines and if a if a container dies or an instance of an application goes down I need something to spin it back up so we call that orchestration it's it's taking care of where should a container run and keeping a life beat of is that container running and do do I need more containers there's a lot going on there but that's essentially orchestration and again like I said really when you think of orchestration just think of kubernetes the idea here is in the era of 2015 to 2017 there was many container schedulers there you had lots of options there was docker swarm there was kubernetes which was originally a project open-source by Google and Google's a large contributor to Burnette ease and you had things like marathon and Apache mesos and so what ended up happening and I've added some links there if you want to read more about container schedulers is that docker and mesosphere both adopted support for kubernetes so really kubernetes has won the race there maybe once upon a time there was a discussion around which container scheduler is the best but overwhelmingly the market has spoken and kubernetes has run it's really not a discussion anymore and 2018 container orchestration is the same thing as kubernetes this is really where the market has shifted as a side trivia note if you've seen the abbreviation k8s that stands for kubernetes it's basically because there's a k' at the beginning and s at the end and eight letters in the middle somewhat like andreessen horowitz but of course at gitlab if you are writing about kubernetes or blogging in any way our corporate marketing guidelines say to always spell out kubernetes and not to abbreviate it but if you've seen the abbreviation that's what it means further evidence that kubernetes has dominated a landscape is that every single company that could or that wants to has spun up a managed kubernetes service so I've listed a few of them here but there are actually more so Google has a kubernetes service a managed to burn a service Google container engine Amazon has released eks and Amazon kubernetes service asher has one iBM has one there there are many companies that have managed to brunetti services and the idea here is kubernetes is an open source project you can build and run it yourself but it takes a lot to manage that infrastructure and manage that kubernetes instance there's a lot that goes into that so by taking advantage of a managed service and abstract away that a lot of that hard work so with git lab we have tight integration into google kubernetes engine with gke we have some unique functionality that i really think no one else on the market has and we work very beautifully with gke and we also have official get lab support for eks but the reality is and one of the beauties of kubernetes is that if if these services are using upstream kubernetes which I believe as your in IBM and and many of them do the reality is you can take your application workload that's running in one kubernetes cluster and it's very very easy to to port or to copy that to another service so essentially it's it's easy to move between a sure or Google or Amazon or to run in all three because of kubernetes kubernetes is what allows you to have that portability so at git lab we have these official support for some but in reality is gitlab officially supports kubernetes in general and if a service is using what we call upstream kubernetes or vanilla kubernetes then get labs you just going to work there there are some places where that's not the case for example with Red Hat openshift they do not use vanilla upstream kubernetes they do some modifications for security and some other components therefore gitlab doesn't just work on OpenShift today but any service that's using vanilla kubernetes gitlab just works there this is kind of the stack to give you a visualization of the different components that you're using you have your git lab instance and that can be installed on and running in your manage gke service which of course is running kubernetes and kubernetes is orchestrating your containers so these are all the components and hopefully gives you an understanding of the difference between a container and kubernetes and a kubernetes service if you want to know more about orchestration or kubernetes in general highly recommended resource is the children's illustrated guide to kubernetes this was put out by some folks over at Microsoft Azure it's a great great resource and I highly recommended it is an easy read and will bring you up to speed on just what is orchestration more technically with that I'll give a quick overview of micro services which is the final component to cloud native and bringing this all together so the in the early days or I suppose even still today a simple application architecture is what we call the monolithic app means you have an application and everything that is running that application is in is in one place but of course this becomes really hard to scale and if a lot of people or multiple teams are working on what application can be tricky to do that development and it can be tricky to scale because if you need a copy of the application to handle more load you have to copy all of the application even if there are parts to that application that don't need to be copied so this is what's called decomposing the model if you take a part of the application and you break it out into its own service so here you have a service a and a service B and a Service C and you know this could be something like like an inbound point like a like a web interface that folks log into and that might be used a lot or this could be a database service or this could be it really any component of the app and what happens is you know service a that might need to scale more so you might have four or five or seven copies of service a but you really only need two copies of service B so by breaking these things out into different services and breaking your one monolithic application into each of these component parts that allows you to do development more easily because it allows a team to own a service and to end and not have to worry about the the innards of another service they just have an interface to it and it allows you to scale so these are kind of the benefits of what's called micro services architecture the reality is you don't need to start with a monolith and to decompose you can actually just start adding services and at once you get to a certain size and folks really are just building new micro services they're not adding to a monolith anymore perhaps the monolith doesn't even exist so as an example this is get labs architecture and this is from our develop architecture page this doesn't really show what's part of get labs monolith or what's part of what's broken out into a service but it gives you an idea of some of the component parts and what could potentially be broken out and more info will be coming in the future as part of our migration for example we are migrating to Google cloud platform and as part of that migration is to run get lab as a cloud native application that means micro services those micro services run in containers and they're orchestrated by kubernetes and we don't have that today but we're moving towards that in the future so you'll you'll see more info coming down the future of how git lab is actually breaking up artist architecture and running this process some other good examples of micro services at scale are folks like Amazon or Netflix is is one of the quintessential examples of micro services and here you can see that once you get to this type of scale where you have so many micro services it really just starts to look like a cloud of services you can see if this was all one application it'd be almost impossible for these companies to manage them anytime you committed code you have to worry about conflicting with all of the other code it'd be a mess or if you needed to scale you need to make complete copies of everything every time you scaled instead of individual services so you can see why large companies do this and even the benefit of smaller companies that don't need this level of complexity why micro services can really help them out a great resource if you want more info on what is a micro service highly recommend watching this video mastering chaos this is a technical overview of Netflix architecture and it's a couple years old but it is a couple it's really only two or three years old but it really is a great overview of what micro services are and how Netflix design their system so that's a if you want to know more micro services that's a resources I recommend and so cloud native apps can use containers it's going to use kubernetes to say where should those containers go and to also manage the underlying infrastructure and the the virtual machines so kubernetes is going to orchestrate all of that and you're using microservices in your architecture so what are some of the things that get lab does together with kubernetes i've alluded to a few these but i'll just share some more of them now so the first is our kubernetes integration this is like I discussed this is a generalized kubernetes integration it is really nice and it works with any it works with vanilla kubernetes or any service that any managed community service that is running from upstream and this is the best way to run git lab literally our most advanced features are only available to you if you are running kubernetes so for example things like deploy boards Canary deploys auto dev ops monitoring kubernetes monitoring and our web terminals you only get access to those features if you are running gitlab deploying to kubernetes and so you can run git lab anywhere you can run git lab on bare metal one of the advantages of gitlab is that it has a lot of flexible installation ensures you can install it and you can use git lab C ICD to deploy your application to bare metal to to virtual machines to anywhere you really want but where get lab really shines is that it is designed to run on kubernetes or I should say we are designing it to run on kubernetes and we're making rapid progress towards that today our helm chart which is the thing that installs Gil lab on kubernetes is in beta we're moving very quickly towards a general availability so then we would say git lab is designed to run on kubernetes and Gil lab is certainly designed to deploy to kubernetes so when when our users applications and our customers applications if they want to run those applications inside of a kubernetes cluster gate lab is the best way to get your software there that's where we really shine so this is just some screenshots of deploy boards and maybe this will make a little bit more sense now where each of these dots in the deploy board is essentially a container it's really something called a pod and if you want to know the different container I recommend that children's guide is a resource but you can just think of this as copies of your application in a container and the deploy board shows you how far you have how many of those instances that have deployed to you and what part of what's called your fleet is a complete so this is you know 23 percent complete hear things like canary deploys lets you deploy just to a little bit only a few instances and test the traffic there see how it behaves before I want to commit to deploying it everywhere of course automatically monitoring being able to get gitlab gives you access to things like what is the memory use a ssin what's the CPU utilization of my underlying hardware so I can see am I am i overloaded do I need to add more notes to my kubernetes cluster etc and of course web terminals which is really an amazing feature we probably need to do a whole training just on this because this is this allows you to introspect and troubleshoot the actual environment that you've deployed to this is where you know if I have a local dev environment things might work here but all of a sudden when I get it into the staging environment we're not getting into the production environment things behave differently because there are different versions and different modules and with this I can get a terminal straight into that and it can help with troubleshooting it can help with design there's there's a lot of fun things there so of course we have a kubernetes integration we have a gke integration which I spoke of before this allows you to create and configure kubernetes clusters with just a few clicks so again thinking about that stack this is like the gke managed service helps me manage kubernetes and get lab makes it even easier to use gke so really you can sign in with git lab and within a few clicks we create the kubernetes cluster for you it's a really nice experience there talk to our help chart already and one of the nice case studies that we have is that the CN CF itself the cloud native computing foundation is one of get labs customers and so I've linked the case study here and on our kubernetes page we also have a youtube video of them describing their cross project cross cloud pipelines this was the CI working group that's part of CN CF they use git lab to actually test kubernetes and core DNS and prometheus so they test multiple projects and they deploy those projects to multiple clouds including Google cloud platform AWS packet so this is a really sophisticated use case and they're doing it all using git lab which is really nice some other resources for you I did a webinar with William Dennis at Google that this goes through not only kubernetes and a nice intro to kubernetes but also a demo of our kubernetes integration this is a great asset to watch to learn more and also to share with customers the link to the youtube video is there and if you want just a five minute demo of our gk integration literally from start to finish from zero to a deployed application you can see what that looks like in five minutes using git lab our gke integration and auto devops so this is a really nice video to say you can go from zero to running in production and five minutes with git lab including the set-up time this is pretty and interesting there so with that I will stop the screen share it looks like we have just a few minutes left but I want to see if I can jump into questions that are in the chat so it looks like we have a few John notes that even Cloud Foundry adopted kubernetes yes Joe asks about git lab compatible with open the answer is yes we are compatible but it takes it takes a little bit of effort to make that work again because they're not running just vanilla kubernetes so gitlab does run on kubernetes or does run on OpenShift and it runs nicely but it takes a little bit of tweaking to get there number of customers using them together today I'm not sure what the question is there what what they would be using together Joe ass is their feature parity with gke or other services so that's a great question the answer is actually no there are a lot of things that gke does that other services don't do and vice versa for example if you're using Amazon's eks that has really tight integrations into all of Amazon's other services so if you're an Amazon customer and you're using all of these other things like slim I'm fine now like the thousands of things like besides ec2 but um you know if you're using their their database service and their their other services eks has integrations in those other hand gke does some really sophisticated things with kubernetes that I don't think anyone else does so for example gke has an auto scaling capability where it will monitor the amount of nodes essentially how much hardware or how many how many VMS do you have running on your hardware the way kubernetes works is it abstract away all of your hardware and it treats it as a pool of resources and you it will essentially bin pack the the asset here I recommend is watching that webinar with myself and William Dennis William Dennis describes that quite nicely but the idea here is that that GK will help you Auto scale it's a unique unique feature so each of these services have different ways that they they differentiate themselves and value ads that they bring on top of kubernetes looks like Joe asks we compatible [Music] there is a question here is is gitlab compatible with JIRA or get hab so there's a question here from from lili we're just about up so this would be the last one I answer but I'll try to hop into the chat since we're out of time and answer some more after after we closed down the we do get lab does have integrations into other products and you can visit our get lab calm about that get lab calm and you can see a lot more of other tools that we we do integrate with so with that looks like we're up on time I'll shut down the video and I'll continue in chat if it lets me continue in chat to answer some more questions okay thanks a lot

Channel: GitLab

Views: 6,594

Rating: 4.9157896 out of 5

Keywords: Product, software development, developers, programmers, code, cloud native, kubernetes, VM, bare metal, Microservices, Orchestration, Containers, Container Scheduler, Scale, GitLab, #hangoutsonair, Hangouts On Air, #hoa, #hangoutsonair, Hangouts On Air, #hoa

Id: jc5cY3LoOOI

Length: 29min 37sec (1777 seconds)

Published: Thu Jul 19 2018