Service Templates

[00:00:00]
>> As I said, we wanted to try and solve two big problems that a lot of organizations deal with. The first one is definitely, as I said, automation in the sense of standards around your services and things like that. And I've been able to show you at least how utilizing something like Pulumi and really just a programming language can help you create a lot of those, again bowling bumpers, as we've said, to help our developers not shoot themselves in the foot.

[00:00:33]
There's another problem, though, that I have dealt with for a long time that actually I had a buddy of mine kind of bring to me, and I would have never thought of it. And I wanna share this with you because this is the second tool outside of the tool I just showed you that is saved, even my company where I work at now, a lot of time.

[00:01:02]
So let's do this really quickly. We're gonna create a new document really fast, and it won't be the same thing as it was before in the sense of legs, but we are gonna need a document of some sort. So the document we're gonna talk about here is service templates.

[00:01:18]
So the problem we have here is we have services that all use similar ways to build, test, and deploy. However, we have to copy and paste these configuration files every time. And this is super common when you're talking about microservices or things like that, where I have a standard now, right?

[00:02:00]
We only work in Node.js or we only work in this or we only do this, right? And we realized that we got a lot of benefit out of service directory by leaning on automation generation and stuff like that. So how can we solve the problem of services all using similar configurations to where we don't have to write a single line of code, right?

[00:02:30]
Because that's the real goal here, with service directory or with anything else is just the bare minimum we need to write to get this working, is what we wanna focus on. So what I'm gonna quickly outline is what we have, to give a better example, we will say what we use to or use for CI/CD, right?

[00:02:57]
And there's gonna be a couple of things that we talk about, so what we use for CI/CD. Okay, so the first one is, say, Docker, right? We know that we're gonna be building Docker files, we know that all of our services are gonna be in Docker files, right?

[00:03:15]
And so we know that across the board, every one of our services uses Docker in some way, shape, or form. Also, they use CircleCI. So Docker is for our image, and this is for our build and testing, right? And again, every repository uses these in some way, shape, or form.

[00:03:34]
It might not be identical, but it's a lot of boilerplate code that we just copy and paste and copy and paste and copy and paste. So what do we want to achieve here? What do we need, right? Well, just like with service directory, we need a DSL or a domain specific language to help us, so that when we want to generate these templates, they will be unique to the specific service, but they will always get the same changes, right?

[00:04:11]
So we need a domain specific language that allows us to configure templates for services, right? And then we also need a CLI tool to generate templates from our DSL, okay? And so what this really starts to look like is a tool that will autogenerate the things that we basically always write.

[00:04:46]
And so what we're gonna say, and again, this is just really quickly here, our solution is we want to build a CLI tool that has templates in it, which we can configure with external, we'll say JSON files, to generate build configurations, etc. Right, and I'm actually gonna do another thing here really quickly, which is if chart never thought I was gonna get into Lucid, they were wrong.

[00:05:23]
I love workflows, I haven't been able to show you one yet, but I'm gonna show you one now. So let's create a super simple chart of what this looks like. We go here. Okay, so to visualize this, right, first thing we're gonna do is we're gonna grab a box Right, and this box here is what we're going to call our build.json file.

[00:06:01]
Sorry, build.JSON file. Now, this build.json file is what you can kind of consider to be a package.json, right? You can consider it to be basically a file of configurations. That's it, it's just got a domain specific language that it uses, and we can configure services with it, right?

[00:06:24]
So we'll say that we have a build.json file, right? And not only do we have a build.json file, but in that build.json file, we give it specific options. So for example, in this case, we'll say, all right, well, we need a service_name, right? We need a way of knowing when we generate the templates, what service it's for.

[00:06:50]
Can anyone guess why we might need to know the service_name? We said it builds Docker images, right? So how would it know to build the right Docker image? That's why we do it. It's because we need to provide, again, we're back to the scenario where it's the developers, what they're expecting to do, right, because everything I've shown you, the developers are doing, just to be clear.

[00:07:17]
[LAUGH] I'm not the one adding services to service directory. And I'm also not the one creating configuration files in a service to make it so it can build, right? These are two huge problems that I guarantee most companies that you guys have worked with has been a one on one interaction with the DevOps team.

[00:07:38]
Where you've had to go to the team and be like, hey, I need build configuration file setup. Okay, cool, let's go do that, or hey, I need a front end deployed, let's go do that. We are literally getting rid of those problems with these tools. So we're gonna say we want a service-name, right?

[00:07:55]
And then maybe for ease of sake, we'll also say that we want a service_type, right? And so maybe we wanna be able to deploy back ends different, there we go, come on now. Maybe we wanna be able to deploy back ends differently. You really can do it. Okay, deploy back ends to a specific location and front end to a specific location.

[00:08:26]
So once we have the service_name and the service_type added to this build.json, then what we do is we create a CLI tool. Right, and this CLI tool is going to read the build.json, right? And it will also have templates. And so what's gonna happen is when the build.json is read via the CLI tool, the CLI tool is then going to go out to its templates, and it's gonna inject the variables that we have here, service_name, service_type, etc.

[00:09:21]
And then what it's gonna spit out, Is our Docker file. That's right. Why should develop the right Docker files? They shouldn't, [LAUGH] or write there circleci.yaml, because we also don't want developers to be dealing with our build pipelines and [LAUGH]. And so we have decided that we will give developers a configuration interface, right, that they can use, and then the CLI tool will then output the files that they need.

[00:10:02]
What does that mean? It also means that if in the future, we need to add other things, write more, what if we wanna generate a npmrc? What if we wanna generate a, I don't know, gitignore? I don't know, whatever, like other standards that we have. We don't have to expect the developers to remember these things.

[00:10:22]
Now, all we do is we say, hey devs, you use our CLI tool, right, and configure your repository with this build.json. And then whenever you, [LAUGH] not me, whenever you run this CLI tool, you'll get the files that you need out of it.