Can everyone hear me at the back? Yeah? Yay. Hi, everyone. Welcome if you've just joined us. My name is Jonathan Clark. I'm going to be talking about something that's a little

bit different than infrastructure as code, even though that's in the title of my presentation, which is how we can get people who don't write infrastructure as code to still get some of those benefits. Let me start quickly by introducing myself. I'm a sysadmin. I was a sysadmin originally. Now I've kind of moved over more to the let's make some software

to help what sysadmins do, what we used to do. I work with a company called Normation that I cofounded in Paris, and we work on two projects there, open source projects, which is why we have it across them, called Rudder and MTF. I've been contributing and

computing, yeah? Contributing and computing the open source projects for quite a while now. I used to be an OpenLDAP contributor. I also contributed some to CFengine in the past. And during time when I'm not behind the screen, I also co-organize events. A really shameless plug, DevOps Days Paris is happening in Paris. It saves time,

it improves reliability, it avoids making the stupid mistake that you make when you're

doing the same thing on one, two, three, four, in my case, two, in some other people's cases, 10, 20. Oh, I forgot something. Damn. So it's better. It's much more scalable. You can manage one or 10,000 or whatever machines are using that. So I think we could

basically agree that is the way you do it, right? If we're here, great. We're in the right place, we're considering the right problems, that's awesome. So just to move away from that very optimistic note for a second, let's look over to a typical IT team. And typical is going to be exactly not what any of your IT teams

look like, either because you don't unfortunately have a mixture of men and women, either because you have more or less than six people. But anyway, roughly an IT team in some company somewhere. You develop applications or you deploy applications, you manage operations, you manage security, you do IT stuff, right? We all know what we're talking about.

And then one day, this team comes along and says, right, we should adopt some kind of automation tool because of all the cool things we just said before. What will usually happen then is that a minority of people, let's say one, two, maybe three, will become really good and expert at using whatever tool they're using. And I'm not going to

take sides for a tool here. There's loads of them out there. They all work very well. We all manage to get the job done anyway. Could be CF Engine, could be Puppet, could be Chef, could be Ansible, could be whatever. And also, obviously, this doesn't apply if you're in a team of one or if you're in a team of two and you both become the experts. But in, let's say, the other 80% of cases, these people are going to become

experts. Good, good. You need people that are experts. You need people to dig into the tool to know what they're actually doing. That's awesome. But what happens to the others on the team, the ones that are there and they don't really dig into the config management tool? They now have to do everything on their IT infrastructure or pretty much

everything and I think you've tried to automate using the tool. So you need to change your config file. Oh, yeah, no, no, you can't just SSH into the server anymore and edit it. No, no, no, no. No, you have to go through this other language that you guys don't know about. Oh, yeah. You can't actually deploy any new software, new features, etc. So this ends up with a kind of ugly

diagram. What choice do they have? They have one choice, which is to either learn the tool and try and become experts too so they can write our DSL, our Puppet code, our CF Engine code, whatever. Or, unfortunately, and I've seen this

happen quite a few times, these people get left behind. That means they can't partake in everyday IT operations and basically it's a bad thing. A bad thing, trademark, with a capital B and a capital T. And I don't mean to say that we're doing everything wrong. Obviously we're doing a lot of things right. I'm guessing there's a lot of people in this room who are

amongst the experts, who have a team where 100% of the people are able to do this, and that's great. Unfortunately, I do believe that there's quite a few companies and quite a few teams where this is happening. Has anyone ever seen that happen? Any companies you've been in? Yeah. Yeah.

Really? So yeah, you recognize this pattern. I think that it's important that we as a community around automation tools think about this as well, because the fact that we can do it is good. It's good for us. It's good for our employers. It's good for our colleagues. But it doesn't mean that we're necessarily going in the right direction. Let's focus on what we're actually asking people to learn.

This is just a random example. Let's say you want to do some SSH, some RPM-I, a great way to install software, editing some config file, restarting service. It's pretty basic stuff. You learn that in any kind of IT school. If you've been working in IT for, let's say,

20 years, you know how to use all of these commands or services, maybe on the recent side for some of those guys, but still. Instead of that, I took a random example here. This happens to be Puppet code. It could have been any code. Lots of people know Puppet. Of how to install the Apache package on different operating systems, depending on the name of the package you want to install.

