SAN FRANCISCO, Nov. 16, 2020 (GLOBE NEWSWIRE) — GitLab, the DevOps platform delivered as a single application, announced today the appointment of Wendy Nice Barnes as Chief People Officer (CPO) and Merline Saintil to its board of directors. Both additions bring extensive experience to the company and will help GitLab further its position as a leading DevOps platform.

“As GitLab continues to grow, it is vital to our success to bring onboard key individuals who will help us maintain high growth and market leadership,” said Sid Sijbrandij, co-founder and CEO of GitLab. “Wendy has an impressive history of mentoring colleagues and growing leaders from within organizations. While Merline’s global award-winning product creation has enabled Fortune 500 companies to manage cyber risk at scale. Both embody our CREDIT values and are tremendous additions to the company.”

Barnes joins GitLab with over 20 years of Talent leadership experience in pre-IPO and Fortune 500 companies. She served as Chief Human Resources Officer at Palo Alto Networks, Vice President of Human Resources at eHealth, and held senior HR leadership roles at Netflix and E*TRADE.

“GitLab is not only a shining example of how to run a successful all remote company, but they are consistently recognized as a top company to work for,” said Barnes. “I am looking forward to joining such a transparent group of people, leading with the members of the executive team and working closely with its DIB (Diversity, Inclusion and Belonging) and remote leaders to further the great foundation set forth.”

Saintil currently serves on the boards of Lightspeed, Alkami Technology, Banner Corporation, and ShotSpotter and was recognized as one of the Most Influential Corporate Board Directors by Women Inc. She is a member of the National Association of Corporate Directors (NACD) and is certified in Cybersecurity Oversight by NACD and the Carnegie Mellon Software Engineering Institute. Saintil previously held leadership roles with iconic Fortune 500 and privately held companies including Intuit, Yahoo!, PayPal, Adobe, Joyent and Sun Microsystems. She has also received a Lifetime Achievement Award by Girls in Tech.

“GitLab has enabled its enterprise customers to shift left by seamlessly incorporating security into its single DevOps platform making them a unique company to watch,” said Saintil. “I’m honored to join its board of directors and have the opportunity to bring my engineering, enterprise risk and cybersecurity experience to support the company as it grows its footprint globally.”

GitLab Velocity and Recognition

The company has experienced 50x growth in 4 years and surpassed $150M in annual recurring revenue earlier this year with more than 30M estimated registered users.

GitLab recently ranked 13 on the Forbes’ 2020 Cloud 100 List (up from 32nd place in 2019) and was listed on the Enterprise Tech 30 2020 as a late-stage private company. GitLab also earned the ranking of no. 268 on the 2020 Inc. 5000 list of the fastest-growing private companies in America.

About GitLab

GitLab is a DevOps platform built from the ground up as a single application for all stages of the DevOps lifecycle enabling Product, Development, QA, Security, and Operations teams to work concurrently on the same project. GitLab provides a single data store, one user interface, and one permission model across the DevOps lifecycle. This allows teams to significantly reduce cycle times through more efficient collaboration and enhanced focus.

Built on Open Source, GitLab works alongside its growing community, which is composed of thousands of developers and millions of users, to continuously deliver new DevOps innovations. More than 100,000 organizations from startups to global enterprises, including Ticketmaster, Jaguar Land Rover, NASDAQ, Dish Network, and Comcast trust GitLab to deliver great software faster. All-remote since 2014, GitLab has more than 1,300 team members in 68 countries.

What Is etcd and Why Does It Matter for Kubernetes?

etcd is the distributed key-value store that Kubernetes uses as its primary backing store for all cluster state data — from node registrations and pod specs to service endpoints and configuration. Its reliability and performance directly affect the health of every Kubernetes cluster. etcd implements the Raft consensus algorithm to replicate data reliably across a cluster of nodes, tolerating failures as long as a quorum of members remains available.

Key Features and Improvements in etcd v3.4

1. Better Backend Storage: Fully Concurrent Read Transactions

etcd v3.4 addresses a significant performance bottleneck that affected large-scale Kubernetes deployments: blocking between read and write transactions in the storage backend.

Previously, the backend commit operation — which flushes pending writes — would block all incoming read transactions, even when there were no pending writes to flush. This caused read requests to queue up unnecessarily, sometimes surfacing as log warnings such as:

read-only range request … took too long to execute

In v3.4, the commit operation no longer blocks reads, improving the performance of long-running read transactions significantly.

