Podcast – Eric Wright talks DevOpsishFullStackishness and Woke IT

 

 

 

 

 

Joining us this week is Eric Wright, Director Technical Marketing/Evangelist at Turbonomic and podcaster/evangelist at Discoposse.com talking open source.

Highlights:

  • RANT on cloud terminology w/ new terms “DevOpsishFullStackishness” & “Woke IT”
  • Open source communities, vendors, and value of users
  • Edge Computing – definition, Turbonomic Role in cloud/edge
  • Edge and Cloud are Hybrid – embrace multiple paradigms including legacy
  • Discussion of Go language and RackN usage

Topic                                                                                  Time (Minutes.Seconds)

Introduction                                                                   0.0 – 2.30
Questioning in Open Source                                      2.30 – 3.38 (Rob’s Skill)
RANT on Cloud Terminology                                     3.38 – 14.30 (Hybrid IT is legitimate)
Software Defined Terminology                                 14.30 – 15.55 (Trademark Tech Terms)
Open Source Community & Vendors                       15.55 – 20.30
Using Open Source as Valuable as Contribute      20.30 – 24.30
Open Source Project Scope Creep                          24.30 – 26.13
Edge Computing                                                         26.13 – 28.57
Turbonomic Role in Edge                                           28.57 – 32.53 (Workload Automation)
Dynamic Mapping of Workloads at Edge                32.53 – 34.39
Sounds like Hybrid?                                                     34.39 – 42.31 (RackN does PXE in Go)
Ruby Containers into Go on a Switch                       42.31 – 46.35 (Language Snobs)
Wrap Up                                                                        46.35 – END

 

 

Podcast Guest: Eric Wright, Director Technical Marketing/Evangelist at Turbonomic

Before joining Turbonomic, Eric Wright served as a systems architect at Raymond James in Toronto. As a result of his work, Eric was named a VMware vExpert and Cisco Champion with a background in virtualization, OpenStack, business continuity, PowerShell scripting and systems automation. He’s worked in many industries, including financial services, health services and engineering firms. As the author behind DiscoPosse.com, a technology and virtualization blog, Eric is also a regular contributor to community-driven technology groups such as the Pluralsight Author, the leading provider of online training for tech and creative professionals. Eric’s latest course is “Introduction to OpenStack” you can check it out at pluralsight.com.

Open Source, Operators, and DevOps Come Together for Data Center Automation

Running data centers is a complex challenge as the typical environment consists of multiple hardware platforms, operating systems, and processes to manage. Operators face daily “fire drills” to keep the machines running while simultaneously trying to expand service offerings and learn new technologies. The adoption of virtualization and cloud has not simplified anything for IT teams and has only made their job more complicated.

Our founders have years of experience working on deploying and operating large, complex data center environments and clouds. They are also well versed in the open source community space and see the merger of community with operations leading to a better way forward for data center management.

We are building an operators community sharing best practices and code to reuse across work sites to fully automate data centers. Working together operators can solve operational challenges for not just their infrastructure, but also find common patterns to leverage across a broad set of architectures.

Community is a powerful force in the software industry and there is no reason why those concepts cannot be leveraged by operators and DevOps teams to completely change the ROI of running a data center. RackN is founded on this belief that working together we can transform data center management via automation and physical ops.

Join us today to help build the future of data center automation and provisioning technology.

2017 SRE & DevOps Influencers

Seems fitting to start 2018 by finally posting this list I started in May while working on my DevOpsDays “SRE vs DevOps” presentation, I pulled an SRE and DevOps reading list from some of my favorite authors.  I quickly realized that the actual influencer list needed to be expanded some – additional and suggestions welcome.  A list like this is never complete.

Offered WITHOUT ordering… I’m sorry if I missed someone!  I’ll make it up by podcasting with them!

SRE & DevOps Focused

Developer, Open Source & Social Connectors

Completely non-technical, but have to shout out to my hard working author friends Heidi Joy Treadway @heiditretheway and Jennifer Willis @jenwillis.

Podcast: Digital Rebar Tech Discussion on Patch APIs, Swagger, and Integrations

In this week’s L8ist Sh9y Podcast, we bring on the Digital Rebar team at RackN to discuss several issues they have working on over the past few months:

  • Patch Rest APIs and CLI : Scaling Challenges Require Patch
  • Swagger API History and Changes : No CLI Generation
  • Integrations to Existing Tools up the Stack

Topic                                                   Time (Minutes.Seconds)

