What’s Next?

A pairing server is easy to connect to for both parties, it’s reproducible, and it’s more secure because it eliminates the need for one of the partners to log directly into the other partner’s machine.

You won’t be sharing a browser, but both partners can point their respective browsers to the same running server. You can even use NX on the pairing server, as you learned in Chapter 4, ​Collaborating with Shared Screens​, and add its setup to your Puppet scripts. But we’ll leave that step as an exercise for you to do on your own.

As with our proxy server, there is nothing unique about Amazon’s cloud platform when it comes to building a pairing server. Most of the virtual private server alternatives mentioned in Chapter 3, ​Using the Cloud to Connect​, can be used to create a pairing server. But there are some other tools that are unique to building this kind of environment:

Packer^[75]

A tool for creating identical machine images for multiple platforms from a single source configuration. It automates the creation of any type of machine—even Windows. It can be used to build images for platforms including Amazon EC2, DigitalOcean,^[76] VirtualBox, and VMware.^[77]

Chef ^[78]

Like Puppet, Chef is a configuration-management framework that can be used with Vagrant. The main advantage and disadvantage of Chef is that its syntax is based on the Ruby language. This is helpful for developers who already know Ruby, but it often encumbers those who don’t.

Unfortunately, most pairing servers limit us to terminal-based editors, which can leave much to be desired for some programmers. In the next chapter, you’ll learn how to use a more robust integrated development environment (IDE) for remote pairing.