Hashicorp held its first ever user conference, HashiConf 2015, in Portland, Oregon, in September, and it sold out in six weeks.
During the conference, Mitchell joined The New Stack Founder Alex Williams, Research Director Donnie Berkholz of 451 Research, and Kubernetes guru Kelsey Hightower to discuss HashiCorp’s announcements from the event on this episode of The New Stack Analysts.
Listen to all TNS podcasts on Simplecast.
This podcast is also available on YouTube.
The talk delved immediately into Hashicorp’s tools, such as Nomad, a distributed, highly available cluster manager and scheduler designed for microservices and batch workloads.
“The big thing we’ve done is to eliminate all the dependencies,” Hashimoto said. “It’s a single binary and it’s the only thing you need to get started. You just run one binary and you can immediately start sending jobs to it.”
“It’s built on everything we learned from Serf and Consul — projects that have existed in production for over a year now,” he said. Both tools offer service-discovery capabilities. Hashimoto was particularly enthused about the network tomography features added to Serf.
“We actually have that available in the scheduler and so you’ll be able to do things like, ‘I want this job to be close to other things,’ and we can figure that out really efficiently,” Mitchell explained. “With a lot of other schedulers you need to program in things like ‘these are on the same rack’ or ‘these are close to each other,’ and with the tomography stuff we actually have the real data.”
The discussion moved on to Otto, which HashiCorp describes as the successor to Vagrant, the development environment creation tool which led to HashiCorp’s formation.
“We took a look at how Vagrant could be improved. I think we made a really good Ops experience, and the developer experience has been good, but we haven’t focused on it in quite a while, so we decided to look back and focus on that, and to build it better,” Mitchell said. “We think, over time, for the majority of developers Otto will replace Vagrant, but Vagrant will retain a lot of use cases that we’re not targeting with Otto.”
“Why didn’t you just call it Vagrant 2.0?” Berkholz asked.
“There will be a Vagrant 2.0,” Mitchell responded. “It’s just a fundamentally different tool: different configuration format, different commands.”
“We’re going to continue to release Vagrant releases for the next many years,” he continued. “Otto builds on top of Vagrant a lot right now. Pieces of that were going to slowly get replaced natively into Otto, but for now there’s a lot of interaction there. I think it’s going to be a multi-year process.”
“Most companies are really afraid to disrupt themselves,” Hightower observed. “Instead of standing back and letting someone build a better Vagrant, they do it first. And that’s risky, because then you get these questions of, ‘should I even use Vagrant anymore?’ And you’ve gotta field those, but it seems like they’re not afraid to attack it straight up.”
“If you were to build Vagrant today you would probably end up building something like Otto,” Hightower said. “It’s nice to see they’re still thinking and not saying, ‘Vagrant’s popular, let’s see how far we can milk it.’ That’s a pretty ambitious step and they’re not afraid to pull it off, so I’m hats-off to it.”
For more episodes, check out the podcast section of The New Stack.
Feature image via Pixabay.