The newfinalfinal_v2.psd of Serverless Computing

We recently marked the beginning of Daylight Savings Time in Europe, which gave me some time to think about time itself, in particular about anachronisms (like the soon-to-be obsolete Daylight Savings Time).

Any developer who has worked closely with designers is familiar with the situation below: files with names like newfinalfinal_v2.psd showing up in your project’s directory. It’s so common an occurrence that it has been made into a meme.

From The Inspiration: http://www.theinspiration.com/2015/03/every-designer-world-yash-bhardwaj-jugaad-posters/

To add insult to injury (no, I’m not speaking about the last file name in the series. Anyone who has ever read comments in code knows that this can be perfectly descriptive language), `newfinalfinal_v2.psd` and its cousins show up in your Git repository, a beautifully functional and immutable data structure that is perfectly capable of keeping the history of work-in-progress files, with the safeguards needed to restore older versions when it’s needed.

What we are observing here is an anachronism in action: a good sentiment (it makes sense to keep old versions of a file, because people tend to change their minds) combined with advanced, but misunderstood or ignored technology (a versioning file system that makes restoring old versions really easy). This leads to the anachronistic exercise of outdated practices like versioning through file names.

All of this would be a cheap, and not particularly original (considering that the image above dates from 2015) laugh at the expense of designers if it were not for developers falling for the same anachronism trap. To repeat, the anachronism trap is:

A good sentiment, combined with advanced, but misunderstood or ignored technology, that leads to the exercise of outdated practices.

One area where developers have been falling for the anachronism trap is in the use of environments in Serverless computing.

The anachronism trap starts with good sentiment, and the use of environments started with the good sentiment that people make mistakes. This is the most likely time for your service to break: right after deployment. It therefore makes sense to separate production code from development code. Or more to the point:

Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in.

In a world of limited and expensive resources with high transaction and setup costs (who does not remember servers, fondly?), separating production code from development code meant setting up a separate server that was a reasonable imitation; who could afford two real servers, exact copies of your production server and call it staging, dev, or testing? If you were really lucky, you had all four.

This practice has become so engrained in the minds of developers that it turned into a ‘best practice,‘ which means you can stop thinking because you can just safely copy what everyone else is doing. When Serverless computing came along, this best practice was applied with the proper degree of mindlessness, resulting in Serverless production and staging environments.

The second part of the anachronism trap is new and misunderstood or ignored technology. Serverless is an emancipation of the developers from the constrains of the underlying hardware (bought at the price of accepting the constraints of serverless architecture) and it means that computing resources:

  • have low startup and transaction costs
  • have zero cost when not used
  • i.e. behave like the exact opposite of the servers we used to know

With serverless computing you can now have one deployment for production code, and one for every developer on the team, or one for every branch you are developing on, or one for every revision, or one for each combination of the above. As deployments are effectively free, you can have as many as you can manage and there is no longer a reason to restrict yourself to the trifecta of production , staging, and development.

Restricting yourself to constraints that no longer apply: that’s where the anachronism trap snaps shut and keeps you bound to old habits. And just like a real trap, it comes at a price:

  • the designer duplicating files wastes space and confuses team members.
  • the development team sticking to a limited number of environments leaves code untested and increases risk.

Machine learning and serverless computing are the two most important software innovations of our decade, but only serverless computing requires significant changes in the way developers work. The anachronism trap of ‘serverless environments‘ is just one example.

The next time you hear someone talk about their serverless environments, think of the anachronism trap and newfinalfinal_v2.psd.

Follow the Adobe Tech Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products.