Is GitOps Replacing DevOps?

well good day everyone and welcome to our devops inbound round table we've got a fantastic panel here with us and a really exciting topic today's webinar or panel roundtable is sponsored by tri-center so we're very happy to be working with the good folks at trish memphis today putting this event on so our topic today is is get ops replacing devops probably heard a lot about get ops here and there maybe you're doing some get off we're going to explore that and talk a little bit about what it is where it applies maybe some thoughts about where it doesn't we'll see where the conversation goes so let me take a care of a little bit of housekeeping here my name is mitch ashley i will be your host and moderator here comes our panel on and uh we are recording the round table today so we'll send out an email to everyone who's attending all our participants with a link to the recording we don't have any slides so you won't have to deal with that uh but you can always share this with a friend and someone else can have or take care of it later or if you said something that you thought you want to go back and check out that's great for the recording as well now this isn't just our stocking we'll have plenty of opportunity to hear us speak um but we'd love to have questions from the audience so feel free any time during our conversation just as the flow goes uh there is the the you can do the question the q a tab there's also a chat if you just put something in public chat we'll respond to it there or try to wrap that into the conversation uh through it fit so the flow goes we'll just kind of take that as it is so either way just we'd love to have you interact with us so please do that as well also we have a giveaway of four gift cards that we're giving away at the end of the round table so stick around find out if you're one of our four lucky winners so let's move on to our great topic is get ops replacing devops so distinct pleasure of introducing our panelists here let's start with you tracy tracy reagan is ceo of deploy hub hi tracy tell us a little bit about yourself well uh hello hello all and thank you um thank you to the mediops group and trycenters for always inviting me to these i always have a lot of fun with them i am tracy reagan i am the ceo of deploy hub and one of the community directors for a new project in the cdf called ortelius what deploy heb and artelius is all about is creating a centralized catalog of basically deployment metadata around microservices so that you can track who's consuming them who's using them who owns them and where they're deployed excellent excellent so it's good good to have you on be with you on the panel again tracy thank you how about clint clint sprout is director of product marketing with trisentis hi clint hi and hello everyone again my name is clint sprov uh product marketing at trisentis um my uh primary role is uh defining the messaging and especially our devops story and helping customers understand how testing and quality fits within their devops journey and so i'm really glad to be here and glad to be a part of this wonderful panel excellent excellent uh next how about you brendan brennan old dairy is senior developer evangelist with git lab hi brett yeah hi mitch thanks for having me as well uh always a fantastic time i feel like i always get a lot out of these panel discussions and i love being able to talk through stuff and that's really my job for git lab is you know spending my time talking to developers and devops practitioners and other folks about you know what they're doing and and how uh they're making things work in their businesses or with their open source projects uh so i'm always excited to to get to chat through these kinds of things wonderful cornelia cornelius davis is cto with weave works cornelia great to be talking with you today welcome thank you thank you so much for having me a part of this uh fantastic team um again my name is cornelia davis i'm the cto at wheatworks and i've been at we for about a year um and prior to that i spent i've spent almost the last decade in uh app platforms so i was at pivotal where i first worked on cloud foundry and then in the last three years or so worked together with vmware on kubernetes-based stuff so i've been working in the kubernetes space for gosh nearly five years now four and a half years something like that so it doesn't make me a total veteran but it doesn't make me a noob either um in working on application platforms i've been in the devops space for almost that length of time probably even before we had the term i am part of the programming committee of gene kim's devops enterprise summit and um and so really i'm very very passionate about devops and we'll we'll have more to say about this because that's exactly the uh the point of the panel today is the relationship of devops to get us and there's a very specific reason why i came over to lead work swedeworks of course my founder and uh ceo alexis richardson is credited with coining the term get off so it's the center square on the buzzword bingo card but it's kind of a cool term and then finally i'm also yeah it's uh i'm also the author of a book that i wrote with manning um called cloud native patterns which is all about cloud native from the application design perspective fantastic well great having you here by the way your microphone's a little distant maybe if you can move a little closer to it just fyi cause it help helps the theory better we don't want to hear everything you have to say ravi ravi lachman is evangelist with harness hi robbie hey mitch hey very excited to be here with the other panelists it's gonna be a great discussion um compared to my last uh recording i'm out of the witness protection program if you caught the last one my camera's working this time a similar job to uh to brendan um i'm the evangelist at harness that my background i've been a distributed systems engineer for a while so i i had lots of creative ways of destroying things they called me the air budget destroyer i've worked at ibm as his fair red hat prior and i was told i no longer belong production and so here i am talking to people about their uh their journeys well you're that guy that they say if it works in production it would have worked and test right that's is that you appreciate the prod [Laughter] well good good we've got good introductions i think we've got everybody in um and just by the way i didn't mention i'm ceo with accelerated strategies and devops and and cloud native traditional transformation cyber security is areas that we all focus on so this is uh near and dear to my heart as well well let's start out with a bit of a working definition like every term in our industry as soon as it sounds cool and it's popular then we over define it and co-opt it make it our own so maybe we can come come together on what we what we find is what um we have cornelia here that can help us with that too i know i know uh brandon tracy you have some thoughts on this too maybe you start us out we'll get to a place where we kind of think this is what it is you asking me or brandon i'm asking yes tracy jumped right in okay well i like to when people ask me what getups is i try to summarize it as as tightly as possible and i say gitops is operation by pull request that's what it is what it does um really well is create immutable or hermetic deployment so that you always know what you did yeah i think that's i think that's a pretty great definition because it's similar to how i think about it i think about it as you know it's it's infrastructure as code of course right it's defining that infrastructure as code it's using a pull request or a merge request as the change mechanism for anything that that we're going to change about that infrastructure and then it's using ci cd to automate those changes um and so yeah i i always think of those as those three things and and tracy's definition probably is even more succinct than that but uh yeah i agree i i'd love to chime in and add can you hear me a little bit better now that's much better thank you excellent excellent thank you um i'd love to chime in and extend those those are both fantastic definitions but i want to put a little bit of a fine point on it because tracy you said something about immutability and so when it comes to 100 we're putting things into git we're using git as a user interface mechanism as an audit mechanism all of those types of things pull requests policies we're applying policies in there then we've got automation for sure but that immutability part there's a part in git ops that's really important which is it's all about a reconciler so it says after we've done that automation out into the runtime environment how do we make sure that we know that what's running in the runtime environment still reflects what we have in the git repository that thing that was approved through a poll request or a merger request that we're in fact running that and that's where what we've done with get offs is we've capitalized on that pattern that kubernetes popularized which is this constantly converging system like you're constantly if something happens you converge back into that desired state and so get ops takes this idea of automation that we've always had and it kind of turns it on its head and says well it's not just automation and then we're done it's this assumption that we're never done and we have to do things in a reconciliation-based way so it's drift detection is something that is part of what we do there as well so it's a very get up get ops to me is a special way of doing that automation that brendan just talked about most of the sort of truth now you have a way of uh supply chain integrity if you will to use that term all the way to production to deployment clinton robbie jump in yeah i i think i have like the least stringent definition of get ops um uh what what i see get offs as i actually see it as like scm operation so some sort of version control or sem is the genesis for everything else behind it uh so it's maybe whatever level of effort you had with like a merge that should be that should facilitate all the way to production if it was seamless well all the infrastructure underneath it uh should be allowing for a seamless deployment leveraging infrastructures code or csd if you have to go through a code review and plead your case for two or three days well you know you might not be ready for true get offs but it's very scm in my opinion yeah exactly and i would i would totally agree with that and just putting a testing lens on this coming from a testing company um one of the biggest challenges that i see a lot of organizations struggle with where they're working with legacy applications or even trying to do modern software development for cloud native apps is that they struggle with the continuous testing part of that so whether they're doing either get ops or traditional devops or wherever they may fall in that journey just doing the continuous uh testing component of that and being able to do the automation is where a lot of organizations struggle so if you have those stop gaps and those approvals within that whole get out process it makes it an even bigger challenge if you don't understand how are we going to do the the right amount of test automation as well i'm not just talking about ui automation but um from the back end from micro services to not only your unit testing but api as well so that's one of the the biggest challenges that i see for a lot of organizations where that becomes that stop gap and prevents a lot of organizations from truly embracing um a really um popular get up get out flow yeah i want to just add to something that ravi said and maybe maybe disagree with you a little bit on this um not disagree entirely but what you said was if we think about the term git ops there's really two parts of it there's the get and there's the ops and you are focusing in your definition on the get part you're focusing on the source code control system and and all of that stuff and when we talk about pull requests but that's only one half of get offs and so when i mention something like drift detection i'm emphasizing the latter half of the get ops term which is the operational element so it's not just what we're doing in scm but it's everything that we do to ensure that what we have in the source code control system the system of record the single source of truth is in fact what's happening over here so there's a lot of work involved in making sure that you have that complete end-to-end um flow interesting there's some really good questions that are coming in on the chat conversation folks are having and i know tracy's responding uh when we say get ups are we talking about a specific kind of architecture does it have to be kubernetes does it have to be containers can it be used for virtually any software architecture that you can put into a an automated tool chain workflow that could be uh supported by a get yeah i mean i i think the answer really simply is it doesn't have to be a specific architecture i mean i think you know to cornelia's point you know that uh for weave works and the founders of the term it came out of this you know need to manage the complexities that kubernetes can bring but i think the principles behind git ops can apply to any type of infrastructure i've we've seen folks apply it to you know automating the way that they're deploying vms right as well as you know stuff that they're deploying onto kubernetes so i think that you know kind of focus um you know what robbie was saying that focus on the developer experience right the developer-centric experience of managing infrastructure and then the making that kind of you know infrastructure as code would be the old term but but making that real through what cornelia was talking about which is you know an automated way of ensuring that that is you know what actually happens um and you know any configuration drift or manual change that's going to get overwritten by what you know our getups getups methodology is going to employ means it can really span any architecture it's it's more of a more of a principle that can guide the way you you think about it yeah 100 and uh i i promise i'll meet myself and stop talking here in just a moment but i do want to take the opportunity to invite everybody in the audience and anybody who's listening to the video i love brandon what you just said it's principles and um where i want to invite everyone is that um under the cloud native computing foundation the cncf we recently formed a new working group and a new sandbox project around get ops and what we're doing in that group is we are agreeing upon what that set of principles are what you know what what that set of principles is and then working together to help and this is really the cncf's mission is to educate folks that cloud native doesn't mean you take your existing stuff from your data center and stick it into the cloud and therefore you're going to realize all these benefits there's this shift and that's kind of what i mean about a special way of doing the automation but the get ops working group and the cncf is the place that we are collectively deciding on what that set of principles are and educating the market on the benefits of those principles and how they're applied i think there's been a shift uh just kind of combining what cornelia and brandon said right like if you took a look at the textbook definition if you you know grab the manning book getups in action like it would be very there's a very stringent definition of what get ops is it's like you have to use declarative infrastructure uh the number one declarative infrastructure those people knows is kubernetes right but um as these particular principles that were very beneficial uh in get ops um it's kind of um proliferating saying hey there's not everybody's using kubernetes right on every application um there's definitely pros and cons and mostly you know i would say from it to have experience in operations experience like a lot of pros you can transfer into other systems it might water down the definition a little bit like anything in technology but the the goals are certainly feasible with other snacks so i'm going to comment on some questions that are coming up in the um in the chat here so we defined git ops let's define devops because that is the conversation right so let's think about what devops is devops started as kind of a it followed up from our ci world where developers had their own operational tasks that they needed to do and we wanted to start shifting left and bringing operations closer to development that created this the site reliability engineer it created a lot of changes in how we manage software and the team the culture so devops is never really a thing it was a culture and a process within devops we have continuous integration which is where we first started this journey and making it faster to check code out you know merge merge check out compile create what i like to call a release package that could be pushed farther across the the workflow which i like to define as continuous delivery these are all devops practices and get ops is part of that it's not instead of that git ops is really focused on continuous the continuous deployment solving the continuous deployment problem of the devops pipeline and we all i also want to bring up another point that gets really confusing get ops is a pull mechanism it's not a push but something had to push the ammo file into the the environment repository in order for git ops to do its job so within the devops pipeline you still have something that's pushing a deployment you may not be taking the actual container and calling your helm chart directly but instead what you need to do through that cicd pipeline is to start creating these auto automating the push for the the the pull request and starting to manage those yaml files so don't think of git ups as replacing devops i i think that's the wrong way to think about it i think get ups is really improving the continuous deployment step of continuous delivery which all falls under the family of devops a bunch of things you know we can explore there tracy one just to pick one of them i'm curious why is the idea that it's it's pull that i mean that's that's what kind of kicks off the whole process i know you talked about how things get to the point where you could do that poll but why is that an important concept to keep in mind it's the real core of what the the brilliance of git ups and the brilliance of you know what we've worked started some time ago think about in and i could be wrong in its history but i can remember at a kubecon sitting down with some of the weave works folks and talking about what they were doing think about when we first started pushing things to kubernetes we would create a container image we create a yaml file and we would use that yaml file to deploy it what we were doing at that point in time is creating containerizing our monolithic applications and we had come out of a phase where tools like chef and puppet were pretty critical but those tools really were managing the full stack and now we had a container that managed the stack for us because it was all insulated in that container so the brilliance of the get offs thought process is taking something we're already using habits we already have which is to get use get for all of what uh cornelia described as the auditing and the and the kind of the feedback loop and being able to keep track and then having a state operator and that's what the get ops operator does it sits there inside your cluster and checks to see what's in your environment repository and is it the correct state that you want to find and by doing so it's doing a it's pulling the information and it's pulling it on a regular basis as opposed to waiting for a an approval process to go and deploy something that is a push but what i'm suggesting here is that both are existing because at some point in time somebody has to decide to update the get the git repository with the new yaml definition which then which could be is really done in a in a a you know a human decides it or you push it through a cd pipeline you update that environment repository and then the get ops operator does its pull so we're doing a push pull in essence yeah i mean that is a fantastic point tracy that there's a little bit of both and um and when it comes to something like the ci process so the output of the ci process i'll simplify it and say the output of the ci process is a new container image that is something where we can say you know what we know regularly what the steps are um we don't have to worry too much about distributed systems and things like that because you know we're going to do a code commit and then it's going to do a series of steps and if something breaks we can you know see that and it but in the end we get the uh the container image but as you alluded to earlier tracy that container image now is going to get realized in a number of different places and so the whole notion of pull has so many advantages there's a security advantage there is a you know an advantage around eventual consistency but the one that i want to focus on here is that we're talking about distributed systems here so that container image that we just built through a push model is going to be deployed in a bunch of different places and those are highly distributed and those environments are constantly changing and we want each one of those environments to be responsible for their own um their their own state and that's a big part of where the poll comes from and by using a poll allows us all sorts of interesting deployment topologies that allows us to be at a sporadically connected edge where at the edge the pull mechanism is saying you know what this is part of my semantic whenever i'm at whenever i'm connected i can pull rather than the pusher saying oh well gosh they're not connected gosh they're not connected i'll have to retry so it's a distributed it's a key distributed systems pattern is what it is so one of the things i would like to just just for the my colleagues on the panel is just uh with your particular customer base are you seeing are they embracing more of get ups versus devops or are they kind of confused where are you seeing them in their in their particular journey it's an extension is get up as part of the devops philosophy approach to to creating software deploying software right i would say okay tracy devops didn't i hate to say it this way but devops doesn't do anything git ops does do something get ups has an architecture to it it has a very precise architecture to it devops is more of a philosophy and a way of thinking about this the entire app alm process whether you do it via a jenkins model or a git lab model it is it is a a culture and a goal yeah similar similar feedback about tracy said like you know they're not mutually exclusive or like hey by using get ops doesn't mean you're having devops it's like this you know the tree fall of the woods type of argument right and for what i see in our customer base it depends how their application stack and their kind of shores up um for let's say newer applications that fit the deployment model of let's say more stateless workloads that fit again i was modeling folks are moving towards get ops for applications that are extremely persistent and have a lot of state and there's a lot of moving parts just uh you know there's a lot of transient data or transactions going on um it might be a little bit harder because you can't restart from scratch when you deploy something to you so it depends um each patient is different with the app stack yeah i think you know like i said in in my definition which interestingly enough didn't include pull because you know i do think we typically think of get ops as this pulling mechanism because that's how most folks that are implementing it in you know to conor's point of distributed system are are looking at it but i i do think that it has an opportunity for some folks who you know are working with systems that aren't like that right embedded systems um you know maybe more traditional or or less traditional deployments right mainframe um there there is a concept there and i think that get ops you know has enough of a principle to it um in addition to you know the kind of typical architecture right that tracy was mentioning that i think it can fit a you know more folks be a bigger tent than just than just that um you know those distributed systems i think it in some ways is this realization of devops uh in a way that you know it i don't think it replaces it but i think it it shows an evolution to the market where you know as operators become more developer centric we get a principle that as a you know we were all kind of agreeing to is a more developer-centric experience for the way of doing operations and i think it's you know critical to say that means we're not going to have these like silos of somebody going in and fiddling with the architecture and and messing with you know the way production is running uh we're going to ha know that in some way it's immutable and the typical way that folks do that is you know yes it comes out of kubernetes and there's lots of folks that are doing it with you know a kubernetes agent um like flocks or similar that is going in and pulling and you know not letting you um in that way but i think that's not necessarily possible for every use case but i do think there is at least principles of git ops that are applicable to everyone's use case if if that's the way they want to go i'd like to offer another perspective um clinton you asked the question around customers and so the not necessarily from a weaveworks customer's perspective but um i mentioned the devops enterprise summit which again is gene kim's community and conference there and um they've been you know the conferences in its sixth year i think so it's been doing devops related things and to tracy's point in several of your point is that devops is kind of a philosophy and a set of practices that have been applied to achieve this this philosophy of devops in that conference when we take a look at the sets of practices more concrete practices and tools that people have historically talked about in that conference for the last five years which is about how long i've been involved in it they have tended to be more on the closer to the dev side of the devops picture that's where we have a lot of maturity around ci systems and things like that even from a practices perspective we've gotten really good at breaking down our teams into two pizza teams etc etc one of the things that one of my co-programming committee folks jason cox who is at disney has been saying for years i want to see more ops at the devops enterprise summit and i feel like what we're doing with git ops is we are i think we're lagging a little bit on the whole cloud native journey relative to the developers we know all those patterns and we know how to do those things but now we're starting to invent what are the sets of practices that are going to practices and tools that are going to help us as we push closer and closer to the right-hand side to the ops that to me is how i view git ops is it's starting to deliver on the ops side of devops more than we have in the pet in the past james is asking a good question i think many good questions and conversation in the chat here just asking so help help us understand a little bit more about what is it automating the developer what is it automating for operations or is it really kind of the entire process of that whole whole process all the way through so i try to simplify it in a tweet because that's about the size of those boxes i said james get ups mainly automates the deployment aspect i like to say it's a continuous deployment um solution for your your pipeline you take your deployment yaml file you check it into your a specific repository and then the operator living in the cluster that's associated is that's pointing to that repository pulls it and and deploys your yaml file which has the container shaw in it so in it so it knows which repository to pull the either the term repository is used too many times here but you have a environment repository and you have a container registry so it's gonna based on the um what's in the yaml file it's gonna go pull that version of the container image out to um the cluster that it's running in that is in essence the tightest the tightest way i can answer that in a in in that small of a chat box yeah i mean i think i think you're right tracy and i think it's again the same point the canary was making about you know hey we're we're looking more at get ops is letting us look more at that right hand side of the equation for devops it's the same is true for the right-hand side of the equation for ci cd right because cd is like something that we you know still have trouble defining and coming to uh you know a realization on and and like like a central industry understanding of what does that mean what does the continuous part mean what does the level of delivery part mean and so i think it it also helps address that right hand side to say hey look we're going to define the entirety of the desired state of the application that's not a great word let's say application right right the entirety of our what we're deploying right it's the infrastructure it's the services it's the the ingress and egress it's it's i'm saying application but you know we need a new word for that that's starting to say that's what we need we're inventing all these new words in the industry we need a new word for system as a whole observability would be a new term right yeah so yeah and then and then going into observability right like so that we can really look at you know what is the actual state of what's running in production right i'm sure clinton could talk a lot about you know people test before and then they test in production whether they like it or not right so what is that um actual state and doesn't match our desired state and if there's a difference like why right like why are things happening differently we want to really be able to observe that because in these large distributive systems you know you can't just as a human being necessarily wrap your mind around the entirety of the system as a whole and you need some other way of you know reasoning about it and and allowing your your assumptions to be challenged and your assumptions to be respected by the system as a whole that's really good point i mean we talk about managing complexity everything is getting more bigger and more complex for us to be able to keep it in our heads alone it's nearly impossible these days i think that's a solid point you know what i'd like to turn the conversation to a little bit a different direction before i do i just want to let everybody know that devops unbound if you're enjoying this kind of a forum roundtable style just discussion uh we're actually gonna have a couple sessions at the tricentus virtual summit conference that's coming up it's on april 13th 14th and 15th i put a link in the chat i'll paste it in there again if you want to find out more about how to attend so we would appreciate seeing you there and i'm sure the trisentis folks would as well uh where i'd like to take the conversation a little bit a little bit different direction is is git ops for everything are there places where get ups just doesn't make sense it's not it's not a workable or reasonable approach to take or is it more of a swiss army knife of in these cases bring out your get ops approach to to doing this anybody want to start i can take it it depends on how stringent of a definition you're you're applying to get up so definitely seems like there's a spectrum like on the call right like hey there's a less stringent and stringent definition it's all all how your infrastructure depending on how let's say reconcilable it is or also um how declarative your infrastructure is right like um kind of the kind of the bridge this might be a little bit more like a 30 second answer if you take a look at kubernetes right like kind of the defacto platform for restriction definition at get ops it's taking two sets of people and pushing their skill sets together as a developer i now have operational tasks i have to worry about as an operational person i now have development-centric tasks that i have to worry about and for infrastructure that's not like that it might be a little bit difficult um to actually shoehorn your infrastructure into that model again um being able to a if source code is the source of truth and it kicks off everything and everything is infrastructure's code it's very development-centric task uh to to reconcile that right like i i can reconcile things by running get diff um does your typical infrastructure engineer do that maybe maybe not so it's definitely a spectrum i'd like to chime in on that i first want to go back up because cornelia posted something i think we should point out she's put cd plus co which is really adorable and i love that because what we have just we have struggled with in overall within it just when i say we i'm talking about the broader it community is the ability to have a repeatable process all the way from dev through prod there's always been a wall and we've never really been able to break it down maybe the wall is smaller it's not quite as tall as maybe four feet not eight feet but there is still a wall and what i have always seen through my career is that even if we have a ci cd practice that goes all the way to test operation teams tend to be skeptical about the scripts that the test and development teams have used to do deployments they have ownership issues like they should because they're responsible for those environments at the higher end of the the cd pipeline so get ops does have the potential to marry you know cd plus co because it provides um so let's just take it in a general a kind of technical way of looking at it developers have their branch where they're storing their gamma files testing have their branch where they're stored in their yaml files and production can have their branch where they're storing their ammo files so if production is allowed to use the same process and as comfortable with the same process as dev and test we are coming closer to continuous operations and that is again part of the brilliance of of that get ops model now that being said i'll say where i think it's going to start running into uh some some roadblocks is as we expand these kubernetes environments as we expand into microservices and we have lots of microservices running and we have lots of yaml files and we are going it from a scaling perspective on the operation side and being able to run as many clusters and pushed pulled from many repositories as possible it's easy but there is a human factor in managing the the number of gamma files the other thing that i see that that can be a roadblock and i'm hoping that the sig starts addressing it is the different formats for this the operators you know you have one for rancher you have one for flux you have one for argo and with us like deploy hub we'd love to be able to generate those files and push them out to the get ops operator but which one do we format to so i'm hoping there's a standard for what that looks like because if there is a standard then development teams can use argo if they choose to and production teams can use rancher if that's what they're they're comfortable with and those are the kinds of issues i think that and i wouldn't call them issues i'd call them growing pains for the get ops movement i think that's what we'll see in the future yep i mean it's still early days there's plenty of growing pains for sure there's lots of things that we haven't solved and every time i see one of those blog posts that says oh here's the problem with get ups i'm like okay you just wrote my backlog yeah yeah yeah it's early days yes you're right those are legitimate concerns those are things that we need to solve so um i i also want to there's something interesting i want to tie i think it was you brendan and you tracy who you can see right where you are on the screen there who uh i want to tie a couple of things together that you said there one was this notion of i test and then like it or not you're still testing in production and then this ability this this lack of trust or this concern between the operations folks who are ultimately responsible for the resilience and the folks who had who just did the test and said i fully tested it it's cool you're you can use this now it's no problem is that one of the patterns and again it's very reconciliation based that allows us to draw those things together is this notion of progressive delivery so now we've got this eventually consistent thing on the operation side that is saying all right you're delivering to me that next version of your application that you want to run i want to do that delivery progressively and depending on how the progressive delivery goes like a canary deployment or something like that i want to interface all the way back to the get repository that has that declarative configuration so i need to close that loop and that's why i'm always so insistent that git ops has to go all the way to the right and then has to circle all the way back into the git repository because that's what it's all about make sure that what you think you have is what you actually want you know what you want is actually what you have that's that's the whole thing there's a really good comment in um in the chat by michael he's asking about going from project to project you know how do you transfer that knowledge into your point cornelia if it's all there if it's all in the repository using that word again it is that that source of knowledge is there you can go back and reuse it and leverage it to other teams and maybe more part of using it in one you grew that yeah yeah i think that's a really great point i mean that's one of the biggest things that we we can um end up spending a lot of time focusing on that but it's absolutely true that while i tend to emphasize the ops part of get offs the get part is so important because it's the collaborative way that we do things and it's visibility and auditability and all of that stuff and and sharing and learning from what other people do it's transparency i mean transparency is a good thing and that's a big part of what git does for us in the whole get ops approach is it provides that transparency to michael's question go ahead yeah just another like just extending that to michael's question like i've probably been on a dozen development teams in my career and every single time we deploy differently like i can take java development patterns team to team job to job but every one of the places i worked um we deployed differently so like one of the big benefits of code codification is that the code doesn't have an opinion right like it will execute every single time um as it's told now the people who authored the code might have an opinion that's another story but it's it's it does have that repeatability which is really crucial right like um just one i forget who uses the cam's acronym so culture automation measurement sharing um if you take a look at one of the most recent reports like we're all bad at sharing like that if you look at the elite performers to the lowest rung like the gap is really small because everybody's really bad at sharing and so as a software engineer sure i should be able to interpret what the code is supposed to do so yeah i think that's a big benefit of leveraging again ups model yeah i agree i think it goes directly to michael's point because he's actually bringing up a little bit of my uh i don't know i don't know what the right term maybe ptsd i used to work for a government contractor yeah um before i came to work for git lab and we had that exact problem it was you know we were a subcontractor with subcontractors and it was an application system again the big where we're looking for that was made up of 13 different very distinct components um and and i was brought in because there wasn't really a plan around devops or really anything from getting from dev to ops and the environments were crazy different right the developers were on one environment then you tried to virtualize it to test it then it goes and runs on bare metal in production for the customer and i was handed day one a a word document that was 11 pages long that was how you deploy the software with like what jar files you need to copy where in what order because somehow it mattered right and like that is obviously not going to work right and so that's why going back to what cornelius said is like that's what you know why using the term get um is so critical here because that's what takes that like cave-like nature of operations right this person that's working in isolation understands it we had a senior developer on that project he was the one that always had to set up people's new environments when they got a new laptop right like think how crazy that is and uh and and writing it down in a way that's repeatable um just like we would with code right and taking all those best practices from software to development and bringing them over into the deployment on op side i think 11 pages that's short man i'm not going to say what agency i worked for inside the beltway our change document was 153 pages i remember that very vividly and it was like i i wish it was in source code somewhere um yeah time to change now probably down to 100 pages at that agency but it was it was a bit government document i like how you said 153 you didn't say 150 that is indelible in your brain number didn't how does the testing community i know that's kind of a bigger community now than it kind of once was since test is such an integral process of devops how does the testing community view git ops and maybe are there some things that help folks that do a lot of the automated testing and manage that architecture that strategy that they can get their head around github so it would be helpful to them yeah so what i see in the just in organizations in general from startups to large enterprise organizations is that they're really just struggling just to get their arms around just understanding just devops in general right so most organizations they're very early and everyone is starting at different areas and a lot of the companies we work with they have separate qa teams that might be deployed and working with different um uh different development teams but the way that they do automation and get ops and just devops in general is just so new because a lot of the customers that i talk to depending on the types of applications that they have to manage you know uh robbie and brendan talked about you know just from a government perspective all the different components and then trying to wrap their head around how can we modernize or go through these you know the you know of course the latest buzzword over the last five years is digital transformation right so what we're seeing from a testing perspective is that a lot of these organizations are still struggling to understand how do we improve quality in this entire process because they can understand that okay this is a um a new paradigm or a technique but they still haven't grasped the actual execution side how do we properly implement uh testing and test automation to ensure that we have proper quality how do we ensure that we're um we're testing all the different components and the ways that they need to be the way they need to be tested before they're released to production and if we're testing production how do we do that so what i'm seeing is that it just it kind of runs the gamut in terms of how test organizations or just organizations in general are just struggling with quality and the best way to implement that and i'll be curious just my colleagues on the panel just to understand how their customers are dealing with that particular slice um within the whole get ops process and it's still part of the the ci um cd component but does that become you know for both of the ones that i talked to that's pretty much the main bottleneck just because of trying to understand the whole paradigm so i i think we're starting to see a shift um and maybe this could be a discussion for another panel and the cd pipeline is um is morphing it really is uh we're gonna i think five years from now we'll be talking more about events events and processing then we are talking about a imperative pipeline process which means that an event for testing could be called at any point in the process and i also think that as we push the decoupled you know monolith into microservices we're going to recognize that not every microservice is equal and requires the same amount of testing or the same pipeline and events will will solve some of those problems for us because we'll be able to declare what our pipeline needs based on the risk value or the consumption of a particular microservice and who it impacts so i think that we'll be seeing a change in how testing is called and at what states and how based on an event model you know and you think about events you think about tools like kept in you think about the puppet nebula you think about tecton even though it's not really events it's it's driven it has an internal pipeline to kubernetes that we could literally the operator could kick off a pipeline to go and test something and do a smoke test in production so i feel like you know we've always seen our pipeline is very very much like a pipeline we're turning it into a starburst where any any of these processes can be it can occur at any point um in what what we were acting upon so i think we'll be we'll be thinking about it differently in the future so don't think of it as a linear process necessarily this doesn't have to be it's definitely not i mean when you're reconciling you don't know where the initial trigger is going to come from do i have to do something because somebody did a cube cuddle which is the equivalent of an ssh into your environment or do i have to do something because the developer just pushed another commit and it generated a new container image you don't know where the initial trigger of something is going to come from and you have to build your system so that you can respond to the triggers coming from anywhere that's one the canary event could kick off something that's right that's right it's truly interesting in production yeah to clinton's point i think um if if let's say pretend you're a new engineer on a new project right like if deploying is one of the hardest things you could do the second hardest thing you could do is figure out code coverage or figure out test coverage i i even for projects i've worked on for a year i i still can't have a definitive answer did we cover everything did we meet the quality expectation not like the development manager like how bad is that right like that's not a very good answer but like anything it's evolving right like we're getting better you know the more let's say just paying homage back to get up so the more we can codify things the more we can take a look at over repeatable events the tracing point like we're bridging that gap so that big part of the learning curve when you go team to team or um organization organization it's lowering that bar so there's more common industry practices as a shiny penny that sounds the industry is headed that way pretty quickly we're just reading the chat i could make up another buzz phrases there's a lot of things a lot microservices is the last mile of agile um so we're about 10 minutes away i need just a few minutes to to wrap up at the end uh i think let's go give each one of you one more pass at what's next for get ops what's next for where organizations uh can take it and benefit from it uh cornelia would you start us out yeah so i think that um i i think that what we've done in the past up until now with git ops is we're still in the infancy and i think we've been experimenting with these patterns like the pull model that tracy highlighted and so on i think that we started to touch upon it when we talked about again tracy when you talked about these imperative pipelines i think what we're going to start to see is we're going to start to see us embracing this model of a non-imperative kind of can reconciliation reconciliation-based way of programming our systems from delivery all the way out through operations with tying back into the continuous integration part so some of the things that we are going to define a set of new models so there's going to be the notion of something like a git ops pipeline we have ci pipelines we have cd pipelines but what does a get ops pipeline look like and so we're going to start to make these things abstractions that developers and when i say developers i mean any kind of a technology technologist it could be somebody who's writing code to instrument their their ops side or it could be somebody who's writing code you know actually apple application code but any any technologist is going to have a new set of primitives to define these kinds of pipelines and take that control through those abstractions who's next go forward and i would say yeah i would say that the because from uh from my perspective the the future really comes down to really educating um uh the the the expanded customer base um for all industries because right now i believe there's just so many different implementations so many views in terms of i think we have a good good idea in the standard standard definition of what get ops is but it always comes down to regardless of where you are or what tools that you have it really comes down to execution so how can we um help organizations understand what is the best way to get started with get ops what is the proper practice how do you implement um how do you really push forth transparency and this is when i was with gitlab that was you know that's the mantra right transparency and that has to be something that in order for organizations to really you know put their arms around get ops and really move forward they really have to understand these are the baby steps we need to take this is how we're going to progress so i think it's really going to become it's going to come down to education and how we can make it so that it's much more digestible and easier for a lot of these new dev organizations to really understand how to properly implement get ops great brendan how about you jump in sure yeah no i think if i'm thinking about the future um you know i think we see all the time and we've seen it for years um you know i'm old enough to remember software development before the term devops even existed right um not to date myself entirely but you know it's true and you know i think over time we see tools and and methodologies come along that you know promise like faster deployment right seamless management i think the reason get ops maybe feels a little different and we're seeing more interest around it or at least you know relative to other tools and and methodologies going around is that that focus on that you know i said developer centric but i use developer the same way connelly did right that technologist centric experience and bringing that like infrastructure that real ops management into the same version control system as where we're doing our application development right really enabling teams to share information transparency really enabling teams to collaborate in this like central platform while also benefiting from you know built-in features of get well also you know allowing observability data to come in and impact the same things right that kind of convergence um into uh a methodology and i think a platform we're seeing in an industry in in consolidation uh through many platforms of you know a way where everyone can do the planning the source code management the delivery and really actually realize the you know goal of putting the words dev and developer and operations together um and actually bringing people together into the same same platform same building same sheet of paper however you want to put it playing playing the same music together i think that's what we're going to continue to see well um brendan i'm betting on that because what you just described is what we're doing with artilles into play hub the farther we go down this road uh the more devops scale is going to be a discussion we're going to go a lot faster microservices are going to move faster and as somebody pointed out not everything is a microservice that you deploy you're going to have poly databases there's a lot of moving pieces and parts and then there's the infrastructure that moves as well as along with all of that so having a central location to find that information and unfortunately you know while git has the audit information in there you have to dig through it to find it so the more we can abstract out and um and display in proper reporting will make it easier for everybody instead of having to go you know dig through some get to find that data so visibility into what's occurring configuration management will be again a conversation that we continue to have and configuration management from what changed from the environment all the way up to the application in the database and if we're going to move fast we have to have that data i guess i guess i'll go last i have the opportunity to hear what everybody said so it's always like going last this is my little sneaky trick i do so i think the the workloads are increasing so like i think get ops adoption looking to increase because the workloads are catching up so i'll give you a really concrete example i i call it the kubernetes dark days i was migrating distributed java workloads onto kubernetes in 2015 and 2016. it was like pulling teeth right um the the workloads that are able to run on a declarative system are increasing so in the drama days i actually had to use a weworks product called weavenet to facilitate the cluster management in a java application that we ran not today there's operators that do that right so the entire ecosystem um an application infrastructure and infrastructure is moving towards a better housing in kubernetes or another declarative platform so as that goes on uh the get-offs mantra is going on and investment all all across the board's going on so i see a very positive momentum in the ecosystem and for the good office movement at the same time well with that boy perfectly timed thank for thank you for landing the plane three-point landing there robbie so you know this has been a fascinating conversation and i think we spawned about four or five different panel conversations we can take i think we did too so did the people in the chat absolutely you know i really want to thank all the folks in the chat wow talk about some amazing parallelism if you will in conversations here from james and bob and michael and and arvind and a whole bunch of folks that are contributing as well as our panelists today so let me take over a few housekeeping items here uh we want to announce our gift card winner uh winners if you will uh the three the four winners are janelle b bruno c jason e and rory oh the good folks at mediops will be getting in hope of you to get those gift cards to you i do want to remind you too again about our trisentis virtual summit that's coming up devops unbound we'll have a couple of episodes that we're actually doing as part of the conference the new experience for us we're excited to do that that's april 13th 14th and 15th i also want to give a shout out to my partner and co-host alan schimel who is usually part of our conversations uh on devops inbound he's taking some well-deserved um time off for him and his wife so i know they're having a good time hopefully they're not watching us they need to be like out there having a good time they are hey hi allen we're gonna turn off here in a minute so it's been a great pleasure yeah i'd love to thank all of my wonderful panelists that have just been fantastic here tracy reagan ceo with deploy hub uh clinton's sprob who is director of product marketing with trisentis cornelia davis cto weaveworks uh great plug for for you cornelia by ravi at the end there brendan o'leary senior developer analyst with get lab and ravi lachman evangelist with harness it's mitch ashley ceo with accelerated strategies has been my pleasure being your host and moderator for the conversation today it's been an hour it's busy times and you spent an hour with us we're extremely honored we hope you've used your time well have a great rest of your day see you thank you stay safe

Channel: DevOpsTV

Views: 664

Rating: 5 out of 5

Keywords: devops.com, devops, devsecops, continuous delivery, microservices, containers, devopstv, gitops, tricentis

Id: WpEbjVEsSMw

Length: 60min 28sec (3628 seconds)

Published: Wed Feb 24 2021