Standards can often times feel like a hinderance to teams when they are developing software. When trying to deliver something to the market quickly, it’s common to forgo best practices in an effort to achieve goals quicker. This attitude is actually counter productive, however, and by taking a different attitude towards guidelines teams can actually achieve results faster.

Let’s start with an example

I’ve recently been working on moving my domains from one provider to another and I’ve decided that I want to host as much as I can in my GCP account. Domain transfers aside, I plan to hold everything in my google cloud account (domains can’t be transferred into Cloud Domains in GCP). My journey to moving all my records began by jumping into my IaC repository and writing up some scripts to build up DNS records inside of CloudDNS when I hit a minor stumbling block: the way DNS records are allocated in GCP don’t match how my existing provider exports them.

Mismatched Standards

Now this is where standards actually start to come into play. There is an established standard for what are called Zone Files defined in RFC 1035 by the IETF. The exports I received from my existing provider gave me zone files that matched this standard, so I was good on that end. This is where I had a choice to make, however, because the allocation of DNS records don’t really match the standard. I can’t write a script that just “gives” GCP my zone file and then CloudDNS is smart enough to ingest it automatically for me. CloudDNS wants me to allocate each record individually.

Fork in the Road

Here we have a fork in the road. We could adopt the new GCP way of allocating records, which seems faster on the face of it, especially if you’ve already dealt with CloudDNS before. However, this is where leveraging standards comes into play. What if, instead, we wrote our IaC scripts so that they could recognize any zone file and it knew how to translate that into GCP CloudDNS language? As it turns out, that approach not only upholds the IETF standards, but it also helped me migrate all my zone files faster. I was able to write the concept one time, and then reuse it over and over again.

Designing a Reusable Solution

When you build solutions around standards, it’s a lot easier to reuse them. The solution I devised allows me to drop in any zone file I want into a folder, and my CDKTF scripts will automatically pick them up and allocate CloudDNS for them. Let’s look at how it works.

First we have to grab all the zone files that are in the repo and iterate through them

Now we need to take the zone file and parse it, so we can use all the information inside it.

From here we need to essentially do two things. We need to create a Managed Zone in CloudDNS to hold all of our records. That’s handled by the construct I made here:

And finally we need to go through all the parsed records from the zone file and allocate them to the managed zone we just made:

You can find the full example in my how to cloud repository

A Little can go a Long Way

So why bother building a solution like this instead of just allocated the records you know you need? Well, now I can drop in any zone file from any domain I manage (of which there are more than handful), and my IaC knows how to handle all of them. I don’t need to keep writing code for every domain I own or manage. After the third zone file that I migrated I was already easily saving myself time with this approach. That’s a huge win.

Change how you Think

And this type of thinking works in so many different areas in so many different ways. Standards, by their nature, allow you to create repeatable solutions around them. Instead of trying to create a customized solution, design a way to take advantage of what is already established. You will find most of the time what you are developing should align to the standards that are out there. And in the event that it doesn’t work out, this mentality will clarify for you and your team where standards and best practices fell short for you.

When it Doesn’t Work

So even if it doesn’t work, you at least know why. I would even add to that, you now have an opportunity to grow the standards that you operate in. If you truly find a use case that doesn’t fit, then it’s entirely possible that a new standard should arise, or an existing one should be augmented to meet the need you discovered.