How Project Onboarding Can Undermine DevOps Efforts at Large Organizations

A “hello world” application is the most basic program a developer, typically a beginner, will write to learn a new language. It’s a sort of “everything works”—a stack-checker app to kick off a project quickly and see its results.

The resulting hello world program is typically a message printed to your screen: “Hello world.” That’s it. No microservices, REST API or class factories, but very satisfying, nonetheless. The stack works; you built it and ran it from scratch.

The average time for a programmer to write a hello world application code is probably a few minutes, or even seconds. The average time to set up the developer’s computer or workstation and servers to be able to compile/build and run a hello world app may take a while longer, maybe a few hours to set up. And I’m thinking cloud server or container. Publishing a hello world app to Google Play, including setup, build and deployment, takes around a few hours for the first-timer. That’s not too bad. But here’s the deal: It’s a few minutes for your first program to run vs. a few hours for your first deployment.

That’s a 60:1 ratio.

Let’s raise the bar a little: Take a large corporation with an IT department of 1,200-plus employees, for example. In that environment the average time to publish a brand new hello world application increases by at least an order of magnitude—even more if the developer is not just onboarding an application but also herself or her team into the organization.

Cutting through IT red tape is a great distraction as epics, user stories and customer requirements pile up. These tasks can be simple to complex, such as setting up your code repository and development stack; identity, security, disk, network and other stack provisions; boilerplate artifacts and following testing and release policies. That’s a considerable chain of requests and wait periods—enough to make that hello world program loop around for months before it reaches production.

DevOps for the Hello World

The ability of a business to respond to market changes start by a quick new-project ramp-up. And in a microservices world that’s often the case. But that’s mostly at the architecture level. How easy is it to provision and manage the external environments beyond microservices? Or, how easy is it to provision and manage the full Dev to Ops stack at your organization, period?

A good way to tackle this is to offer a menu of automated tasks through a help desk-like setup, a configuration catalog if you may. A configuration catalog holds tasks à la carte for every need in the DevOps cycle. Call it the IT user interface for teams requesting or delivering changes to the organization.

This is nothing new. ITIL talks about it everywhere. It’s called a service desk. In a DevOps culture, however, traditional service catalogs do not cope well with continuous deployment and infrastructure-as-code approaches. And vice versa. The reason is that there are plenty of needs that tend to fall outside the common service desk and configuration management automation realms, so they end up in an issue tracker, service ticket or, worst case, plain emails, chat and phone call requests.

From Zero-to-Deploy

A catalog of configuration services can be application or project-oriented and should keep state, knowing what has been requested and delivered in the past to enable future interactions. Every task offered by the catalog has one or more rules associated with it. These rules, or recipes, do the dirty work and automate provisioning, emails, boilerplate setup and other tasks that antecede or surround most of the core DevOps delivery automation.

Think of it as your classic service desk catalog and configuration management tool set combined.

Building a configuration management front end can greatly mitigate and simplify the effort of onboarding applications. Here are some of the features and strategies to consider:

• Baseline Templates: Offer teams a set of baseline configurations, tasks and services that can be provisioned around project typologies, such as “Mobile App,” “Python-Django-Postgres” or “Java-Spring-AngularJS-Oracle DB.” That means that on Day 1 the developer only has to select the preapproved application type to get started. Push-button onboarding should include straightforward guidelines that guarantee that the project starts on the right foot, including committing boilerplate source code to the repository and directory verification.
• Incremental Services: Make the catalog offering incremental, providing development teams only the options they should have at a given time for each project at its given stage. A good configuration system will keep track of what every application has installed at a given point in each environment, so progressive options will be offered.
• Broaden Your Scope: Automate all provisioning tasks in sight. Just because your application is containerized or configuration management is automated it doesn’t mean it’s a push button from start to finish. Reasonably sized applications have many dependencies, approvals and setup steps that are don’t have a place in typical scripted recipes.
• Manual Tasks: Make the work flow by bringing every manual process into the onboarding pipeline and avoid the need for emails. Make sure to cater to non-standard requests also, as that will help keep everything in one place.
• Draft and Versioned Provisioning: Allow provisioning plans to be built along with the code, be it infrastructure-as-code or catalog requests. As new requirements come into play, revise provision drafts accordingly.
• Scale to Environment: For every new environment in the onboarding chain just reapply the previous requests and configurations, but adjust them to that particular stage. For example, a preproduction environment template will probably need to scale CPU, network and memory to closely mimic production.
• Just-in-time: Make sure provisioning happens before code is delivered. If before means just-in-time, great. Maybe it’s just a matter of putting provisioning before deployment in the automation pipeline. Or maybe it’s a non-standard request that needs human intervention and holds up a release for a short time. The closer provisioning looks like continuous deployment, the better.

The next generation of configuration management tools must tackle many different aspects of onboarding applications and services to become an effective DevOps front end. This is not just giving developers a “Request Cloud VM” button but the full how, why and where chain that assists teams with writing boilerplate application and infrastructure code, passing the first build or scaling environments correctly. And moving forward, ChatOps and machine learning are replacing the classic request workflow, adding needed insight and foresight to manage project deliveries from zero-to-deploy.

DevOps practices should start early on in the cycle and offer a great user experience all the way through. A good delivery chain needs to tackle the newcomer workflow, just like the application interfaces of today tend to target first-time users. A friendly and capable DevOps front end is what separates mature organizations from the rest, helping them smoke the from-hello-world-to-deploy test suite gracefully.

About the Author/Rodrigo González

Rodrigo Gonzalez is the CEO and co-founder of Clarive. Besides running the day-to-day operations, Rodrigo oversees the overall strategy for the company. Rodrigo, originally from Brazil, holds a B.S. in Computer Science from Texas Tech University and has nearly 20 years experience working at tech companies in the United States, Brazil and across Europe, including Lucent Technologies and CA Inc.