By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Resources
>
Blog
>
Article
A man sitting at a desk working on a computer.
August 18, 2021

DevOps Architecture: What You Need for DevOps to Work

Talking about DevOps architecture may seem strange if you aren't a developer; so in this post, we'll describe what that means.

Talking about DevOps architecture may seem strange if you aren't a developer since they're the ones who usually discuss it. However, every technical group has to think about the architecture they are involved with. So in this post, we will describe what that means and how it can impact every part of your daily routine.

A Synopsis of DevOps

DevOps is a common buzzword right now, but what does it mean? While this isn't a definitive guide, let's review to ensure we're all on the same page. DevOps brings the development groups and operations groups together. In the past, development groups and operations groups usually had two very different ideas about how work gets done.

Developers often completed their work in relative isolation from the rest of the group. Then they came together at some point and tried to merge everything into a single deliverable. This usually meant that there were defined periods of work before merging. Once merging was completed, they had something that would hopefully run in the production environment. This is where a divide was formed. The developers just handed off their work to operations and let them figure out how to make it work. At best they provided some instructions. This created conflicts between groups because they were focused on different outcomes. Developers wanted to create things, but operations were more interested in keeping the lights on than changing the world.

This is why the DevOps movement started gaining steam. Companies desperately need these two groups of people working well together. That way, business objectives can be achieved as reliably and as quickly as possible. The DevOps movement is the set of ideals to make that happen.

DevOps brings the development groups and operations groups together

Now let's move on to DevOps architecture.

What Is DevOps Architecture?

As stated earlier, DevOps architecture isn't just for developers. It's part of every group. The architecture is the basic structure and patterns you follow to do your work. It's important to have some kind of guiding path, especially as you come upon unexpected or unknown things. Architecture is basically a compass that helps guide you through the unknown of the unknowns and helps you make tough decisions.

Good architecture helps you ensure that business objectives can be obtained and that your infrastructure can be as reliable as the business needs it to be. Good architecture is designed to be usable and moldable by the people who need to use it. There are guidelines and safety checks to ensure that all parts of the system are doing what they need to be doing.

Good DevOps architecture ensures that groups are working together as efficiently as possible

Why Should I Care?

The DevOps group has to wade into both the development and the operations world. They have to be aware of what's going on at a high level to ensure that things are running smoothly. Good DevOps architecture ensures that groups are working together as efficiently as possible. This means that developers can deploy as often as they need in a safe and reliable way. It also means that operators know what's going on with the infrastructure and that the capacity is sized correctly.

Good DevOps architecture also helps establish patterns that quickly move ideas from a whiteboard to production. This means that the right tools, patterns, and processes are in place.

Pieces of a Good DevOps Architecture

Now that you have all this in mind, let's look at the general areas that DevOps architecture should touch:

  • Infrastructure and how it's built and maintained
  • Deployment pipelines for each service
  • Testing and security verification
  • Monitoring and analysis of services
  • Developer tools
  • Operational runbooks and processes to respond to infrastructure needs
  • Security procedures and threat responses

The DevOps group needs to think through and discuss all of these areas. A good architecture will help you make day-to-day decisions if it's designed well enough in advance.

Next, let's look at a couple of sections in detail.

Toolchains and Platforms

Part of a good DevOps architecture is the tools and platforms that help achieve whatever needs to be done. These are the lifeblood of the DevOps group. A primary focus is ensuring that delivery pipelines are functioning appropriately and are being utilized by the development group correctly. This means the DevOps group needs to make sure that developers can get their code together, that there are testing protocols, that certain security parameters are met, and finally that an application can be deployed into a production environment. The architecture needs to ensure that these are all working and that they fit with the culture of the company.

Good DevOps architecture means that every tool and platform has its place and that it's continuously reviewed. The one constant in the technology world is change. So making sure that your tools and platforms are still correct is something that needs to be reviewed periodically. Replacing any part of the system can be cumbersome. That's why architecture needs to be carefully thought through ahead of time.

The Cloud

The next big piece to look at in a DevOps architecture is the cloud platform (though you can also use an on-premises system). There is a wide variety of places where you can host the hardware you need, whether you are hosting a single cloud function or have a world-distributed infrastructure hosted in several data centers. Knowing where your hardware is and how to scale that hardware and infrastructure to support your business needs is critical.

You need to be sure that you can run software that meets your requirements and that you can afford it. A good DevOps architecture has guidelines for how it will use the capacity and how to provision new hardware when scaling is necessary.

If you choose a cloud vendor, first find out exactly what they offer and how you can utilize it. Sometimes buying is better than building, especially in DevOps groups. To get to market at the right time, utilizing something that has already been built can be very beneficial.

An Example

Let's say your company uses Amazon Web Services (AWS). You need to know which tools AWS provides that you can use to deploy your software. You need to know how to deploy on AWS and what your toolchain looks like. Getting this right as soon as possible means that you can keep doing things in the future. From there, knowing what services AWS has, where it fits in your mission, and what principles are used to choose your next path is very important.

Documents should demonstrate how and why you came to certain conclusions

How to Document This Architecture?

Now that we have an idea of what DevOps architecture is, how best do we put all of this together? Well, now we come to the boring part: documentation. Documentation is where architecture lives. Documents should demonstrate how and why you came to certain conclusions. A great format for these types of documents is architecture decision records. They give you a standard format to document why and how you came to certain conclusions and what the assumptions were. This is important because those assumptions may change in the future and warrant a change at a higher level.

Conclusion

I hope this article sheds light on what makes up DevOps architecture and what to look for as you travel the DevOps path. Every group has different needs and outcomes, so every group will have a different architecture. This is both OK and desirable. Just make sure you have something to guide you on your journey that will help when you encounter problems you hadn't expected.

This post was written by Erik Lindblom. Erik has been a full stack developer for the last 13 years. During that time, he’s tried to understand everything that’s required to deliver high quality, valuable software. Today, that means using cloud services, microservices techniques, container technologies. Tomorrow? Well, he’s ready to find out.

Ready to get started?

Contact Us

We'd love to learn more about your project and determine how we can help out.