Ortelius Open Source Ortelius Microservice Visionaries 2021, 19 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Ortelius and GitOps - the Road Ahead panel discussion

Description

Ortelius Microservice Visionaries 2021- In this panel we chat with Steve Taylor, Sergio Canales, Christopher Hicks, and Brad McCoy on the topic of GitOps, what it is and a look forward to the Ortelius GitOps Integration Project.

A

Hey, thank you all for attending the ortillius microservice visionaries event. This event is to celebrate all of our contributors and start conversations in all areas of pipeline management, devops continuous delivery, especially around microservices, which is our topic today.

A

I want to introduce our panel to panelists. Today we are going to cover get ops and why get ops and where get ops is going and how ortilius will be fitting into get ups in the future. So I am going to leave it to our distinguished panelists to introduce themselves. We have steve taylor, sergio canales, christopher hicks and brad mccoy all coming from different backgrounds from development, sres and solutions, architects, and I'm going to let them really talk about their own background, so I'll pass it off to steve. First.

B

Hey everybody, uh steve taylor: I am the ceo and cto of deploy hub. One of the core contributors of the r2ds source code base background is mostly configuration management, build management uh forever, so pretty much seen it all and tried different things to so I have a good feel for what works and what doesn't work. These days.

A

Sergio hello.

C

There I'm sergio canales, I'm a senior consultant. I work at red hat. um I day-to-day live delivery on customers. We work mainly with a container platform, so cloudforce in some way. So usually I I I work with a lot of immigration and implementation. So I'm happy here to share experience.

A

Thank you and mr mccoy.

D

Hi everyone, I'm brad mccoy, I'm the cloud engineering leader at muller, I'm working in australia at the moment. My background is software engineering and then I transitioned to devops a few years ago, yeah big into open source cloud native and you're happy to be here.

A

Thank you and christopher.

E

Howdy folks, I'm christopher hicks, I am a site, reliability, engineer at mcdonald's tech labs. I have been doing site reliability, engineering for uber and yahoo, and a variety of interesting folks and I've spent a good bit of time, doing, release engineering monitoring and automating all the things. So that's.

A

Me so I just want to give a shout out to all of you. um Everybody on this call has made some real contributions to the ortillius project. uh Steve taylor is our fearless leader when it comes to the architecture.

A

Team christopher has uh supported us from the very beginning he's one of our first uh people who actually started showing up to meetings sergio just uh jumped right in when he saw what we were up to and is also responsible for a lot of the artwork you see and brad mccoy came to us from australia reached out and said hey. We would like to do some work too. If we can figure out the time zones and they he is leading the team that is really starting to look at how artilleus will work with get ops.

A

So, let's just get started and talk about um for. I want each of you we'll go around um we'll start with christopher and just tell us in your mind what is get ops. Maybe you tell us what it is and what it isn't.

E

To me, get ops is the evolution of heroku. You know we want to give developers an experience where they don't need to be exposed to how the infrastructure is working, everybody's comfortable with git.

E

We can define all of our configuration history and get and have one source of truth that you know is shared by the outside and developers, and so you know, I think, get ops provides a very good developer experience if you've got the team to be able to automate the vacuum.

A

Brad you want to add to that.

D

Yeah, I think it's really a paradigm, it's not a specific tour technology.

D

It really gives drives business value from linking devs to operations even more so um it's defined at the moment there's four different principles that define it so they're sort of working on a fifth one at the moment, but your entire system should be um described declaratively, whether that's yaml files- um and you know the second principle being the desired state- is version, so it doesn't actually have to be get you can you can have container registries, you can have you know configuration management tools, um the second, the third principle is approved, changes can be automatically applied to the system and then the fourth one is the the software agents, ensure creativeness and alert.

D

So it's really where continuous delivery is beside continuous operation. So it really all that stuff we're talking about how you know we're shifting everything left we're shifting security left. You know it really enables us to do that and work together out of silos in the organization.

A

Do you have anything to add from a red hat perspective,.

