Prelude

What follows is the start of a broader reflection on how computing skills are managed in the age of cloud-everything, whether individual or collective, at the scale of a company, or even of a country.

The famous “side project”

In recruiting I meet about one junior dev a week, from every kind of background: engineering school, DUT/BUT, short program, bootcamp, or even self-taught.

On this kind of profile, we are obviously interested in the projects the candidate has built, and all the more in the ones built on their own time, which very often give a better read on the candidate, their skills, their expectations, and what drives them.

Of the 50% who show a personal project, about 30% push the thing all the way and deploy it to a production environment, and with very (very) rare exceptions, always on a cloud provider like Netlify, Heroku, Vercel, AWS, or GCP.

YAML Powa

[DISCLAIMER for what follows] I am absolutely not judging the value of deploying to a cloud, or the undeniable advantages a cloud infra gives you. My point is only about the skills that get developed.

“And so, I put the project in production on Netlify!”, the candidate is generally pretty proud to show their project running ON THE INTERNET \o/.

That’s great, it works, and it’s hugely gratifying to have your own creation, your baby, presentable to your parents/friends/nice-recruiters without a localhost:8080.

But how do you deploy to a cloud, then? It’s actually very simple, very well documented, and accessible to anyone, in principle for a young software developer. Obviously each provider has its own processes, configuration systems, UI, CLI, which turn lines of code on Git into a production project, often for free (“There ain’t no such thing as a free lunch”-TANSTAAFL).

A YAML config file, an API key, a git remote add, a set of environment variables, and off you go.

What has our young developer, maybe specialized in python or JS, learned from this operation? What skills? The YAML format? A new GIT command? The principle of authentication by API keys? The concept of PaaS? The computer person has certainly learned all these notions and skills, and the professional has learned to use ONE cloud.

DIY

Now, imagine the same personal project but with no cloud provider. How do you deploy the project? What tasks will they have to carry out to get there? In no particular order (not exhaustive):

• rent a server or a VPS
• secure access to it (ssh, firewall, fail2ban)
• deploy an http server
• deploy the code
• configure routing

Obviously, there has to be (easily) a 10x on the setup time of this solution compared with the cloud version, not counting the lack of scalability and resilience.

Now let’s look at the skills our novice is going to develop:

• gnu/linux architecture, user management, managing access rights
• ssh configuration, the principle of asymmetric encryption, key generation, the concept of a firewall, managing network flows
• HTTP server, SSL hardening
• deploying an Nginx, an Apache, or a Caddy, vhost configuration, generating and managing certificates
• DNS redirection
• building an application

People will of course object, in this example, that “It’s not a dev’s job to deploy an app to prod”: in most cases in big companies, true. Still, you can’t imagine how many “JS ninja” devs (#privatejokefrom2015) are completely ignorant of whole stretches of computing, with no doubt an effect on what they produce, like security (ask devs with 2/3 years of experience what’s in an HTTP request, you might be surprised).

I don’t know about you, but I find this gain in skill indispensable, especially at the start of a career. Yes, it’s long, yes, it can be a pain, but the number of key concepts that get covered makes this gain priceless. It benefits both the professional, who becomes versatile, and the computer person, who will be able to improve the quality of what they produce.

Deploying an app on a server lets you get at concepts that are only skimmed in the cloud solution — I’m only talking about a junior dev deploying a simple app, right — and which are obviously crucial to understanding the computing environment.

The Professional and the Computer Person

Ok, what I wrote is pretty obvious, so why did I write it?

Above all, I think we have to hammer into young engineers/devs that they need to understand what goes on under the hood. Levels of abstraction, whatever the discipline, can be very high, and understanding “what is going on” is what will make the difference between 2 people. That’s the case with someone curious enough to get their own server (a few euros a month for a VPS) to host their projects.

When a cloud is used, the person has learned to use and to configure ONE cloud provider. It’s an interesting skill, which they’ll be able to cash in ($$$) professionally, fairly easily, depending on the providers. They might even, for some of them, pass certifications (hello AWS & GCP) that will make them bankable to work on infrastructures implemented on that same provider.

The professional has developed skills that sell on the market, but the computer person has developed pretty feeble skills. On the other hand, the latter has shrugged off problems as old as computing (scalability, resilience, security, etc.). They have benefited from the skills of thousands of computer people who made this jewel of engineering possible, with the payoff of less time and lower cost to reach production, comparable to the experience effect in industry.

The hidden side is that the professional has “contractually bound” themselves to a cloud provider and the computer person has created a dependency. And that, by the way, is a stroke of genius for the provider, because what solution is the computer person certified “cloud architect AWS” going to propose for a problem? Obviously an AWS solution, even if it doesn’t fully meet the need, or it complicates the solution (without even mentioning the total dependency on that provider). Building certifications on your products means creating “under cover” sales engineers who are going to generate revenue.

These last points are what worry me the most. Without being a rabid-free-software-zealot-down-with-GAFAM, the productivity gains created by using the big cloud providers’ products, their ease, come with a global loss of skills, at the individual AND collective level.

Why collective? Because “serverless” makes me think furiously of the “factoryless” of 30/40 years ago and, for us French, that didn’t end very well.

End of part one

The rest here