This is pretty nice when you're an expert. Yeah, that's cool. Instead of typing that, you have to type that. You actually have to type not just that, because that's only one of the lines above here. You've got to learn to use Git or SVN to commit it and to share it, and to actually check maybe using the testing that guys from Puppet Labs, interestingly enough, were talking about earlier, and so on and so on.

Yeah, what we're asking people to do is hard. It's easy for us, maybe, if we're the ones that are able to do it, but I think it's not something that looks simple here, anyway. I guess that we could agree that getting everyone

in a team that's not, again, a small team of one or two people, one or two experts, is hard. There's a steep learning curve. Learning these new syntax, learning all these new tools that you have to use, changing the way you make changes is hard. I often see people with a complete lack of motivation.

I've been doing this job, someone says, I've been doing this job for 10 years, and now I have to change the way I do it, but what for? This is really hard. I've got to learn more stuff, and I don't really see the benefit. And they end up saying things like, I could do this quicker by hand or with a shell script. Yeah, for sure, you probably could on one or two machines, maybe 10 machines. I would say if you're managing 10,000,

probably not the same situation. Or as XKCD puts it, this is two different graphs of, I spend a lot of time on this task, I should write a program to automate it. This is what's supposed to happen. You spend more time, and then you spend less time. It's great. What often happens is that you spend more time, the code doesn't actually work, so you debug it,

then you rethink it, you refactor, you rewrite it, and actually you end up just working on the automation tool. XKCD is a funny website, so this is a joke, obviously it's not the reality. Crazy. Except sometimes.

Let's look at the bigger picture for a second here. God, I'm like the guy before, I'm going really fast through these slides. Situations where we have complex technology and we're getting people who are not expert in that technology to use them are all over the place.

This picture here is a control panel to run a submarine. Wow, submarines, scary technology, right? Actually it turns out this is a submarine in an amusement park, in the Finding Nemo amusement park. It's a little bit less mission critical, but it still has real-life human beings going underwater in a closed container.

So it still is kind of mission critical, at least to those people. And the people, yeah, anyway, you get the idea. This kind of control panel involves knowing how to use the control panel. It does not involve knowing how to build a submarine, how to figure out if there's enough oxygen in the submarine, how to figure out if all the onboard systems are running.

But still, people can run a submarine using a very simple control panel. Well, a quite simple control panel. We're doing the same in IT everywhere. When I started learning IT, we started learning to use assembly code. We could actually give instructions to a processor.

We could tell it to put numbers in memory banks. It's nice, it's very interesting. But if every day we were managing infrastructure, let's say, oh, let's spin up a new virtual machine in some kind of cloud infrastructure. If we had to do that writing assembly code, what? It's crazy.

And every day we're building interfaces on top of other interfaces. People don't really write assembly code much anymore, at least in mainstream IT. We tend to use much higher-level languages, like really high-level, like C, for example. Really high-level. You're not writing any assembly code. You can allocate loads of RAM.

Maybe sometimes the RAM doesn't even exist, and it's virtual RAM. It's really high-level. And then since more recent years, people have been adding and adding and adding interfaces, and we have these even higher-level languages that actually abstract handling memory. You don't actually choose how you use the hardware anymore. It's just crazy. Languages like Java, which I heard lots of good things said about earlier, how reliable it is.

Just quoting the previous speaker, of course. And higher and higher still. And now we don't even run necessarily any programs on exact hardware anymore. We say, I'm just going to push this code to somewhere, and it's called a platform, and it's a service, and it happens,

and there's a machine. Maybe there's a machine. Maybe there's several. I don't know. No one knows. We've got tools to help us with this. We've got APIs. We've got IDs. But weirdly enough, in our space, we don't talk about that very much. Sure, there's different interface levels. You can write modules.

I learned this morning that in Puppet, you can even have modules that inherit from each other. It's pretty cool. But yeah, we can definitely do better. So if I look back across these points where we could improve, getting everyone to learn configuration management,

everyone to use configuration management, there's this deep learning curve. Okay, let's get simpler interfaces. Let's have the push buttons like on a submarine. No motivation. Let's show people what's happening. I would love to press the buttons on that submarine interface and see the submarine.

Let's show people what's happening. Enable quick wins. Oh, yeah, I just did something. There's a green light. We like green lights. Green lights are encouraging. They're positive. So how can you go about doing that? We don't want a steep learning curve. First thing, let's separate the content and the controls, the how and the what. If I want to install, let's say, the Apache package or, let's say, a web server on a machine,

