Introducing DevOps for Developers

Infrastructure Standardization

Erik Reinert

Erik Reinert

Introducing DevOps for Developers

Check out a free preview of the full Introducing DevOps for Developers course

The "Infrastructure Standardization" Lesson is part of the full, Introducing DevOps for Developers course featured in this preview video. Here's what you'd learn in this lesson:

Erik discusses identifying the problems of and creating technical design documents regarding standardizing infrastructure and CI/CD. A technical design document is created for standardizing infrastructure in the segment.


Transcript from the "Infrastructure Standardization" Lesson

>> We've talked a lot about theory, practices, how to take good steps towards building stuff. Another thing that I really wanted to share with you guys is actually tools that when I first was even introduced to the concept of them, I think were pretty massively revolutionary at the company I was at.

And I think that they solve individual problems, but they also do a really good job of showing what DevOps is supposed to have opinions about and what it's not. So yeah, we're gonna go ahead and just jump right into it. We're gonna talk about identifying problems, right? We talked a bit earlier again with technical documents of how it helps you break down a problem so that you know if it's worth doing it or not, essentially.

But once you have a problem, obviously you can start working on it, but how do you know what is a problem and what isn't, how do you, see, this is an issue? Normally, something that is happening a lot is something you're hearing a lot. Our deployments are slow, our pipelines are slow, our merges are slow, right?

These are the types of problems that DevOps focuses on. There are two big problems that I think any company deals with and, oops, not that, actually it is around a lot of this stuff here. So we are gonna be working with these services and tools and stuff like that, but they all kind of exemplify a problem as well.

Most companies probably have some type of cloud account where they repository resources to. Most companies probably have some type of GitHub or some type of repository location for code or infrastructures code, stuff like that. And most companies normally have CI/CD or at least they try to. However, it's one thing to have these things, and it's another thing to actually wire them together to solving problems effectively.

And a lot of companies even have existing tools like Node JS or Pulumi, or again, CircleCI for CI/CD. Say, we're a completely brand new company, and we know that we wanna host an Amazon, we know that our source code is gonna be on GitHub, we know that we wanna use CircleCI or something like that for CI/CD.

But we don't want to move forward until we're confident that we have good opinionations and standards around the things that we're gonna put out there, right? And this is what's going to lead me to our first two problems that we can work on and create technical documents around.

The first one is gonna be standardizing infrastructure, right? Too many people too often have opinions on how something should be deployed. The reality of it is, it should be a collaboration and an ongoing process. Frontend doesn't necessarily have the complete control to say how they deploy frontend. They shouldn't, it should be a collaboration between frontend infrastructure, again, IT or anything like that.

And it's actually the same way with even CI/CD. There are these bridges that you have to work with, where, okay, we have more of a high level opinionation interesting that we need to make. However, we also need to make sure that we're not impacting the developers and stuff like that.

Let's see here, yep. So the first thing that I wanna work on is solving the standardized infrastructure problem. And we are gonna create a quick technical document to kind of help us here, and I would love you guys assistance with it. So what we're gonna do is we're gonna call this document standardized infrastructure, right?

S-T-R-U-C-T-U-R-E, if I can spell, there we go, there is infrastructure. And our problem is simply going to be we want to define, that's not the problem, sorry. We have no defined patterns or opinionnations we'll call them, right, around, I cannot spell. O-P-I, opinion, we're just gonna say choices around how we describe services in our infrastructure.

Infrastructure, S-T-R-U-C-T-U-R-E, I cannot spell today. So that's our problem. We're brand new company and we have no defined patterns or choices around how we describe services in our infrastructure. The next thing we're gonna do is is we're gonna say, well, what are these services? Right, first one is pretty straightforward, frontends, right?

We need a way of having opinions around frontends, backends as well, right? We wanna have a good opinionation around backends too, right? And then the next thing we can do is we can say, okay, well, we know what these services are, what do they need? What do they need, right?

And so for example, if we go to frontends, this is completely opinionated. So I'm not going to go super deep into this just because we also have to build it. But we'll say, for example, we know that frontends will need a bucket, probably of some type. We're gonna do static hosting, so we need a bucket of some sort or some place to basically store our flat files, right, our static files, I guess is a better word for it.

And then we also need an ingress of some type, right, some type. And this can be whether it's Kubernetes, whatever, it can be anything, but we just need to make sure that it's routable essentially. Outside of that, from a DevOps perspective, there's not much else, right? Now, we can add to this, we can say, okay, well, it needs this or that or whatever.

But when we talk about what we need from a very simple perspective, our frontends will just need a bucket of some sort or some place to put that data, and then a way for us to access it, right? So if we go to backends, oops, we can kinda do the same thing, right?

Where we can say, okay, for backends, we probably would want some type of container, right, of some sort of if we're gonna be using a container platform or something like that. We'll still need that ingress as well, right, an ingress of some type. And again, it can be a bunch of other things.

The reason why I'm showing you this is, you can already tell there's a separation between frontends and backends, right? In frontends, we're talking about, we wanna save as much money as possible. We wanna make it so that we're not spending for continuous uptime and things like that, right?

So we're already kind of making an assumption here that frontends and backends are intrinsically different in some regards. Another thing that we can say here is that, all of our frontends are gonna deploy the same way, that's what this also helps us do, right? Now, we're not saying, okay, two teams can deploy frontends differently.

What we're saying is, two teams can build front ends differently, but they have to deploy them the same way, why? Because that's how we support them, right? We know how the infrastructure works, we can easily troubleshoot that infrastructure and things like that. And it's the exact same thing for containers, basically.

If we know where it exists and we have standards around that, it makes it a lot easier for us to be able to do what we need to do. And really, that's the majority of it. And so we next can say, well, what do we need, right? Because we know what our frontends need, but what do we need with regards to this?

And the simplest way of putting it is, we need simple interfaces that allow us to pull off the shelf deployments for specific service types. Now, we talked about, what was it called again? Back, what's the spotify thing again, sorry?
>> Backstage.
>> Backstage, yeah, we talked about backstage and you might go, this sounds like backstage.

That's because backstage is trying to solve this problem. Backstage is trying to basically say, let's standardize a lot of the things that we do so that we can kinda pull these off of the shelf solutions instead of making new solutions every time. And that's what we need, right?

So we know what our frontends need and our backends need, but we also now know what we need, right? And we can even say, we need a simple way of managing these resources and updating them when changed, right? Outside of that, most everything is iteration, right? It's taking a look at it and saying, okay, well, we need a simple way of making it so that developers can deploy a frontend if they need to.

And then we also need a simple way of managing those resources so that we can. No mention of technology, no mention of, you should do this or you should do that. And as a matter of fact, outside of just giving this technical document more information about parameters and stuff like that, this is what the developer would get, realistically, right?

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