All or Nothing: Why Partial Automation Does Not Work

As we build out cloud applications and networks, we need to change the way we deliver and manage IP addresses. Many of the tools we currently use were designed for the good old days, when we had one or two, or maybe tens of servers to support a single application- a server was deployed once and it sat in the datacenter for years.

That’s all changed. We’re now deploying hundreds, even thousands, of virtual servers; taking advantage of the speed of virtual infrastructures to change networks on the fly, adding and removing servers as we respond to demand. Need a dozen new web servers in Dubai to cope with a spike in demand? Click, and they’re there.

We’re also changing the way we build applications, using containers to wrap services for rapid deployment. Change your code, and you change the container, deploying a new one. Instead of just deploying one part of an application, we’re also now redeploying entire virtual infrastructures.

The scale of the cloud and its flexibility make it impossible for people to manage- we’re just not fast enough, and there aren’t enough of us. That leaves only one option: we must automate. This means automating the delivery of IP addresses and building DNS entries, bringing together DHCP, DNS, and IPAM as DDI. See the graph below.

Why we automate

Automation is key to the successful delivery of all aspects of a cloud infrastructure, using both public and private clouds. There are three key reasons for using cloud automation, and for automating DDI services:

• It saves time. By automating the different steps needed to deploy IP addresses you can save time and deliver to the market quicker.
• It reduces the risk of human errors, as complex manual processes (which can have a high risk of configuration errors) are being replaced by DDI.
• It simplifies removing IP information, allowing resources used for a virtual environment to be used for something else. You can free up resources for other apps that need to be deployed.

How we automate

Building an automated cloud means deep integration between all your management tooling, from your self-service portal to your configuration management database, and on to your orchestration and deployment tooling – including your DDI services. When you need an application or a service it needs to be ready as quickly as possible. This means deploying an image and configuring it as soon as it’s requested – once it’s ready to go it must not conflict with the rest of the system.

With security and data protection as key elements of any cloud service, you can’t make a mistake. Having automated DNS configuration is an essential part of ensuring this, as any DNS and associated IP deployment and assignment need to be in sync with what is deployed. DNS is the map of our application.

That goes further when we look at managing “born in the cloud” applications that take advantage of virtual infrastructures and containers. When we make a change to one of these applications we deploy a whole new infrastructure; so we need to be able to manage its IP addresses and that of the previous release in case we need to quickly switch back to a known release after a failure.

Deprovisioning is as important as provisioning; we need to scale up and down, making it important to recover free IP address and DNS names for reuse, either in this or another application. With cloud services billing for resources no matter whether they’re used or not, there’s a cost implication in not freeing up resources quickly. Once IP addresses have been returned to the pool, virtual servers can safely be deleted – all part of an automated process.

Automation for the future

As we move to more cloud-focused architectures, like those based around containers and microservices, automation becomes increasingly important. We will need to have rapid automated scaling, and at the same time the ability to manage the IP addresses of new services, and deliver them to load-balancing services and other front-end networking systems.

Similarly, many of the newer development patterns needed for services at scale require automated IP address handling. If you’re using the Actor/message pattern that’s becoming increasingly important in IoT and in massively scalable applications, each service element must have a registered address that can be used to deliver messages – so if a message is sent to a service that’s not running, data can be lost. Similarly, if a service is running, but not registered correctly, resources can be wasted.

Partial automation does not work – it’s all or nothing