I don't need to know what the Puppet or CF engine or Chef code to call out to the package manager and choose the right package name is. I just need to be able to say install package X. That's all. Separating content and controls, again, not a new idea in our space. It's coming from web frameworks. We've been doing this for years.

What about the lack of motivation? Let's show benefits to users. I find it depressing using traditional infrastructure as code when you write some new code and you test it on your machine, like, oh, yeah, this does what I want. That's nice. And you commit it to the repository, and it goes out to 2,000 machines.

But you never know that. You never see that. You don't get the feedback. Hopefully, I mean, sometimes you do get the feedback when the monitoring goes red everywhere, but that's not very much more encouraging. In fact, it's quite the opposite. So let's show people how it's going. Show what it's worth. Show what works.

What about frustration? Let's make it easier and quicker to achieve success. Do simple things. Provide ready-to-use configs. Provide simple examples. This doesn't mean we can't hack them. It just means they're already there. It means we're not reinventing the wheel in every single company or organization that sets up config management.

So I gave this some thought. For anyone who's at DevOpsDays in Ghent back in October, I kind of already presented this same idea. It's moved on in my brain since then, but instead of having our IT team, which was split up earlier with the gray guys wondering how do I do work now, and the orange guys were like, yeah, we're the experts. We can write this code.

What if we separated these out into layers, like the whole of the rest of the IT world has? We still need the experts. That's most of us guys in the room, so that's good. We're still needed to fine-tune modules, to be the ones that say, yeah, actually I need to change the options I pass to AppGet or to Yum to better install packages.

I need to adapt the way that I deploy code across a load of servers instead of just one. Yeah, we need this expertise. It needs to be there. We also need to manage the tool itself, deploying certificate authorities, the tool, the communication. The experts are here, but we can have an abstraction layer above that,

which makes it possible for people who are not willing to write CF Engine, Puppet Chef, et cetera code, and focus on the task they have to do. Be able to say, yeah, I need to install a package. I need to put this in the config file. That's it. I can say it in about 10 words. We don't need to write 100 lines of code to do that. Use what they have.

And then there's probably a third level higher up where people aren't even doing. They're just setting a direction. They're just seeing if everything is okay. From lots of us in the room, that top level is probably our boss or our boss's boss, but still, they are the ones that at some point are going to give us the green light to go and spend loads of our time on some automation tool, on some configuration management tool.

So we probably should give them some kind of benefit. So this stuff at the bottom, we're good at. I was listening to the talks earlier. We were talking about some pretty in-depth stuff at times. We were talking about other tools that integrate as well, which is going up the stack in the way that I'm suggesting.

We talk about this a lot. There's a lot of talks. That's great. We're experts. We share expert ideas. It's cool. But we don't really talk about this stuff very much. We don't really consider how our team members are. Well, hopefully we do, but it's not a general blog post topic.

How do I get my team members to start using Puppet Chef, CF Engine, whatever. It's not something that we write about a lot, which is why I'm talking about it. So I want to just explore an example here that's based on two projects that I co-created in both cases,

NCF and Redder, of how we can actually achieve this. And this is stuff just for the context. I've been doing this for about five years now, but it's something we started out with. We've been helping companies that are not your average startup company, that are more the kind of medium to large sized corporation,

where your sysadmin team probably isn't three or five people. It could be ten people, or in one case, one company we worked in, the sysadmin team was 120 people. We think, oh yeah, we should just give these guys some training. Yeah, okay, we can train 120 people, but that's a lot of work.

And they're obviously not all going to be experts, even if we do. Quick introduction to these tools. What is NCF and what is Redder? NCF is a framework that actually runs in pure CF Engine language. We had to make a choice at some point. This could have been anything, to be quite honest. There are reasons why we chose CF Engine, obviously, but for the purpose of this discussion,

it's just a way to structure infrastructure as code, make it shareable, make it reusable, with single purpose components. Basically, if we look back at the diagram I had before, it's this abstraction layer in between the infrastructure as code we already write, and we know how to tweak, and people who can use other things.

It too works with a layered method, a layered approach, generic methods, which will be very simple unit tasks, and our attempt, our goal at least, is to have these unit tasks as non-debatable, not subjective, but objective. Installing a package, there's not multiple different ways to install a package.

I always hear the joke about the number of Apache modules there are on the XForge, PuppetForge, ChefForge, whatever, it doesn't matter. Something like more than 10 different ways of configuring Apache. Yeah, okay, probably. That's a problem because it means that loads of people are going to have to choose

