The plans for a 'spiritual successor' to the Vagrant devops tool are ambitious, but it might prove to be a difficult sell for existing users In the world of devops tools, Vagrant is widely used to create reproducible VM environments for development and testing. But with development pivoting away from VMs and toward containers, Vagrant creator Mitchell Hashimoto and his company, HashiCorp, have decided a successor is in order. Otto, as the new project is called, automates the way application environments are created for both development and production use. It’s more a complement to Vagrant than a successor, and questions are still arising about its role in a world where Vagrant may be hard to displace. Vagrant, and then some Otto has been devised for three purposes: Create application development environments without needing to spell them out explicitly in a Vagrantfile, from the machine level on up Deploy apps directly to production from a development environment, while accommodating dissimilarities between those environments Do all of this in a way that uses container-based microservices rather than VMs as a unit of production Otto uses appfiles, akin to Vagrant’s vagrantfiles, to say what a given application needs. It describes the language, dependencies, and software versioning in use, but it doesn’t automatically include requirements associated with the host machine (OS, memory, and so on). An eWeek article about Otto quoted Armon Dadgar, co-founder and CTO of HashiCorp, as saying that Vagrant is a successor “in a spiritual sense and not a technological one.” Since Otto leverages Vagrant and other HashiCorp tools (namely, Packer and Terraform), it can be considered an abstraction layer for all of those applications at once. Another page at the Otto project’s website says, “Vagrant is a great way to test configuration management, obscure operating systems, etc. These use cases will not go away. Due to the above, we’re committed to continuing to improve Vagrant and releasing new versions of Vagrant for years to come. But for the everyday developer, Otto should replace Vagrant over time.” Magical, but also opinionated Otto provides default assumptions about how to set up an environment — a potentially divisive approach. “When you tell Otto the type of application you’re developing,” says the above link, “Otto knows how to develop and deploy that application using industry best practices…. Over time, Otto will get smarter and adopt new best practices to improve your environments.” Otto’s opinionated default assumptions (euphemistically referred to by Hashimoto as “magic”) can be overridden, but it’s a philosophical break from Vagrant’s attitude of being as explicit as possible about system setup. A thread at Hacker News introducing Otto, with an introductory comment by Hashimoto himself, drew mixed reactions, many of them concerning the philosophy of the system or how Vagrant is solution enough for many of them. “It’s pretty depressing to see HashiCorp adding more layers to a system that already has way too much accidental complexity,” wrote one commenter. Another commenter, however, liked the idea of having a way to enforce best practices: “I don’t think I can underestimate just how much I don’t want to have to stay up to date with all the various best practices for deployments. I have zero interest in that and it is currently a fairly expensive problem to fix for many.” Otto is in the very early stages. Its plug-in architecture, the main avenue to extends its functionality, isn’t even exposed for use yet. Should Vagrant be subsumed into Otto over the long term, the plan could backfire if the use case for Vagrant outstrips that of Otto. DevopsDevelopment Tools