C

um For a perspective is something needed is some like uh by by default, something like uh every company should have, because uh it it lets.

C

You get uh a uh get um advantage about new technologies, so the declarative way of what is is putting in place with githubs is the more reliable, reliable way to to use container platforms on in the every cloud scenario is like, like chick says: how, in a single single single place, where all the true of your application is, is a way to enable hybrid cloud and having a smooth way to do an a consistent way to deploy to every environment. So it's like really fundamental for today, capabilities.

A

Yeah, I think reliability and repeatability is core to this um steve. So why don't you give us a little bit of the architecture? What is the architecture of get ops looks like.

B

I'd like to um kind of say what uh get ups is not um just to put some context around it. Get ops is not an orchestration tool like a jenkins.

B

It is really focused on a small part of the whole cicd pipeline process, um and people are trying to put other bolt-on other things uh to it, but I it could be difficult in the long run. um One of the core pieces of git ops is the concept of an operator get ops operator like uh fluxd.

B

um Argo has their, they just introduced, one called uh application sets um and then like rancher, has their fleet, uh but basically you can think of it. As an agent like we used to have for puppet or chef um for containers now for clusters, so that's kind of what you can start. Thinking of it is, and it's you know it's. The concept of state management is the way I like to think about it. It's the easiest way to wrap your head around. It is by looking at what state do.

B

I want my cluster to look like.

A

Yeah state management. I think it's a really good way to describe it, because there are, even though we are speaking about get ups in terms of microservices and really defining the state of a cluster and having your uh your yaml file, managed in a git repository.

A

There are discussions about using this same kind of technology to do a lot of things and I'm looking forward to seeing kind of a cd operator right where you have a declared state for your cd pipeline, and it manages it that way so getting back to just get offs and really how we're using it today christopher. Why don't you tell us from an sre perspective? How is how git ops is perceived uh good, bad, indifferent.

E

I mean I feel, like the perception is really positive. When I searched for news about uh get ops, I really didn't find very many people that were posting negative things about it.

E

The negative stuff that I saw was from the classic I.t community that you know is still struggling to adopt a lot of these internet uh technologies, but from an sre perspective, you know we're making things more reliable because we have our entire source of truth and get, and so, if somebody messes something up, we can just say: okay, we're going to roll back to a particular point in the get history which we know you know is is good and then you know we can try and figure out whatever the problem was from there, and so you know having that.

E

You know same comfort that you can always fall back to something that previously worked and get. You know that power of let's go, try new things and see what works, I think, is a great way for people to stay, agile and keep moving. You know, and it really takes a lot of the different ideas that we've had. You know continuous integration and continuous delivery and it buries all of that behind something that the developers are going to have to deal with anyway. You know almost everybody's comfortable with git, it's you know become the lingua franca.

E

Even if we don't like some aspects of how it works, you know everybody has to figure out how it works and get used to it, and so once you're in that paradigm, you know oh great, we can bolt on the ability for you to deploy to a staging environment without you having to understand any of what's going on in the background, and you know that reduces the number of tech support issues that are going to come into the sre team for hey.

E

Please can you do this for me, so you know we definitely like to see more of this self-service architecture out there, and you know, I think it helps us make things more reliable. So you know within the tech sre community, I feel like it's got a very positive.

E

You know perception.

A

Yeah that you know creating that, I like to call it a hermetic kind of deployment and moving away from those imperative scripts into something. More declarative really does create that self-service environment, and when I hear people talk about it, I think that you're spot on. That's that's! That's! What's driving the adoption of it so um brad in terms of specific benefits that gitops adds to the deployment process, um how is it different from these traditional imperative release? Approaches why? Why does that?

A

You know what is the difference between this imperative kind of method that we're used to and moving to that declarative approach? That christopher just talked about.

D

Yeah, but for me once again, it's a single source of truth and it allows you to have immutable infrastructure as well. So you know in the past how many times have we seen the disconnect between you know development and operations? If we have the single source of truth, then you know it makes things like rolling back easier.