between the different existing ones. It means that loads of people are actually going to end up writing a new one, or taking one and hacking it and adapting it. So we're not doing very good sharing there. But if we have lower level unit tasks, then obviously those can be shared much more efficiently. Installing a package is installing a package. Yeah, sure, experts may need to tweak how that happens,

but that's okay. So if we're sharing the interface, we're not sharing the code, so it's fine. On top of that, we have our, let's say, standard level users who are not infrastructure as code experts, but can use the interface that we've just created for them. This is again a separation of the content and the control.

So these guys are supplying the data. They want to install the Apache package, and underneath we have some people who have said this is how we install any package, this is a method. And right above that, some kind of services level that gives you an overview, statistics, reporting, so on. So an example is worth a thousand words, also I'm told.

This is NCF code, if we can call it code. It follows the CF engine structure, obviously, since it's based on CF engine. And we're basically just calling out to functions, package install thing, file from template, there's a template file somewhere, it gets copied to a destination. We restart a service if some weird condition could do better, I agree.

And we ensure the service is running. So this is basically what I said in the earlier example. That's all I want to do. And we can enable with the exact same power and the exact same control over details of infrastructure as code, as we all know it in this room today,

to give this ability to people who are not expert users. When I was here last year, I actually gave this exact same example in a talk on this exact same stage, so it's not really new. But we've been further since then. Since we can have this very simple structure of code, we've been able to build what you would call in a development world an ID,

an integrated development environment, which is basically a web interface that you can say, hey, I want to get these different blocks in here. Building blocks, one building block to install a package, one to initiate a file from a template, and so on. And I can just type out the parameters in the web interface.

And again, I'm aware that most of the people in this room are probably not going to want to use this because we can write the code. But giving this to your colleagues or your future colleagues who don't want or can't learn the way to write the infrastructure as code that we use every day, this can be a real enabler, a real benefit for them.

On a related topic, I'd said about two tools. Rudder is another tool, also open source obviously that we work on, that uses NCF as the abstraction layer underneath.

And it sets up an environment with same defaults that enables you to automate configs. Again, without any code, we can create automatic configuration. It looks something like this. You have, again, web forms. But these web forms, instead of being based on the actual actions we're going to do on each machine,

they're going to be higher level questions about what you want to achieve. This is actually quite low level. As an example, it's SSH settings for the SSH deconfig file. Nothing revolutionary in there. But what is actually happening behind the scenes is that these parameters are being injected into some of the NCF methods I talked about earlier, which have been written by experts, maybe experts like myself,

well, if I can call myself an expert, that have been shared on the internet and are available as open source. So we're not reinventing wheels, we're reusing building blocks. I like to compare that to Lego. I had this great picture of kids with Lego earlier, but my stupid computer lost my slides earlier this morning,

so I lost my picture of Lego. I'm not very good at actually doing the IT thing, I just talk about it, I guess. What that enables us to do is, since we're using all of these building blocks that are quite low level, at the end of the day, every time we touch a file, we're going to be going through one single piece of code, which is in our lower level infrastructure as code method.

And we have been able to build in reporting, so feedback from each of these actions that we make. This means that every time we touch a file, every time we install a package or upgrade a package, we send some feedback back, and we get the red and green lights at the end of the line there that show people, yay, it's working.

So think back to the submarine panel we had earlier. You touch a button and a light goes yellow. It means something's happening. At the end of the submarine moving down into the water, the light goes green. I'm like, yay, I did it, I did my job, it's awesome, it worked. And we can do the same thing here with infrastructure as code, without writing code. You can say, yeah, I want to install this package,

turn it out to these machines, and a few minutes later you have a green light. This is helping. I've seen people so happy just to see the green light, it's crazy. It's like, oh, yeah, there's a green light. Yes, that's not really the main feature of the software we wrote, but yeah, okay, cool.

Here's another example of that, and a final example of a dashboard that we integrated that is more for that third level. I said, you know, your boss or your boss's boss. For each and every item that we configure, each Apache package on each server, we can build things up, we can consolidate, and we can show a global overview of how is my IT system happening.

What does compliance mean in this? Compliance means what percentage of configurations and machines are in the state they should be in. So, for example, let's say I write a very simple policy

