Pokéservices

We’ve all been there. It’s 2am on a Saturday night. Operations call because some feature on your front page is broke. You get a PagerDuty alert because some-codename-api is down. You’ve never seen some-codename-api before in your life. You open it up on Github — the only developer that worked on it has now left. It doesn’t install and build locally any more. Product Owner for the feature has moved on to new shiny things and no longer cares about the thing they shipped 2 years ago.

Microservices can be a great architecture for building and shipping things quickly — but come with the onus of distributed ownership. But what if it wasn’t such a burden?

Introducing: Pokéservices! A framework for putting the fun in perfunctory maintenance and ownership of microservices.

Starter services

Every new joiner to the team should be given a service to own and look after. Ownership of (or “catching”) this service will introduce them to the patterns and libraries used by the team, as well as giving everyone a sense of responsibility and feeling that they are adding value.

Caring for your Pokéservice

While everyone will work and interact with lots of Pokéservices, the purpose of an owner (or trainer) is to ensure that a service is well maintained (updating dependencies, failing builds etc), well understood (documentation/tests), correctly lifecycled (retired if no longer needed).

Pokéservice trainers do not have to be developers — they can be Product Owners, BAs, QAs, even stakeholders could catch them.

Pokéservice Cards

Every Pokéservice will have the following:

• Name: a cool name, ideally a pun.
• Type: this can be either a team, department and/or category of service (front end component, API, user facing application etc).
• Description: a clear statement of what the service does and why it exists
• Stage: where this service lies in the product lifecycle (is it experimental or more evolved?). A service can only evolve if it’s stats meet a certain threshold, or some criteria of supportability are made.
• Special moves: any technologies used, APIs provided or otherwise that are unique to this service (e.g. it’s the only app in your team that uses that latest hipster JS framework), as well as how to use them.
• Stats: indications of it’s value to the business, cost and ease of maintenance. Ease of maintenance could incorporate things like test coverage, number of different committers to the repo, technologies unique to this service.
• Shinyness: SLAs are super simarle. If it’s a shiny, you can call me up after hours. HP: Pokéservices will use Hit Points to determine how healthy they are. This could consist of error rates, health of underlying services — whatever you use to monitor your services now.

Pokédex

This will be your central database of all the Pokéservices, and will include information of who currently owns the service, and who has “seen” it (which can be anybody who has worked on or committed to the service).

They are also the key to gamifying the system. The Pokédex will also rank trainers as they progress through the organisation. Everyone’s bonuses will be linked to the ownership, training of and retiring of Pokéservices, as well as annual “The Very Best” awards.

Gyms

Each of the types of Pokéservice defined by your organisation should have a Gym leader. This is someone who’s expertise is in that type (so a Tech lead for a department, or Front End overlord etc.), and can be used to “battle test” a service and ensure it is worthy of the type. A gym leader can then give github badges to cosign or verify the legit-ness of a service.

Trading

In a large organisation, it’s inevitable that people move around within teams and departments. The concept of trading allows me to move on without being straddled with services I no longer need to know about.

It also provides incentive to look after and maintain the services I own. If I try to get rid of a weird API that is undocumented, untested and falls over every other weekend, nobody is going to want to give me their Charizard for that.

Battling

Occasionally, there’ll be times where you have multiple services doing the same thing. This could be on purpose — one of the perks of a microservice is that it is easy to replace a small part of your system with another that performs better. It could be a result of silos in your organisation that inadvertently created the same thing without talking to each other. Or perhaps someone somewhere higher up got a fancy sales pitch for a new Recommendations API that will boost your conversion rate by 300%.

Having well defined services with scores for value, cost and maintainability make battling a super effective way of pitting competing services against each other.

Battles are also a great framework for convincing that one stubborn stakeholder that their pet project that nobody actually uses can no longer hold the fort against your level 80 Rattata’s Hyper Fang.

Here are some other concepts that — while not core to the Pokéservice framework, may sound familiar to your organisation.

Legendary Pokéservices

These are the services that have been around since the dawn of time that nobody understands, nobody can get rid of, and yet underpin your entire company’s revenue.

By rebranding them from legacy to Legendary, these will now beconsidered rare and prestigious to own, and so everybody will want a piece of the action.

Team Rocket

That consultancy or startup that came in, created a load of shiny, unsupportable tech that you now have to deal with in house.

Squirtle Squad

The Squirtle Squad are a gang of prank-loving, shell-toting delinquent services who’ve been abandoned by their owners and no longer trust humans.

These are the services that every so often break and cause trouble for no reason, but with a bit of human TLC would be a valuable addition to your team.

Magikarp

This is the thing that was made at a Hack day, that everyone thought had great potential — but nobody actually wants to put the time and effort into developing it.

Pokéservices put the emphasis on the long term relationship between you and your service. They should be your best friend, in a world you must defend. A Pokéservice teaches you as much as you teach it.

It demotes the importance of creating new services/features/apps, and instead notes that to catch a service is the real test, and to train them is your cause.

So go forth; travel across your landscape, searching far and wide for each Pokéservice, to understand the power that’s inside. And be the very best.