The team went further and made backend read transactions fully concurrent. Prior to this change, ongoing long-running read transactions would block both writes and subsequent reads. According to the etcd release notes, this change resulted in:

• ~70% increase in write throughput when long-running reads are in progress.
• ~90% reduction in P99 write latency under the same conditions.

The team validated these gains by running a Kubernetes 5,000-node scalability test on GCE and observed consistent improvements across the board.

2. Improved Raft Voting Process: Pre-Vote

etcd uses the Raft consensus protocol for data replication. In a Raft cluster:

• A single leader is elected by the cluster members.
• The leader replicates data to followers and sends periodic heartbeats to maintain authority.
• Followers forward client proposals to the leader.
• An entry is committed once a quorum of members acknowledges it.

In the standard Raft implementation, a leader immediately steps down to follower status upon receiving any message carrying a higher term number — without performing any cluster-wide health checks first. This behavior can be exploited accidentally by a flaky or rejoining node:

1. A node drops off and reconnects intermittently, accumulating a higher term.
2. When it rejoins, it ignores messages with lower terms and broadcasts its higher term.
3. The current stable leader receives this message, steps down, and triggers an unnecessary re-election — disrupting cluster availability.

Network partitions amplify the problem: a partitioned node that regains connectivity can immediately force a leader re-election, even though the existing leader is perfectly healthy.

The fix: Pre-Vote. etcd v3.4 introduces a new pre-candidate node state. Before incrementing its term and launching a real election, a pre-candidate must first solicit informal votes from a majority of peers to confirm it is sufficiently up-to-date. Only if it wins this pre-vote phase does it proceed to increment its term and start a formal election. This extra handshake means:

• Disruptive nodes cannot force re-elections unless they genuinely have the support of a quorum.
• A healthy leader that maintains quorum connectivity stays in power, improving cluster stability.

3. New Raft Non-Voting Member: The “Learner”

Adding or removing members from a running etcd cluster (membership reconfiguration) is one of the riskiest operational tasks. Even when a reconfiguration does not change quorum size, it can expose latent issues that destabilise the cluster. A new member that joins without being caught up on the leader’s log is especially dangerous — it could inadvertently reduce the effective quorum before it has replicated enough state to participate meaningfully.

etcd v3.4 introduces the Learner role to address this. A Learner:

• Joins the cluster as a non-voting member.
• Receives all log updates from the leader, catching up to current state.
• Does not count toward quorum, so it cannot affect leader evaluation of peer activeness.
• Serves only as a standby node until an operator explicitly promotes it to a full voting member.

By decoupling log replication from quorum participation, the Learner role makes membership changes far safer and reduces the window of increased cluster vulnerability during scaling operations.

4. Simplified Client Balancer Failover Logic

etcd clusters are designed to tolerate node and network failures transparently, presenting clients with a single logical cluster view across multiple server endpoints. However, cluster-side fault tolerance does not automatically guarantee client-side liveness — if a client is connected to a failing endpoint, it needs its own mechanism to detect the failure and reconnect.

Historically, the etcd client balancer was tightly coupled to an older gRPC interface. Every gRPC dependency upgrade risked breaking client failover behaviour, and fixing those regressions consumed a disproportionate share of engineering effort. The resulting code was complex and made fragile assumptions about server connectivity.

In v3.4, the balancer failover logic was simplified significantly. Rather than maintaining a complex list of unhealthy endpoints, the new logic adopts a straightforward approach: when the client is disconnected from its current endpoint, it immediately tries the next available endpoint. This change makes the client easier to reason about, easier to test, and more resilient across gRPC version upgrades.

Summary of etcd v3.4 Improvements

What This Means for Kubernetes Operators

For teams running large Kubernetes clusters, etcd v3.4 is a meaningful upgrade:

• Large clusters with heavy read traffic will see direct latency and throughput benefits from the concurrent read transaction work.
• Clusters that experience network instability will benefit from the pre-vote mechanism, which prevents flapping nodes from forcing unnecessary leader elections.
• Operators who regularly scale etcd clusters should use the Learner role when adding new members to reduce risk during the catch-up phase.
• Client application developers can expect more predictable reconnection behaviour from the etcd v3.4 client library.

As always, test etcd upgrades in a non-production environment first, review the official etcd changelog for any breaking API changes, and consult your Kubernetes distribution’s compatibility matrix before upgrading etcd on production clusters.

Source: Originally reported via Packt Publishing’s technology news coverage.