Software Engineering at Google and Microservices

Someone linked this e-book on software engineering at Google to me. And I feel somewhat vindicated in my advice around Microservices. In the section on "Time and Change" I found this little bit here:

For any project that didn’t plan for upgrades from the start, that transition is likely very painful for three reasons, each of which compounds the others:

• You’re performing a task that hasn’t yet been done for this project; more hidden assumptions have been baked-in.

• The engineers trying to do the upgrade are less likely to have experience in this sort of task.

• The size of the upgrade is often larger than usual, doing several years’ worth of upgrades at once instead of a more incremental upgrade.

To recap, my suggestion was to start with a hybrid approach if you're uncertain of the architecture demands. And I made a lot of the same arguments as to why.

The simple argument is; if you aren't 100% certain of the demands and thus the correct architecture, then it is logical to assume that at some point you would benefit from re-architecting some or all of the services to maintain code stability/quality/performance.

And with that in mind, by doing at least some of the architecture as Microservices you're exposing yourself to the tasks associated with incorporating a Microservice. As a result, you're forcing yourself (or your team) to have some experience and you make more of the work required to transition other parts of the service into incremental versus wholesale changes.

While it does not necessarily alleviate any of the above entirely. It is pretty easy to see how it makes the first two pretty much negligible. And the third, the amount of work, should be smaller as well. While such a migration might be larger than a typical task, having laid the foundation by building out other Hybrid or Microservices previously it should definitely result in a decreased scope for the effort.

I also particular liked in the TL;DR section of the same page this one:

• Software is sustainable when, for the expected life span of the code, we are capable of responding to changes in dependencies, technology, or product requirements. We may choose to not change things, but we need to be capable.

My argument are generally in favor in accommodating the unknown/unexpected. And this often means anticipating the need for multiple types of solutions. Researching and adopting more than one strategy can seem costly up front. But it is the longer term benefits you're really interested. You can always scale back on the number of adopted solutions later. Once you have the knowledge and expertise that is.

Mostly, I'm bringing this up though, simply because I'm shocked to find such well articulated reference material to support me. Impostor syndrome runs deep. Also, I wanted to keep a link to this e-book somewhere.