Oh where, oh where have my services gone?

As mentioned previously, one of the biggest problems related to the implementation of private and public cloud infrastructures is the fluidity of the network. Back in my day, any changes to the network required a myriad of steps. Let's focus on the simple need to deploy a new application. Let's assume that our application has already been written and tested:

1. Review the machine requirements requested.
2. Obtain the number of quotes for the requested machine(s).
3. Submit a purchase requisition.
4. Justify the purchase request with a number of management layers depending on cost.
5. Submit the purchase order to the vendor.
6. Wait for the machines to arrive.
7. Decide what IP address we're going to allocate.
8. Vote on what inventive name we'll call the machine(s).
9. Determine where in the warm and loud server room we're going to mount the machine(s).
10. Figure out how we're going to connect the machine(s).
11. Once the machine arrives, install the actual hardware and plug it in.
12. Argue with facilities about where to put the cardboard and leftover packing materials.
13. Configure the machine with the allocated network parameters (address and name).
14. Troubleshoot routing and address resolution tables.
15. Provide the application team with the address and credentials for the server.

Does any of this sound familiar? Each of these steps required human discussion (which is inherently unreliable) and usually paperwork and emails that got lost in the shuffle. Eventually, it got better with ticketing systems, but instead of getting buried in emails, we got buried in tickets that took days, weeks, and sometimes months to process. If our services needed to move to different servers or different areas of the network, we would have to start this entire process again. Now, as we've migrated toward more automation in the private and public clouds, let's look at how we've improved:

1. Review the machine requirements requested.
2. Identify what virtual network it needs to live in.
3. Execute the appropriate code modules to deploy the infrastructure.
4. Troubleshoot connectivity problems.
5. Provide the application team with the address and credentials for the server.

So many steps have disappeared, and the entire process of acquiring and deploying machines for our applications and services has been drastically simplified! However, the law of unintended consequences has not been eliminated. If you noticed, along with the elimination of cabling and mounting the hardware, we have also lost a lot of control surrounding the addressing of the devices. Of course, we can stipulate in what network our application or services should reside, but as we introduce new versions of the application, expand the application into other regions, or suffer a service loss and have to redeploy, the last thing we want to deal with is allocating and assigning addresses. But Rob, if I don't have an address, how do I find my service? Well, how many phone numbers do you remember now? You're not calling a number; you're calling a person (or sometimes an automated machine).

With Consul clients distributed throughout the network, tracking and monitoring your services, you don't need to know the addresses anymore. Don't worry about load balancers and firewalls, we'll get to that later. When the Consul service client is configured, it not only knows the address of its own machine but also recognizes what applications are running on the server through a set of intelligent health checks. These checks can be anything from a simple port check to a customized script to make sure the application is not just hearing but is actually listening (there is a difference). Once the server cluster is aware of the healthy application, and its location, then any application that can utilize the Domain Name Service (or DNS – you use this every time you use a web browser) can discover the application. There are other ways to share this information as well, but we'll discuss those later.

Figure 1.4 – Find your migratory services

As we've seen, the evolution of our network infrastructure has produced some amazing benefits when it comes to the management and the deployment velocity of the infrastructure. However, it has also introduced some complexity and perhaps some unwelcome variability, but with Consul service discovery, we're able to embrace those changes without trying to figure out who moved my cheese. So now that we know where our services are, what do we do next?