D

um We we, it makes it easy to audit things as well, and we can really focus on. You know deploying a lot faster. So if we look at some of the metrics that we see in deployments these days, like you know, deployment frequency lead time for change time. To restore change, fail right, get ops really enables us to really deploy on demand and be confident that we can release faster.

D

So I I think it's all those sort of key metrics, it's bringing down the failure rate and it's really maturing the pipeline as opposed to the imperative way.

A

The pipeline, you know uh I talk sometimes when I you know, if I'm on any of these discussion uh topics around get ops. I talk a lot about the front end of get ops because, even though we do have a process that is automated once it's, the yaml file has been checked into the git repository. It takes care of everything from the back end, but now we have to start thinking about how to get it there in our standard cd pipeline. We don't like to stop so steve.

A

How does git ops fit into the ci cd pipeline, or does it.

B

Fit I I personally think the jury's out on that one, because um if you have some, you know financial institutions that have had uh the waterfall pipeline and they want their gated pieces.

B

Get ops could actually fit into that world. Quite well, because you can do your pull request. Have somebody review it view it have a bunch of approvers on it and then once it's ready, you can then say go. um But if you're looking at a smaller company uh that doesn't have that type of uh pipeline and approval process- and you want to just go from point a to production, you know it. You have to do a few more steps around the pull request, process uh and automating.

B

Something like that out of a like a jenkins pipeline or a techton pipeline uh can be a little tricky um so because you're having to deal with git and make your pull requests and those pieces automated um it's doable. But it's just a different viewpoint that you have to to think about when you're working with it.

A

Yeah, when I think about that different viewpoint, I think about the the potential number of yaml files that we would have to be managing through the pipeline um christopher in a microservices world. Does this because these microservices are independently deployed through the pipeline?

A

Does that mean that, in a new in this kind of new git ops, world we'll have lots of yaml files to manage within git.

E

um There are different ways that you can deal with the explosion of configuration files. um You know having some sort of you know, templating system and auto generation, I think, can help reduce the what the humans are exposed to in.

E

In terms of you know, you're only having to deal with a relatively small amount of configuration, even if it's generating tons of yaml files behind the scenes, but having all of it in git, including all of those generated files, means that it's very easy for you to go back and look at the history of a service and trace. You know when when changes were made and having it in that process, post-processed form you know, is handy to have it be available.

E

It's not something that hopefully, you've got to manage on a day-to-day basis, and you know dealing with the microservice management problem. You know get ops, isn't the elixir that's going to necessarily solve that. So if you've got that problem other places- and you know because of the way your organization is working, you know this might give you more time to solve it, because your developers are not working on other things.

E

You know they have a nicer time, but you know one of the great things about all this being in git is to get scales really well. So even if you end up with you know thousands of files uh that you've gotta deal with you know, that's not gonna blow get up, it's gonna just keep chunking along and the tools that you know are built on top of this are you know, similarly pretty scalable, so um you know you're not going to break anything. It's except your brain, maybe, but hopefully not even that.

B

Yeah, that's one thing that, when they develop git that they really figured out quite elegantly was how to track uh differences and how to report on them, and that was one of the. I think one of the the nice things people like about git, even though other things can be a major pain.

A

So sergio you work with a lot of different customers. Can you tell us a little bit about some of the use cases you've seen or some of the different configurations you've seen across customers.

C

Sure, well, this is like telling about history, because kidops is well like everything start from a space, a gap that we are not feeling some require. Some usual problems that you're having in your customers. So at the beginning, when we just doing like get cicd at some point, you start seeing that in the last mile about the deployment uh it was that it wasn't the same that you're being working on on the development side.

C

So I think when git starts like spreading to to to more areas to more places, um customers and, of course, with consultants. Like me, uh I start to creating these this kind of uh git ups. uh Before it was kid ups, um I think at the beginning.

C

