Kubernetes certification starts with the people operating it

Choosing someone to operate a Kubernetes cluster requires evidence about the people who will support it. A description of the software cannot establish whether a provider can explain a failure or accept responsibility for recovery. The November 8 announcement addresses that procurement problem through a training, certification and Kubernetes Managed Service Provider program. It establishes a way to assess expertise alongside the software an enterprise intends to deploy.

The timing needs care. Today's announcement launches the program, while the course and examination remain work in progress. The course is expected in early 2017, and certification is expected in the second quarter. Calling this an available examination would confuse an announced qualification with something an engineer can already earn. Customers can evaluate the proposed requirements now, but the completed certification process remains ahead of them.

I value Kubernetes for the operational model it asks people to understand. Support is useful when the person answering can explain why the system behaves as it does and identify the responsibility of each component. A qualification aimed at practical cluster administration has a more useful purpose than a badge that establishes familiarity with product names.

A second qualification for service providers

The earlier Service Partners announcement on October 31 distinguished companies offering consulting and support from Technology Partners offering software and support for that software. That distinction concerns what a company sells. It helps a customer find assistance, but a listing alone gives limited information about the depth of that assistance or the people assigned to provide it.

The new managed provider tier adds requirements to that existing arrangement. A provider needs at least three certified engineers, active contribution to Kubernetes, and a business model that supports enterprise end users. These requirements concern staffing, involvement in the project and the ability to provide an ongoing service. The program therefore evaluates more than a company's willingness to appear in a directory.

Each requirement answers a different question. Requiring several qualified engineers reduces dependence on one named expert. Upstream activity gives customers a reason to expect a provider to understand the project beyond its own packaging. A support business gives that expertise a contractual setting. These are interpretations of the requirements, not guarantees that a particular provider will handle every incident well.

The contribution requirement is especially relevant to support work. An explanation of a problem must eventually connect with the software's actual behavior. Participation in its development can help a provider distinguish a local configuration issue from a question that needs upstream attention. Membership cannot establish that every support engineer has this ability, so customers still need to understand how their cases reach the people with the relevant knowledge.

An open curriculum changes who can teach

The CNCF announcement describes a collaboratively developed curriculum and an online proctored examination run by the Linux Foundation. It also proposes a free introductory edX course. Training providers can use the open curriculum, which makes a shared definition of competence available beyond a single company's classroom.

That arrangement matters because training and assessment have different jobs. A course can organize the material and help a learner practice. An examination must establish whether the learner can perform the work the qualification claims to cover. Publishing the curriculum makes the intended scope visible to both parties. It also gives an employer something more concrete to discuss than the reputation of whichever course an applicant happened to attend.

An open syllabus can expose omissions before they become assumptions in hiring. If the curriculum leaves an operational subject out, customers and instructors can point to that gap. A private training outline gives outsiders less opportunity to examine what the qualification means. The working group creates a place for those arguments to occur, although today's announcement does not settle the eventual examination content.

I prefer this relationship between public knowledge and commercial support. A company can charge for instruction or operational responsibility while the underlying description of competence remains available for inspection. That gives customers a basis for comparing services without requiring them to accept each provider's private definition of expertise.

What an SLA still has to specify

The managed provider program describes support backed by service level agreements. A qualification and a contract answer different questions. Certification concerns competence within an assessed scope. An SLA describes obligations between a customer and a provider. Neither document should silently inherit promises that appear only in the other.

For example, a customer needs to know whether a support commitment concerns responding to a request or restoring a service. Those obligations have different consequences for staffing and escalation. Responsibility for applications also needs a stated boundary. Buying help with cluster operation does not by itself describe who owns a database's recovery procedure or decides whether an application is safe to restart. These are contractual questions that the existence of the program cannot resolve for an individual purchase.

The number of qualified engineers deserves similar interpretation. Three engineers establish a minimum organizational investment, but that number alone does not describe a shift schedule or guarantee availability to a particular customer. A useful commercial discussion connects the program's staffing requirement with the provider's actual support arrangement. The badge can start that discussion without supplying all its answers.

The launch is a commitment to define competence

The record of today's announcement is strongest when read as a public commitment to build an assessment system. A curriculum working group is beginning its work, while providers and customers have proposed requirements to examine. The unfinished parts should stay visible when anyone describes what the program offers today.

My interest is in whether the resulting qualification makes operational reasoning easier to evaluate. A customer should be able to ask how an engineer reaches a diagnosis and which responsibilities the provider accepts. The open curriculum can make those conversations more specific. The managed provider requirements give them an organizational context, while the service agreement must still state what happens when that customer's system needs help.