Introduction                                              0.0 – 0.42
Intro to Digital Rebar Project                 0.42 – 1.58
Patch in Rest APIs                                    1.58 – 4.02  (Reference: JsonPatch.com)
Why not use PUT?                                  4.02 – 4.53
CLI use Reference Objects                    4.53 – 6.28
Examples of How Use This                    6.28 – 10.55
Patch Synchronous Question                10.55 – 12.32
Swagger Built into API                            12.32 – 15.44  (Reference: https://swagger.io/)
Operator view of CLI w/out Swagger  15.44 – 18.30
2 Key Points on Swagger Change         18.30 – 20.22
Integration to Other Systems                 20.22 – 28.13   (Grumpy Operators Syndrome)
Learn More About Digital Rebar            28.13 – END      (Digital Rebar Online Meetup Community)

Guest Podcast Attendees

  • Greg Althaus, Co-Founder, CTO RackN
  • Victor Lowther, Sr. Software Engineering, RackN
  • Shane Gibson, Sr. Architect and Community Evangelist, RackN

Digital Rebar is the open, fast and simple data center provisioning and control scaffolding designed with a cloud native architecture. Sponsored by RackN, this community is building an extensible stand-alone DCHP/PXE/IPXE service with minimal overhead offering a quick 5 minutes to provisioning solution.

Community Mission: Embrace the Heterogeneous Nature of Data Center Operations while Eliminating Complexity and Manual Steps.

Digital Rebar Provision: Community Content Demos

Shane Gibson, Community Evangelist takes the viewer on a tour of the Digital Rebar Provision tool running all the freely open and available community content packages. The tour consists of both CLI and Web UI options allowing the user to select a platform they are most comfortable with.

 

Video Activities Start Time (Minutes.Seconds)
Introduction / Setup 0.43
Login to Existing Node 1.30
Install DR Provision from Tip 1.48
Start Server / Load Community ISOs 3.00
What Community Content is 4.00
“Contents Show” 4.23
What Bootenvs in a Content Pack? 6.12
Ubuntu Distribution Components 8.25
Templates in Ubuntu 11.22
Templates in Detail (CLI) 12.30
Template in Details (WebUI) 14.12
Clone a Read-Only Template (WebUI) 15.35
Content Page on WebUI 16.25
Root Access Keys (WebUI) 17.54
Root Access Keys (CLI) 18.50
Edit your own Content Pack 19.22
Set the Preferences to use Bootenvs 20.35
Adding Subnet 21.06
Packet Plugin (for Packet.net) 22.25
DRP Data Directory 23.50
TFTP Boot Directory 24.34
Swagger UI API 25.15

Additional Information:

OpenStack Boston Day 1 Notes

Contrary to pundit expectations, OpenStack did not roll over and die during the keynotes yesterday.

20170508_093339

In my 2011 Boston Summit shirt.

In fact, I saw the signs of a maturing project seeing real use and adoption. More critically, OpenStack leadership started the event with an acknowledgement of being part of, not owning, the vibrant open infrastructure community.

Continued Growth in Core Areas

Practical reasons for running dedicated infrastructure (compliance, control and cost) make OpenStack relevant for companies and governments with significant budgets. There is also a healthy shared infrastructure (aka public cloud) market living in the shadow of the big 3 players. It’s still unclear how this ecosystem will make money for the vendors.

What do customers buy? Should the Core be free?

My personal experience is that most customers are reluctant to (but grudgingly do) buy distros for the core open technology. They are much more willing to pay for adjacencies like security, storage and networking.

Emerging Challenges from Adjacent Technologies

Containers and Kubernetes are making a significant impact on the OpenStack community. At points, the OpenStack keynote was more about Kubernetes than OpenStack. It’s also clear that customers want to use containers as an abstraction layer to make infrastructure less visible or locked-in. That opens the market for using servers directly (bare metal) or other clouds. That portability is likely to help OpenStack more than hurt it because customers can exit workloads from the Big 3 players.

Friction for adoption remains a critical hurdle.

Containers, which are cloud first platforms, have much less friction than IaaS platforms. IaaS platforms, even managed ones, require physical infrastructure with the matching complexity and investment.

OpenStack: an open infrastructure software community

Overall, the summit remains an amazing community space for open infrastructure software and cloud alternatives to the Big 3 players. The Foundation’s pivot to embrace Kubernetes and foster several other open technologies helps maintain the central enthusiasm for open source infrastructure that gave birth to the platform in the first place.

A healthy pragmatic vibe

The summit may not have the same heady taking-on-the-world feeling as the early days; instead, it has a healthy pragmatic vibe. Considering how frothy this space remains, that may be a welcome relief.

What are your impressions? I’m looking forward to hearing from you!

Open Source Collaboration: The Power of No

TL;DR: The days of using open software passively from vendors are past, users need to have a voice and opinion about project governance. This post is a joint effort with Rob Hirschfeld, RackN, and Chris Ferris, IBM, based on their IBM Interconnect 2017 “Open Cloud Architecture: Think You Can Out-Innovate the Best of the Rest?” presentation.

nullIt’s a common misconception that open source collaboration means saying YES to all ideas; however, the reality of successful projects is the opposite.

Permissive open source licenses drive a delicate balance for projects. On one hand, projects that adopt permissive licenses should be accepting of contributions to build community and user base. On the other, maintainers need to adopt a narrow focus to ensure project utility and simplicity. If the project’s maintainers are too permissive, the project bloats and wanders without a clear purpose. If they are too restrictive then the project fails to build community.

It is human nature to say yes to all collaborators, but that can frustrate core developers and users.

For that reason, stronger open source projects have a clear, focused, shared vision. Historically, that vision was enforced by a benevolent dictator for life (BDFL); however, recent large projects have used a consensus of project elders to make the task more sustainable. These roles serve a critical need: they say “no” to work that does not align with the project’s mission and vision. The challenge of defining that vision can be a big one, but without a clear vision, it’s impossible for the community to sustain growth because new contributors can dilute the utility of projects. [author’s note: This is especially true of celebrity projects like OpenStack or Kubernetes that attract “shared glory” contributors]

There is tremendous social and commercial pressure driving this vision vs. implementation balance.

The most critical one is the threat of “forking.” Forking is what happens when the code/collaborator base of a project splits into multiple factions and stops working together on a single deliverable. The result is incompatible products with a shared history. While small forks are required to support releases, and foster development; diverging community forks can have unpredictable impacts for a project.

Forks are not always bad: they provide a control mechanism for communities.

The fundamental nature of open source projects that adopt a permissive license is what allows forks to become the primary governance tool. The nature of permissive licenses allows anyone to create a new line of development that’s different than the original line. Forks can allow special interests in a code base to focus on their needs. That could be new features or simply stabilization. Many times, a major release version of a project evolves into forks where both old and newer versions have independent communities because of deployment inertia. It can also allow new leadership or governance without having to directly displace an entrenched “owner”.

But forking is expensive because it makes it harder for communities to collaborate.

To us, the antidote for forking is not simply vision but a strong focus on interoperability. Interoperability (or interop) means ensuring that different implementations remain compatible for users. A simplified example would be having automation that works on one OpenStack cloud also work on all the others without modification. Strong interop creates an ecosystem for a project by making users confident that their downstream efforts will not be disrupted by implementation variance or version changes.

Good Interop relieves the pressure of forking.

Interop can only work when a project defines what is expected behavior and creates tests that enforce those standards. That activity forces project contributors to agree on project priorities and scope. Projects that refuse to define interop expectations end up disrupting their user and collaborator base in frustrating ways that lead to forking (Rob’s commentary on the potential Docker fork of 2016).

nullUnfortunately, Interop is not a generally a developer priority.

In the end, interoperability is a user feature that competes with other features. Sadly, it is often seen as hurting feature development because new features must work to maintain existing interop standards. For that reason, new contributors may see interop demands as a impediment to forward progress; however, it’s a strong driver for user adoption and growth.

The challenge is that those users are typically more focused on their own implementation and less visible to the project leadership. Vendors have similar disincentives to do work that benefits other vendors in the community. These tensions will undermine the health of communities that do not have strong BDFL or Elders leadership. So, who then provides the adult supervision?

Ultimately, users must demand interop and provide commercial preference for vendors that invest in interop.

Open source has definitely had an enormous impact on the software industry; generally, a change for the better. But, that change comes at a cost – the need for involvement, not just of vendors and individual developers, but, ultimately it demands the participation of consumers/users.

Interop isn’t naturally a vendor priority because it levels the playing field for all vendors; however, vendors do prioritize what their customers want.

Ideally, customer needs translate into new features that have a broad base of consumer interest. Interop ensure that features can be used broadly. Thus interop is an important attribute to consumers not only for vendors, but by the open source communities building the software. This alignment then serves as the foundation upon which (increasingly) that vendor software is based.

Customers should be actively and publicly supportive of interop efforts of projects on which their vendor’s offerings depend. If there isn’t such an initiative in those projects, then they should demand one be started through their vendor partners and in the public forums for the project.

Further, if consumers of an open source project sense that it lacks a strong, focused, vision and is wandering off course, they need to get involved and say so, either directly and/or through their vendor partners.

While open source has changing the IT industry, it also has a cost. The days of using software passively from vendors are past, users need to have a voice and opinion. The need to ensure that their chosen vendors are also supporting the health of the community.

What do you think? Reach out to Rob (@zehicle) and Chris (@christo4ferris) and let us know!

Note: Cross posted on IBM OpenTech site.