But sometimes I want a microservice…

Remember 3 days ago when I acknowledged that I had already missed a day 3 days into trying to write something daily? Yeah…about that. Anyway, we’ll just pretend that I was waiting until I got a chance to read an article that made me want to talk about the other side of that post. The other day I talked a little bit about some thoughts after reading Hype Driven Development. That article talked about our tendency to see something work well to solve one problem, and set forth to use it to solve all the problems.

Tonight I went down a bit of a black hole spurred by reading a post on the Netflix Tech Blog. Netflix does some really great stuff, and I often find myself solving all the problems with things I read about/use of theirs. I think I heard someone in a talk I attended once describe Netflix as a really great software development company that happened to create a video streaming service. This seems like an accurate description as an outsider who is frequently a little envious of all the cool things they create.

This particular black hole of reading was spurred by a question posed in the post linked above.

Can we provide engineers at Netflix the benefits of a monorepo and still maintaining the flexibility of distributed repositories

This is something I’ve found myself thinking about a lot recently because of things I’ve been working on. Trying to find the right balance while answering two different questions:

  1. How do we decouple these things?
  2. How do we avoid making 12 independent things to manage that does little more than add extra headache?

This is the struggle between the monorepo and microservices right? If you have a single development team, or even 2–3 development teams sometimes splitting one thing into many seems like you’re just creating more of a headache for yourself, and to some degree you are. On the other hand if things can be logically separated there is a lot of merit to doing that. Simplicity tends to make things easier to manage, and less error prone. Also as teams grow or increase in number working inside of the same monorepo tends to be more problematic. Especially in the case where things aren’t tested as well as they should be.

All of these questions are much harder to answer for an already existing project. People are adverse to change, and to be honest if you have something that is working you should have good reasons for changing it outside of “This is just a better design.” As it turns out a well architected piece of software that doesn’t work is much less valuable than something that is currently working.

I look forward to reading more (read as stealing ideas) about how they’re solving these problems.

As a side note everyone should flip through this presentation about the Netflix culture of freedom and responsibilty. There are a lot of great points about valuing behaviors over mottos. Hiring smart people and allowing them to do great things for you, etc. that everyone should read. Especially if you’re in a position to impact culture where you work :)