Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Wrapping Up" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik wraps up the course by discussing how automation could be extended further by abstracting the network and cluster resources. Workspace outputs can be referenced by related workspaces, which reduces the need to duplicate workspaces for new network resources.


Transcript from the "Wrapping Up" Lesson

>> Let's take a look at the homework that you guys can essentially do. So if we go to 08-setup-configuration-directory, we've already had this concept of locals, and we've got workspaces and projects and stuff like that. And that's really nice, but it gets to a point where it becomes really unmanageable.

And we've talked about inputs, which is something that is done through variables, but we haven't talked about something which is called outputs, right? If we go to Terraform Cloud really quickly, You'll see that my workspaces provide me with inputs, right? But say if I go to terraform-tfe, you'll also see that there are outputs here.

Now there's none right now, but let's think about this from a programming perspective for a second. We just wrote a whole bunch of code, and we also made it so that it's configurable, right? What if we could pull variables not just from the workspaces themselves, but from other workspaces.

Like say, for example, what if I said, I wanna make this a little bit more complicated, and I actually wanna make it so my networks follow the same pattern as other things. And so then I say, all right, well, I'm gonna create another locals file. And this will be all of my infrastructure configuration.

So what we're gonna do is we're gonna go to our workspace_aws file. Now you might say, why are we going from locals to workspace_aws? Because we're gonna add more logic. It's a little complex, but the TL;DR is it's just a big for loop on our networks. So in the same way that we're doing for loops in other places, I can do for loops on our networks.

And so then later on, if I wanna create more networks, I don't have to do copy-paste, even on the whole workspace level. I've now abstracted workspaces into their own dynamic code. So that now I can say, all right, well, if I wanna mess with infrastructure stuff, then I can just add a new network.

So if I was to say, all right, I want to add another network, in the old scenario, I'd have to copy that whole workspace code, paste it, and then put in my changes. But in this scenario, I don't have to do that. All I have to do is paste it like that, commit and push, and now I have a whole new network.

Same thing for the cluster, right? So another thing that you can do with this, which is really awesome, is you can actually create what we talk about in DevOps for developers. So be sure to check out the DevOps for developers course. We create our own service directory, and that's in local_service.

And I want you to stew on this for just a second. The goal here is to make it so that developers, if they want to configure their services, they only have to go to their service repository or terraform-tfe. That's it. And this is how it works at Hippo.

We have a main repository that has this configuration inside of it, so that developers can go to that repository and copy and paste a couple of lines of code, put in their variables that they need. And then we have pipelines get triggered downstream, right? So terraform-tfe gets applied and saved, and the moment that's done, we then say okay, well, let's do this.

Let's go to our service repository, for example, so let's go to that example repo. And again, this is homework for you guys. And let's go to the last branch in that repo, 08. If we go here, looks pretty similar, except for look at what we've got here. We have a data file, or a data resource.

This data resource, look at the workspace it's looking at, eci-tfe. So what's going on right now, right? What we're doing is we're making it so that the developers have to touch less things. And we're saying, hey, Devs, all the stuff you care about, it's in our configuration domain-specific language in terraform-tfe.

Just go there and we'll make sure that the pipelines downstream get triggered. You don't have to worry about if it's a cluster or if it's network or what's got, just we'll take care of that, put your configuration in your repository, right? And so once this is added to the terraform-product-service repository, what we can do then is we can then use more logic to create all of our services.

And so this is a fun little for loop, where if you look at this long [LAUGH] value right here, you can kind of consider this as an import in your code. But it's actually an API call request made to the other workspace. So that it will check and see, okay, any non-sensitive values named services, which we said, oop, sorry, which we said, if we go back to our, GitHub, f4, sorry, two seconds, tfe, and then we go to outputs.

This file is what makes it so that other workspaces can then see those outputs, right? So if we think about the whole flow, a developer comes to tfe, right? Adds their service to local_service, right? And that's it. They walk away. They commit, all of the downstream automation gets triggered.

That's it. The developer doesn't have to ask, did product service run, or did anything else run? No, because we only make sure you care about just the one thing, right? If it doesn't get out in a matter of time, hit us up, let us know, we'll help you, right?

But it removes the need for developers to have to touch as many things. And so again, if we look back at our eci-terraform-product-service example, we have service here, right? And then, the other thing that we do is we just go to main and then we wrap this in a for loop.

And that's it. Now, whenever a product service is updated, it will go out to tfe-workspace, download the data, and recognize if there are any new services or not. If there are, it will add them to the for loop and create those new services. If there aren't, it will delete any ones that aren't in that for loop, right?

This is service directory configuration. This enables you to have your configuration at a very high level and then let it slowly go downstream, right? So that anything, okay, Google, okay, Amazon, okay, Azure, developers don't have to care about that anymore, right? Because it's just being brought into the automation for them and the only thing that they have to worry about is the configuration inside of the service directory.

And that my friends is enterprise cloud infrastructure in its fullest. Completely dynamic, completely modularized, with its own separate updating life cycles, its own separate approval and policies, as well as the complete control over where and when you wanna update things. So I appreciate you guys watching. Thank you so much.

Be sure to check out the repos. If you ever have any questions or anything like that, you're more than welcome to watch me or check me out on YouTube. I'm sorry, on Twitch. [LAUGH] But thank you guys so much for being here, I appreciate it, and that is the course.


Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now