that says that my SSH server should never accept root connections and that the SSH server should be running. If I deploy this to, let's say, 10,000 machines and 400 machines don't respond, or 4,000 machines, we're going to be at like 60%. If some of the machines I can't edit the file for some reason, I don't know why, but assuming,

then that's going to be low in compliance. That's a very simple example, but if you set up a whole security policy as a rule in Rudder, you can get compliance. For example, you could set up PCI DSS, have very strict rules about credit card handling. You could set up some of those rules in Rudder, and it would report the compliance, the percentage of compliance to PCI DSS.

Do you use CF engine policies as well to do this policy? Like I said, Rudder is based on NCF framework, and all of the methods in NCF are written in CF engine language. So at the end of the day, the code that's running on each machine we use is CF engine code,

plus or minus a few patches, but basically CF engine code. So all of the reporting that says, yes, I've done this, or yes, I've checked this, or yes, my PCI DSS compliance is good or bad is CF engine. Could the reporting also be to other machines? Yeah, we have a way actually of sharing state between two machines.

Like saying, simple question, is your database set up? No. Is your database set up? No. Oh, yes, it is. Okay, right, I'm going to continue configuring something else. So yeah, it's not the same mechanism, but we could share the same idea of state from one machine to another.

And that's again nothing new. I think there's a talk about console later. In fact, in this same room, which is on the same topic, very interesting stuff. So that's nothing new from a technology point of view, but what is, I think, slightly new is the way that we can make this more accessible to non-expert users by saying, again, in a web interface, you know,

go and get this info from that machine over there, wait until it's done, or just abandon it if it's not done. I'm not very familiar with CF engine, so maybe that's something. But what I find challenging from my experience

is not only learning a new DSL like this, this is a steep learning curve in data as well, but it seems we have a lot of automation in place, and we have a particular way of handling all these resources. It's also very difficult to enable the non-experts to actually do the managing itself.

So what I find difficult from their perspective is that they actually have to go in and configure in one way or the other. So is there a way to actually expose these resources as a commodity thing,

but not give them too much power to actually break the system? Right, I follow your reasoning, so I'm going to repeat the question for the recording, or some of it, anyway. The idea was, I think, and please correct me if I'm wrong, giving out access to different hosts and control through web interfaces

may be enabling people who don't know exactly what they're doing to break things. Is that a fair summary? Yeah. What do we do about that? That's a very good question. It's very interesting because obviously the easier you make it just to click, click, click, obviously you can break something. If I could go to that submarine panel and just press,

oh, empty the oxygen out on the button, I might do something really stupid very easily. I have two views of that. Either these are people that need training and they should know what they're doing and they're professionals and we're in a job, we're not having fun at home clicking on random interfaces and that shouldn't happen. Okay, maybe.

Other solutions are access control management. We could very well, we don't have this currently in Vado, but I'm sure that other software that does the same idea could have it and will have it one day. We could say you're allowed to modify these parameters, but not these other parameters.

Or you're allowed to use these values, but you're not allowed to use these other ones. There's an example that I like particularly. I live in France. In French law, we have two conflicting laws. Law number one is that to prevent terrorist activity and aid in understanding it, we're obliged to keep any logs from access to web servers for minimum one year so that the police can request them

and analyze them, do whatever they want to do. On the other hand, for respective privacy and individuals' privacy and leaving traces around the world, it is illegal to keep any web access logs for more than one year. So in this case, imagining a web interface

where you could choose the number of days to keep the logs for, we shouldn't be able to change that. It is not a parameter we should have control on. We're obliged to put in exactly 365 days. That is the law. But that doesn't mean we couldn't change other things like how we can press them, where we store them, what the naming scheme is, whether we centralize them to some other syslog thing.

So I think that there's room for quite specific access control on the values that we're putting in. And again, this is two different jobs. One of the jobs is for, let's say, the experts to say how we set that up. And the other job is someone who knows the law,

someone who knows what they're doing, to choose what is allowed when it's not allowed. And actually, the third part of my two-part response is that you can also include, and we do have that in Red Hat, a validation system, exactly like pull requests on GitHub or in GitLab or whatever. You can say, I would like to change the config like this,

and it goes over to a senior admin or colleague or whatever, just a second pair of eyes, basically, to look through it and say, yeah, okay, what you're doing is not going to break things. Or, actually, we're doing a major upgrade of the whole infrastructure this evening. Maybe we should do that tomorrow instead, something like that. Another false possibility is to have specifications

