A development environment of ones own

A development environment of ones own

By Andrew Burrow

Vagrant is a great tool that has been widely adopted by developers to quickly create isolated development environments. The question is what it can do for middleware integrators?

What does a tool like Vagrant provide a developer? A single Vagrantfile describes one or more virtual machines, including the operating system and network connections. When the developer calls vagrant up, Vagrant provides the virtual machine(s), and then calls another tool like Chef, Puppet, or Ansible to provision the new environment with software. In this way, a team can easily share a description of a development environment, and be sure that everyone has access to their own isolated, but identical, development environment.

However, reproducible development environments are not enough. Another important consideration is parity between development and production environments. In The 12 Factor App, Adam Wiggins explains the importance of closing this gap. He calls out Vagrant as assisting developers to “run local environments which closely approximate production environments”. To return to our question of what a tool like Vagrant can do for middleware integrators, we must consider the ways that development and production environments diverge.

A development environment provisioned on a workstation is probably insufficient for a middleware integrator. To see why, note that development and production environments can diverge in at least 3 distinct ways: behavior, data, and topology. Vagrant solves the first case. There is no need to suffer behavioural differences caused by substituting lightweight local services for the actual production services. This is the argument made by Adam. The second case concerns injecting test data into the development environment: a subject we will leave to an expert. The third case is less easy to solve within the constraints of a single workstation, but of special importance to the middleware integrator.

Typically, a production environment distinguishes a greater number of hosts and connects these with a different network structure. Namely, the development environment has a different topology from the production environment. On the production side, this is a consequence of design for availability, scalability, and security. On the development side, this is a consequence of limited host resources, and simplification. For example, a development environment might use a single virtual machine to host several backing stores, where the production environment would use a cluster behind a load balancer for each.

There are other reasons why topologies diverge. The software defined networks of infrastructure as a service (IaaS) providers like Amazon Web Services (AWS) are different in composition and structure than those built directly on hardware. See Practical VPC Design for a run down on the AWS case. Likewise, the container management systems emerging around Docker introduce new considerations.

The reason a development environment provisioned on a workstation is probably insufficient for a middleware integrator is that topology matters to the integrator. Since the topology of the production environment is seldom reproduced except in shared environments, middleware integrators lose the opportunity to work in parallel in isolated development environments. The challenge is to sufficiently automate the creation of production-like environments to allow integrators the same advantage. For the reasons given above, this will not be through lightweight tools like Vagrant, but only by realising infrastructure as code at production-like environments. This matters, because as we head toward microservices, everyone is becoming an integrator.

Subscribe to the Syntegrity Solutions newsletter here.

Have a question?