Podcast: Nic Jackson on HashiCorp Product Philosophy in Open Source and Feature Minimization

 

 

 

In this week’s podcast, we speak with Nic Jackson, Developer Advocate, HashiCorp (@sheriffjackson). Nic provides insight into the product and development philosophy of HashiCorp and how it impacts their products and open source components. The last section of the podcast on product feature limitations and how companies go too far is very interesting.

  • HashiCorp Overview and Design Philosophy of their Solutions
  • Company vs Community Open Source Comparison in Terraform
  • Abstractions and Portability Failings
  • Product Features and Doing Too Much

Topic                                                                     Time (Minutes.Seconds)

Introduction                                                         0.0 – 0.53
HashiCorp Overview                                          0.53 – 3.20 (Started with Vagrant)
Design Philosophy of HashiCorp Tools           3.20 – 5.28 (Isolated Tooling)
Neutral Ground w/ Tools                                  5.28 – 7.46 (Open, Integrated Environments)
Engagement Model                                           7.46 – 10.28
Open Source Community Model                     10.28 – 12.56 (Tightly Controlled)
Software for Operators                                      12.56 – 16.30
Terraform De-Coupling                                     16.30 – 25.25 (Company Open Source)
Terraform – Awesome & Horrible                    25.25 – 29.15 (Edges around Terraform)
Portability & Abstraction                                    29.15 – 33.29 (Partial Abstractions Fail)
Industry Moving Fast & Tools are too Young  33.29 – 37.17
Build Set of Tools for Single Purpose               37.17 – 39.55 (Not All Tools Solve Every Problem)
Adopt Tool Knowing It’s Role                             39.55 – 41.45
Constant Workflow Across Platforms               41.45 – 43.25
Wrap-Up                                                                43.25 – END

Podcast Guest
Nic Jackson, Developer Advocate, HashiCorp

Nic Jackson is a developer advocate and polyglot programmer working for HashiCorp, and the author of “Building Microservices in Go” a book which examines the best patterns and practices for building microservices with the Go programming language. In his spare time, Nic coaches and mentors at Coder Dojo, teaches at Women Who Go and GoBridge, speaks and evangelizes good coding practice, process, and technique.

Follow Nic here: Nic’s Blog

HashiConf 2017: Messy yet Effective Hybrid Portability

Last week, I was able to attend the HashiConf 2017 event in my hometown of Austin, Texas.  HashiCorp has a significant following of loyal fans for their platforms and the show reflected their enthusiasm for the HashiCorp clean and functional design aesthetic.  I count the RackN team in that list – we embedded Consul deeply into Digital Rebar v2 and recently announced a cutting edge bare metal Terraform integration (demo video) with Digital Rebar Provision (v3).

Overall, the show was impressively executed.  It was a comfortable size to connect with attendees and most of the attendees were users instead of vendors.  The announcements at the show were also notable.  HashiCorp announced enterprise versions of all their popular platforms including Consul, Vault, Nomad and Terraform.  For their enterprise versions include a cross-cutting service, Sentinel, that provides a policy engine to help enforce corporate governance.

Since all the tools are open source, creating an enterprise version can cause angst in the community.  I felt that they handled the introduction well and the additions were well received.  Typically, governance controls are a good demarcation for Enterprise features.

I was particularly impressed with the breadth and depth of Terraform use discussed at the event.  Terraform is enjoying broad adoption as a cluster builder so it was not surprising to see it featured on many talks.  The primary benefits highlighted were cloud portability and infrastructure as code.  

This was surprising to me because Terraform plans are not actually cloud agnostic – they have to be coded to match the resources exposed by the target.

When I asked people about this the answer was simple: the Terraform format itself provides sufficient abstraction.  The benefit of having a single tool and format for multiple infrastructure created very effective portability.

Except the lack of cloud abstractions also drove a messy pattern that I saw in multiple sessions.  Many companies have written custom (“soon to be open sourced”™) Terraform plan generators in their own custom markup languages.  That’s right – there’s an emerging, snowflaked Terraform generator pattern.  I completely understand the motivation to build this layer; however, it strikes me as an anti-pattern.

Infrastructure portability (aka hybrid) is a both universal goal and frighteningly complex.  Clearly, Terraform is a step in the right direction, but it’s only a step.  At HashiConf, I enjoyed watching companies trying take that next step with varying degrees of success.  Let’s get some popcorn and see how it turns out!

Until then, check out our Digital Rebar Terraform provider.  It will make your physical infrastructure “cloud equivalent” so you can run similar plans between cloud and metal.

For more information on the Digital Rebar Terraform provider, listen to this recent podcast.