Why Devs Care About IP Addressing

Self-Service Matters to Developers

So often we network vendors only talk about how ops are going to implement things and we forget to understand the context by which other teams will be impacted. While there are many teams affected by how IP information and DNS are managed, I want to concentrate on why this matters to developers. Not DevOps, but the folks actually creating your internal and external apps and services on-premises or in multicloud environments.

Why Would Devs Use IP Information?

When developers are creating new or updated apps, those apps usually have multiple tiers. To simplify, we usually talk about the Data Base Tier, Application Tier, and Web Tier.

Now, if you’re a network engineer or anyone on the operations side, you probably noticed there are multiple things missing from this picture. There are usually several tiers that come together to make an application work, DNS being a very important piece of this application dependency map.

Once upon a time it may have been more acceptable to use static IP addresses directly within code. However now there’s a big push to use URLs or some sort of human readable name instead. There are a few reasons for this, but obviously depending on a manual change of IP address within code can make for a troubleshooting nightmare when operations are looking for a problem with a service or app. Using a URL within code, instead of an IP, can help ease migration to new IPs, or even help move from IPv4 to IPv6.

Why it Matters

As we see more and more servers, virtual machines, containers, and micro-services within our environments, it’s actually harder to generate human readable names that make sense as to what that service/micro-service is providing. There is actually an extra step that comes with creating a name and then also registering that name with DNS. When we had three to five VMs providing a service it wasn’t as big of a deal, but when we think about how many dozens of containers we might have for just one application, you can see where this becomes a problem.

Often developers will use static IPs as they create and test new apps or new versions of apps, just to be able to get it done. This may be forgotten as these apps move to production. The idea of switching to a URL registered with DNS may also not get prioritized as deadlines become imminent, especially if it takes days or weeks to create the ticket and then wait for a DNS name. Again, imagine if there were several containers and the amount of tickets created to get DNS records created. So, how can operations folks make this more attractive to developers?

Make the Path Less Resistant

Through network management with the use of abstraction and automation, network engineers can not only help developers more quickly, but also create a more sustainable network. Abstraction in this case, lets you see your entire DNS, DHCP, and IPAM (DDI) environment. It lets you easily identify which subnets are being overextended, if you’re going to have an IP conflicts, and easily create a workflow of creating the proper DNS records.

That DDI solution should also offer an API so that self-service is possible. If a developer or application owner can go in and request a DNS entry on their own to trigger an automated workflow, this can result in the wait time going from weeks to hours or even minutes. Thereby making this the best case for both developers and operations.

What Do You Get with Micetro?

Micetro, by Men&Mice, is a sustainable network management solution that gives you view and control of your entire DDI environment. It offers an API-first methodology, which means anything you can do in the GUI, you can also do in the API. Going beyond abstraction and automation, you’ll also gain the ability to log who made changes to you DNS, DHCP, and IP information. I also wanted to mention the DNS Workflow capability here. Because access control is so important, we’ve built in the ability to have request permissions to make changes to DNS. Meaning, there will be an approver who will allow the request to go through. In the meantime, that IP address is held so that no one else may use it. You may also build up several requests, like in the case of a multi container implementation, so that everything is approved within the same change management window. Again, reducing the wait time as well as making sure the network is up and your users are having a great experience.

If you’d like more information on how to make your developers lives easier, sign up for a live demo here https://menandmice.com/live-demo