or tests for, like, for your, you can keep the logs, or you have to keep the logs for one year. You can just express it in a test, and then the test goes red if someone changes it before it goes live to the production server. So I guess it's possibility number four. Yep. Which doesn't exclude the other possibilities.

Absolutely, yeah. I'm going to repeat that again for the recording. We're saying there's a fourth possibility, which is to add some automated tests to express that requirement. Say, yes, the logs must be kept for 365 days. And then if ever anyone changed it, and the test goes red before deploying to production, obviously, then you would know about that,

and you'd have kind of a barrier to protect yourself. Yeah. How do you deal with scenarios when you've got organizations that are running change management procedures like ITIL, and you have to have a feedback to say the change is complete, and it needs to report up a chain that it was done within a timely fashion,

if there were any issues, errors? Basically, by integrating with your config management tool. Part of having feedback, I think, is the same requirement as you're discussing. The human in front of the machine that just made the change wants to know what happened, and basically the process, the ITIL process

and habits that have been set into place also want to know that. So in this specific example, using weather, you can get the status of a change at any point. You can be notified via an API, and you could report that and integrate with, I don't know, some kind of script that reads the data from weather and puts it into your ITIL change management database.

Is that a good response to your question? Cool. Yeah, another question? Is it possible for the expert user to specify a dependency or kind of step between your building blocks?

Yeah, absolutely. Absolutely. In fact, it's recommended. That, for example, if you had a, I don't know, a building block to edit the MTP config file, that would actually require and depend on the building block to edit a generic file. So exactly like the way you would call

all of the operations in a Linux system at some point, and we're going to be calling basic kernel operations. It's exactly the same. At some point, there's going to be a few base items. There's actually not that many things we can modify on a Linux system, and on a Windows system, I guess.

You're basically talking about packages, files, maybe some tunable CCTLs, I'm missing one, processes, and that's pretty much it. So basically, of those four, there's probably a few more items at the bottom level. We can have items at the higher level that call them to them and so on and so on. So yeah, you could, well, you would, in fact,

have these dependencies. That's actually part of the whole power, is that you can then tune just in one place what you want to happen, the way you want it to be changed. A nice example of that was a customer said to me once, I really want that every time there's a file edited that you copy the old file and the new file into an SVN repository and you commit it.

Okay, sure, why not? Just using this NCF framework, we could modify just that base method that edits files and do that. We just implemented that for him in this one place without any special features or anything. Okay.

So if we just look back at the diagram that I had earlier of how I feel that things should work, these are the three different layers that I had imagined, that we had imagined. Experts at the bottom, fine-tuning modules, hacking around with things like committing files into SVN every time we change one, why not?

Exposed to an abstraction layer to users who are not happy or comfortable, just not up to that today, writing infrastructure as code, and showing that with, in this case, the rudder on the left-hand side here, to their bosses via even higher-level reporting. So basically, instead of having this flat hierarchy

we had at the beginning with people who are experts and other people who are not, mixing things up so that everyone has something to gain from that. So basically, my hope is that the next IT teams that do follow this kind of thought process, instead of ending up with a group of experts and a group of people left behind,

will look something more like this, mixed up people, experts, non-experts, working together using the same tooling. And as I said, I've been speaking very quickly, so I've actually reached the end of what I wanted to discuss. Do we have any more questions?

Just one addendum. I usually call this doing good cargo code programming, so you have to provide code blocks which your non-expert co-workers can just copy

and they don't do any harm to your software by doing copy and paste programming, because you already gave them an indirection, like I want the service to be started, and then you have a define or function

or whatever it's called in your configuration management tool, and they can do cargo code programming, like just copy and paste it without doing any harm, because they just copy one block. People usually tend to, and we all do this, like going to Stack Overflow, or copying out some code block

and copying into our program without understanding, like Stack Overflow driven programming. So this is what I experienced from, or this is what I have seen. So basically suggesting that we use,

we provide templates to our users so they can copy and paste, and reuse them without making mistakes, making it much easier for them to write with. Yeah, I agree with that. So I don't know if there are any more questions. I know this has been a maybe unconventional talk for FASTEM. I just wanted to put out some ideas here,

suggest that there are other ways of thinking about what we do do every day. I hope that I showed you how we achieved this using NCF and Rutter. I'm not saying you should go and use just NCF and Rutter. Do check them out. That would be cool. But I think there's thought to be had about how we include everyone in our team

around config management and what we do there. Any other questions? No? Okay, well, thank you very much.