ISSUE 196: Straighten Up Your Namespace

“With agile your documentation is out of date as soon as it’s published — your docs need to be updated when your product is updated.”

If technology affects everyone, shouldn’t technology be for everyone? By everyone? The architecture of distributed systems becomes increasingly complex. And big data, artificial intelligence and machine learning all make things more complicated. Yet we witness a continued pushback to allow more people — even non-IT trained — to be able to access the potential of technology and even create it.

This isn’t just driven by a technological change. More interestingly, it’s a cultural change. And a drive to find a common language so that all key stakeholders can understand the intent behind any digital resource.

At KubeCon+CloudNativeCon last month, The New Stack founder and publisher Alex Williams sat down with Pivotal’s Senior Vice President James Watters and Pivotal’s Global Chief Technology Officer of data-intensive software Sina Sojoodi. They take you on the historical journey, from our origins of service-oriented architecture and Waterfall program management through to the microservices architecture, event-driven design and agile practices of today. And they begin to look toward the dependency-oriented and data-centric tomorrow.

Straighten Up Your Namespace

Earlier this year, at HashiCorp’s annual user conference in Seattle, HashiCorp CEO Dave McJannet shared with us his perspective on maintaining cloud native operations. We’ve gone beyond our reliance on Internet Protocol numbers as the ultimate identifier, at least within distributed systems, he argued. With the age of automation and programmable infrastructure, there was no way each individual service could be assigned a single IP, as it would drift from cluster to cluster, sometimes within seconds. Should a Domain Name Service (DNS) track an ephemeral container’s IP when it would only be up for 30 seconds? Not very bloody likely. Instead, what the emerging cloud native world needed was some sort of central registry to keep track of all the services as they dynamically move around across different nodes. And the registry would keep track of the service names, which would be their core identifiers.

The company’s Consul services networking router was built with this philosophy in mind. And a surprising number of Fortune 500 companies and other large enterprises have adopted Consul. And their success with the product has brought a number of new challenges — one of which is keeping track of all the service names. Each development team may create what they think are unique names for their services, though other teams may have already used those names, leading to confusion when some other service tries to find one particular service with that name. You could have one central office administer the assignment of names, but this can be time consuming, and would slow down developer productivity. 

Now Consul 1.7 has taken the next step is service name management, by offering unified namespace management. This is a self-service feature that allows an organization to split up its global namespace into separate domains, such as “development” or “legal,” allowing each team to manage their own namespace, while maintaining an organization-wide coherent registry of service names. 

It’s exciting to see HashiCorp take its vision to the next level, allowing all its customers to enjoy its hard work. 

Kubernetes 1.17 Brings Volume Snapshots, Easier Plugin Management

The new release of Kubernetes 1.17 brings volume snapshots. This feature creates a point-in-time copy of a persistent volume. These snapshots can be used to provision new volumes or to restore an existing volume to a previous state. “Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no 'cluster-specific' knowledge.”

Continuous Documentation in a CI/CD World

Why do we suspend the continuity of CI/CD when it comes to documentation — the thing that helps users actually use our product? Because no one wants to do it, as it seems like an ancillary chore to our normal workflow. But docs are important because you never know how your tool will be used by others.

Why Packet Is Open Sourcing Its ‘Bare Metal’ Bring Up Technology

Packet has open sourced Tinkerbell — the same technology that powers over 60,000 deploys on Packet’s global bare metal cloud each month — which provides developers with a consistent method for provisioning and lifecycling heterogeneous physical infrastructure. With Tinkerbell, Packet hopes to bring a cloud-like experience to more environments. “Our goal with open sourcing Tinkerbell is to ensure that users can leverage automated bare metal as the foundation of their multi-, hybrid- and private-cloud initiatives, no matter what that looks like or where the infrastructure lives,” a Packet spokesperson said.