um At the beginning, I think the different configurations of what happened in the last years that you do you have some faithful trying to working with a single self of true or trying to have everything uh from from ripples, usually like, if you're working with with jenkins or other tools. At some point you you get into some some people feed pitfalls, because the pattern is not, it wasn't really clear. So um I think right versus, like, if I compare a few years ago, I think today is more clear.

C

The way you implement git githubs, based on the on the tooling, based off some experience. So it's it's a lot more easier. So for day, for for today, like and red hat, we are using, argo cd uh is make is working like by the fall. uh So I think we are. We are um like grooming very well. What is giving you dogs on one? What is the the best way to implement it? uh Even gdp has been a a huge evolving in just just a few a few months.

C

So so I think uh the different configuration is like uh was hard to to have a single source through a few years ago because of the paradigms, but today having agile how I am cic having everything else code, I think we are in better shape uh implementing githubs itself in in companies and right now, for for what I see into the future, I think uh is going to be uh more like than um I don't know.

C

It is going to be like pretty much a service and a structure more well clear to implement, and how I say is for me is is the best, because we have like urinaries that want the the space in the market just because they work in a in a declarative way and we were using imperative toolings in a declarative platform. So today we are seeing more more more uh coherency uh between the tooling around the qrs.

A

And do you see a difference between um you probably work mainly with large companies, but is there a difference between how small and large companies might implement get ops.

E

A

Maybe for larger companies.

C

I'm super happy because I have both. I I've been working on a in a.

A

C

Companies and big companies so well. This is similar when, when, when agility starts to to be famous like uh every every everyone say that it is only for for small companies startups, maybe some unicorns or people with better extreme areas that are working. So it's like similar, because it's a new thing and usually when you are working in a small company, uh sometimes they are don't having something working that well and taking the decision you need.

C

So you don't need to to speak with so much people, and- and at that point too, you can it's more easy to start again than than changing everything or improving whatever they already have so yeah. I think in small companies you have that that freedom- and I think so I I like when I'm in in a small team, because I think I I feel- and I do it for saying some way I like to put like more crazy ideas on the on the table.

C

uh On the other side, when you're in a big company, you're you're you you need to have you need to take care about your where what are you going to say? So I think that it's a um it's I think in every level like when we talk about innovation and improvement, is about doing different, different things and and and trying and failing so uh so in big companies. You can, you can do it, but uh usually uh works in.

C

um You need to find someone that is going to take the risk, like usually people expect that someone already do it. So you are going to you need to find the bravest people in that big company. uh Do this this! uh This love this. This kind of weird thing uh put it in some way, a a true production and then with a lot of trouble, more more trouble about the the size of the company and the approvals and on another thing at the end, you're going to to get this like.

C

Okay, this is possible, it's not a crazy thing, and it's funny because you you, you can see it in other companies and other places and it's there, but still people, okay, but me company, my rules, my reality, so I need to to see it working uh so in in big companies. Usually we we use um long term engagement to to make this possible uh usually related with adoption and transformation, so yeah to to find that crazy people.

C

You need to to do this transformational engagement that are pretty much changing cultural aspect aspect behavior in relation between areas, so at the end, the technical, the technical work is super short. It's like just a few weeks on my perspective, but the work with the company uh with the areas uh is like a lot of months. So that's I I think is that totally different, because uh right.

A

Now github's.

C

Like always, we is not like okay, it's new, but it's totally there. We are using it every day day to day. So um I think that's that the main difference between big companies and small companies.

A

Well, I think, regardless, if it's big or small, um failing and failing fast and having upper management, um allow their teams to fail is really what drives that in that innovation and allows.

A

You know a shift to something like git ops to be successful, so yeah, failing, failing and failing fast and being supported at failure is really important. So.

D

And I'm glad sorry, if I can just add to that as well. I think because we're talking about you know git ups as a paradigm, it's not a specific tour technology. I think that businesses can like slowly bring it into into their. You know their ways of working, so you know you can. If we talk about those principles I was talking about before, you can slowly start to release that you don't have to say. Well, okay, we have to change absolutely everything for good ups. Today you can slowly roll that into business.

