0 comments on “Podcast – Eric Wright talks DevOpsishFullStackishness and Woke IT”

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.

0 comments on “Open Source, Operators, and DevOps Come Together for Data Center Automation”

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.

0 comments on “Podcast: Digital Rebar Tech Discussion on Patch APIs, Swagger, and Integrations”

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.

0 comments on “Digital Rebar Provision: Community Content Demos”

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:

0 comments on “Open Source Collaboration: The Power of No”

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.

2 comments on “Accelerating Community Ops on Kubernetes in Hybrid Style”

Accelerating Community Ops on Kubernetes in Hybrid Style

Preface: RackN is looking for SRE teams who are enthusiastic about accelerating Kubernetes on-premises in a long term operational way that can be shared and reused across the community.

kubernetesWe’re excited to see and be part of the community progress towards enterprise-ready Kubernetes operations on both cloud and on-premises.  The RackN team is excited to be part of multiple groups establishing patterns with shareable/reusable automation. I strongly recommend watching (or, better, collaborating in) these efforts if you are deploying Kubernetes even at experimental scale.

We’ve worked hard to make shared community ops work accessible, repeatable and multi-platform without compromising scale or security.

The RackN team has been enthusiastic supporters of Kubernetes since the 1.0 launch with our first deployments going back to June 2015 with updates for 1.2, 1.3 and now 1.5. I’m excited to report that fully converged the composable Digital Rebar approach with the Kubernetes Kargo Ansible. Our 1.2 efforts leveraged the Kargo predecessor “Kubespray.” This integration brings the parallel hybrid operation and node-by-node function of Digital Rebar with the Ansible community efforts around Kargo.

Composable design is a key element the RackN focus on SRE automation because it allows ecosystem

That allows a fully integrated deploy where Digital Rebar stages the environment and then use Kargo directly from upsteam to install Kubernetes. Post-deployment, Digital Rebar is able to extend the cluster with packages like Helm, Deis, Dashboard and others.

Since Digital Rebar supports parallel deployments, it’s possible to fully exercise the options enabled by Kargo simultaneously for development and testing.  Benefits????

For example, you can built-test-destroy coordinated Kubernetes installs on Centos, Redhat and Ubuntu as part of an automation pipeline. Unlike client side approaches like Terraform or Ansible, our infrastructure allows transparent monitoring of the deployments including Slack integration.

Flexibility is also important between users because Ops variation is both a benefit and a cost.

A key Digital Rebar design goal is for users to explore useful variation and still share operational best practices. We are proving that shared community automation can support many different scenarios including variation between between clouds, physical, operating system, networking and container engine.

If we cannot manage this variation in a consistent way then we’re doomed to operational fragmentation (like OpenStack has endured).

We’re inviting you to check out our open work supporting the Kubernetes Ops community. As Rob Hirschfeld says, looking for “Day 2” minded operators who want to make sure that we are always able to share Kubernetes best practices.

%d bloggers like this: