Migrating Route53 DNS records to Azure

Berislav Babic — Wed, 29 Jun 2022 11:14:42 +0000

Recently I've been notified that we need to move our operations away from AWS to Azure. I'll keep my feelings about that decision to myself for now, but one of the steps I found interesting (and never did before) was migrating the DNS provider from AWS Route 53 to Azure DNS Zone.

There are steps we need to take before we export the AWS DNS records. Since AWS has a lot of built in services, there are DNS records that aren't proper DNS records. They works as ones, but they are A type records, pointing to various AWS services. Those services can be load balancers, cloudfront distributions, S3 static websites and other services you aliased under your domain.

Cleaning up these records is pretty easy. You have to edit the mappings to be readable by any other DNS service. In these cases you will have to create CNAME records for those AWS aliases. ALB/ELB and CloudFront mappings stay the same but you have to change them from A records to CNAME and update the values. The mappings are in the table below:

DNS entry before	DNS entry after
subdomain.acme.inc	subdomain.acme.inc.s3-website.eu-central-1.amazonaws.com

Be sure to set the TTL (Time to live) on these entries to a value you feel comfortable (300 seconds should be okay for DNS records).

After you cleaned up your Route53 from AWS specific aliases, you can export the bind file with this awesome cli53 tool.

After you have installed the tool and set the AWS credentials, you can run it with: cli53 export acme.inc > acme.inc.txt. This will export all your domain's DNS records into a BIND file format, readable by other DNS services.

Next thing we need to set up is the Azure CLI following the installation instructions for your OS. After you have set it up and authenticated, you can create a new DNS zone using this CLI.

az network dns zone import -g resourceGroup -n acme.inc -f acme.inc.txt

The whole procedure for creating a resource group and importing/verifying the DNS at Azure is described here

After you import all your DNS records, you have to verify that they resolve to the correct place. You will need to fetch your domain's NS records with
az network dns record-set ns list -g resourceGroup -z acme.inc --output json
and take one of the nsRecords > nsdname values to test using nslookup

$> nslookup www.acme.inc ns1-03.azure-dns.com

  Server: ns1-03.azure-dns.com
  Address:  40.90.4.1

  Name: www.acme.inc
  Addresses:  134.170.185.46
  134.170.188.221

You should test multiple entries to make sure they get resolved to the correct place.

After you have verified the records resolve properly, you can update the DNS delegation in your domain registrar. Since you have the name servers you fetched in the previous step, you can use those in the specific domain registrar you are using. Here is an example of how it looks like on the domain.com registrar. After they have been propagated (give it 5-10 minutes), you can verify them in your DNS Zone page on Azure.

Resources:

The stack you use to build your next app is irrelevant

Berislav Babic — Wed, 29 Jun 2022 09:11:14 +0000

How to choose the best stack for your app

Rash words to begin the article, but if you think about it, it's hard to deny the fact that it doesn't matter what tech we use to build the app. What matters more is solving the needs of your customers and getting paid for it enough that you can sustain the costs of your app.

I understand that its hard to choose the correct one today. There are a lot of established frameworks and out of the box solutions alongside the new and flashy frameworks and no-code approaches. All will work similar (or won't) depending on what you decide to build with it. You can spin off a very profitable web app with Airtable and automation apps. If you want to build a more complex web app like I usually do, you will start looking at frameworks to help you on your way.

Most frameworks are very similar because they all borrow ideas and technology from each other. The difference lies in their underlying programming language they and what the majority of the community is using them for. I'm going to focus on basic and semi complex CRUD apps here, which have been my bread and butter for the better part of the past 2 decades. As I go further, I want to dumb down the development stack as much as possible. I'm not perfect here, my friends and ex coworkers will say that I left some wild heritage behind me, but I guess it's what growth looks like. Experimenting with different thing and figuring out what works for you.

The main mistake we make is trying to replicate what FAANG is doing. Regardless whether it's in development, operations and sometimes even sales and marketing. Let me be completely honest, it makes no sense comparing ourselves with those companies. I know everyone can dream, but it's best to leave that unicorn dream behind us and do the best we can do serve our customers. The quicker we realise that, quicker we can start implementing stuff that solves real problems.

Our customers don't care much whether we use React or Vue.js for our frontend. You can even write an app using Backbone.js (Those who remember this one shoot me an email) and be super successful with it. What you should focus is to reduce the complexity as much as possible so you will achieve the following goals:

Hiring is much easier if you hire for one thing. It's hard to find someone who is an expert in both Rails and Ember.js or Django and Vue.js, or Laravel and React. And if we add some esoteric database + ORM to the picture, you introduce too much complexity in your stack. Everyone already has to know about HTML/CSS and at least basic JavaScript to do web applications.
Less complexity means you can deliver features faster with less bugs. Okay, the amount of bugs is dependent on your engineering and testing capabilities, but if less things can go wrong it will reduce the possibility of bugs.
Every framework has its own deployment guidelines and best practices. If you mix up a couple of them in your stack, you have to figure out your own deployment strategy instead of serving your customers' needs.
Testing one tightly coupled and integrated thing is much easier than testing 3 loosely coupled things.
Server rendered apps can be just as fast and even faster than single page apps. They can also be easier to secure. Did I already mention that you can develop them faster?

The last point is what I'm aiming at here. Server rendered apps are enough for most of the stuff we are building now. You don't need micro services or single page applications because you can always live without the additional complexity. You want the "boring stack" - something proven, battle tested and known to work. You want Wordpress, Laravel, Django and my favourite, Rails. There might be a JS solution available for you in the likes of Next.js if you prefer JS as your language of choice.

Now I'm not against experimenting with new and flashy technologies, or using them when they become necessary. What I'm advocating here is being prudent with the choice of technology you build your app with. Scala was once a very popular language, so was Clojure and now I don't even hear them mentioned. While Python, PHP and Ruby are still alive and doing very well. Not on the top of the lists, but not forgotten like those other "killer languages". I like Clojure because of its lispiness, and I'm sad I never got to use it on a project.

Languages and frameworks come and go, but the good ones stick. If you are a Microsoft fan, Asp.Net MVC is a good choice, or Spring MVC in Java, whichever makes you happy. If you don't over-engineer it when you start, it's gonna be easier down the line.

If you ever upgraded one of your frameworks to a new major version, you know how hard it can get. Do you want to stick your team (or yourself in the start) with having to manage 2 or more frameworks. Think how hard it will be to upgrade 2 or 3 of them (sometimes at the same time). Just keeping on top of security advisories can be overwhelming.

Let's end this one remembering the spirit of KISS and YAGNI, and using those as a guideline in choosing our stack.

The Ops Community ⚙️: Berislav Babic

Migrating Route53 DNS records to Azure

The stack you use to build your next app is irrelevant