D

You know you can start declaring your files before you. You know roll them all out. You can, if you're not using get or source control, you can start using that and you can slowly bring that into the business as well. So sometimes it doesn't have to be as scary as as some people think of of what google's actually.

B

D

I'd like to I'd.

B

Like to ask one question of for christopher, do you think um get ops? The like brad was saying the principle is one of the few trends for lack of a better word lately that is agreed upon between developers and the operations side. Or do you see? Do you still think there's like a disconnect?

B

You know like in the past we used to have the developers have one deployment tool and then operations to go by a different deployment tool. Do you think get ops is solving that problem.

E

Yeah, I think it you know basically hides the deployment tool from the developers you know behind whatever the git is so that that they're not having to worry about it. So your cicd pipeline, you know it's still there doing whatever the deploy is somewhere, but it's not something that the developers have to see or interact with, so they don't get distressed by it. Hopefully,.

B

A

As sergio mentioned, the evolution of the tooling around get ops, and I certainly have seen that happening which takes me to ortillius so brad and steve kind of bring us home brad brad you're, leading the team out of australia for building out our get ops roadmap.

A

Can you give us a little high level summary of what that looks like and maybe steve you can chime in and give us an idea how long it might take to to build out an ortillius interface to get ops.

D

Sure so, at the moment where we have a small working group and we're really going back to basics, where we're writing a small white paper on on what git ops is today what it can be in the future and we're really doing the research stage, you know we are researching uh flux, flagger, argo, so there's so many um great operators and and tools out there um and then we're also seeing how that's beneficial for this as well.

D

So um we're really trying out these tools at the moment and then we'll be building the roadmap out of how we can implement it, and I think it's going to be a big alignment throughout the ortelius project as well and we you know we come together and we collaborate on on what we think it is. We define what git ops is to us and how we want to use it. We align and then we we go from there.

A

And steve from your perspective, um how big is this project for us and for the team.

B

Well, if you, if we kind of circle back to what christopher was saying um where you have uh when we were talking about a number of the number of files that you had to deal with the manifest files and the the templating that can be used to help minimize that, basically, what we're looking at from the arterial side is extending that so ortilius would be driving that process.

B

Ortulius has all knows the relationships.

B

It knows all the metadata about a microservice for example, so it's really going to be pulling it all together and uh for lack of a better word kind of like the the get ops editor um for your clusters uh and not only in in one stage of your pipeline, but all the way through um as part of that process and we're uh what brad's doing on his side, with really looking at the the basics and seeing what capabilities these different get op operators uh have and how we're going to fit into that is going to be.

B

Where we'll have to do a lot of work to see what the strategy is. Hopefully, the cncf get ops working group is going to come up with some of the standards, because that's one of the things that's lacking right now, some standardization, which makes it a little bit difficult from the artelia side, but nothing that um we're. You know within the next six months, we'll we should six to eight months.

B

We should have something out the door that we can start playing with and kind of kick the tires to see if we're on the right track, and hopefully, at that time the the the operator side will be start merging with uh the artelia side um on the standardization.

D

Exciting times ahead,.

A

Yes, I think so so. Thank you, gentlemen, um for all your insights. uh We uh are thankful for your for your input on this topic and I want to say if those of you who are watching out there are interested in getting involved in this project.

A

uh We do have our own get ops working group on the artillia side. That brad is is leading. You can find us at artillios.io. You can also join the ortillius google group look for ortillius os on the under google groups. If you join that, you will get the calendar invites and you will see when our those meetings are, and you can also keep track of.

A

What's going on at on at github under ortillius, and also there is, as steve mentioned, there is a sig or a get up sig under the cncf, and if you take a look at cncf.io, you can find information on that as well. So we'd love to have your input, we'd love to have your contribution to the artelias project and in particular around this particular effort, and on that. Thank you again. We are out of time, um and I hope that everybody has enjoyed the uh our our first microservice visionaries, artelias user conference.

A

A

A