A Perl toolchain for building microservices at scale

The guys at Semantics3 explain how they came with a workflow that was tuned for micro-services and capable of scaling up with the team. Here are the problems they needed to address:

  1. Each code artifact (a library, script or service) should be owned by one engineer. It should do one thing and one thing only (Unix philosophy).
  2. Each code artifact must be checked in to its own VCS repository and must have tagged releases with semantic versioning.
  3. The experience of authoring a code artifact must be both seamless for an individual developer and uniform across the team with tooling present to take care of scaffolding boilerplate code, identifying dependencies, packaging, testing and releasing. The tooling available should enable a single engineer to own multiple code artifacts easily.
  4. Private libraries that we write must be installable from services in exactly the same way that third-party libraries are.
  5. Each code artifact must declare its dependencies (code and environment) explicitly i.e. clean contracts. Ideally, any developer must be able to run any script/service on their development environment easily.
  6. An engineer’s development environment must be as isolated as possible so that we don’t step on each others’ toes.

Why Perl?

Comprehensive article explaining why Perl (a question I’ve received a few times myself as well) and how they managed to resolve their issues using Pinto, Minilla, Carton, Perlbrew, Github and Mojolicious. In my job I use Plenv instead of Perlbrew, however they address the same problem. One thing I came to realise over the last year is Perl is a lot more present and capable than many think it is. Look at many solutions hosting providers offer, for instance, cPanel. That is Perl. Moreover, glad to see Mojolicious making the cut, as that is my go-to framework now. And I like it so much that I’ve decided to write a Beginner’s Guide for it. More on that soon.