Friday, 2 January 2015

Awkward questions for those boarding the microservices bandwagon

Why isn't this a library?
What heuristics do you use to decide when to build (or extract) a service versus building (or extracting) a library?

How do you plan to deploy your microservices?
What is your deployable unit?
Will you be deploying each microservice in isolation or deploying the set of microservices needed to implement some business functionality?
Are you capable of deploying different instances (where an instance may represent multiple processes on multiple machines) of the same microservice with different configurations?

Is it acceptable for another team to take your code and spin up another instance of your microservice?
Can team A use team B's microservice or are they only used within rather than between teams?
Do you have consumer contacts for your microservices or is it the consumer's responsibility to keep up with the changes to your API?

Is each microservice a snowflake or are there common conventions?
How are these conventions enforced?
How are these conventions documented?
What's involved in supporting these conventions?
Are there common libraries that help with supporting these conventions?

How do you plan to monitor your microservices?
How do you plan to trace the interactions between different microservices in a production environment?

What constitutes a production-ready microservice in your environment?
What does the smallest possible deployable microservice look like in your environment?

2015 technology wishlist

The start of the year is a good time to be thinking about the end of the year and the kind of world I would like to see. Usually this leads to resolutions and predictions. Unfortunately I find most predictions worthless since the pundits seldom go back to check on their previous predictions. The other problem is that people start out making predictions and then the articles turn into wishlists. That's why this year I'm just going to write a wishlist.

I'd like to see:
  • more viable identity providers.
  • more social environments that understand the benefits of Reed's Law and ridiculously easy group-forming.
  • Wikipedia starting to use identity technology to improve the user experience. For example if I donate or become a member then I'd like to stop seeing obnoxious adverts (and they really are adverts) asking for money. The Guardian's membership programme is a good model that Wikipedia should adopt.
  • a viable successor to the Leica M9. The Leica M Type 240 just isn't a big enough improvement.
  • a viable replacement for Aperture. I have zero faith in the upcoming Apple Photos app and there isn't enough official  support for migrating from Aperture to Lightroom.
  • a viable replacement for the old Mac Pro. The new Mac Pro abandons all of the strengths of the old Mac Pro.
  • more mujicomp and less ryanaircomp.
  • fewer people bemoaning the web we lost and more people asking new questions about the world we actually live in where everything gets touched by the network.
  • more device-native apps. I'd like to see more apps that are designed to really exploit the capabilities of our current generation of interconnected mobile devices.
  • more apps that provide multi-device workflows
  • more experience reports about the issues involved in building backend services that support multiple native mobile and web apps.
  • the Software Craftsmanship community changing its focus from converting new people to helping each other learn and grow.
  • less hype/advocacy for microservices and more documentation/descriptions of techniques that work with collections of small services. You'll be able to tell if you're seeing hype by the number of awkward questions that they raise.