By the end of the sprint they ship a new set of services to production without having to coordinate with any other teams and also more importantly without having to modify a single line of code in any existing applications.
Why Companies Adopt Microservices And How They Succeed
Asim Aslam

I do not want to pick on the author of the original piece, which has much more than this line and many good points, but I see this reasoning as support for microservices so often that it boggles my mind. As someone who successfully led a migration from a monolith to microservices (nb: it took about 2 years to do, so you know, prepare yourself if this is your desired path), I have basically never seen this happen, and I am constantly perplexed at the suggestions that this is an easy or common thing to do. Something is missing. What is it? Well, most fundamentally, the missing component is the data.

Let’s start with the basic question: what is implied here? The implication here is that you have access to all of the data you could possibly need, and that you are capable of independently storing any data you decide you must produce or pushing that storage off to some independent storage apparatus that is itself functioning as a service. On the former point, this can happen. If you have a very well-specified overall system that is fairly stable in its data, maybe you can simply spin up a new service that just recombines existing data into new exciting functionality. I would say that accounts for a very small fraction of actually valuable features, but ok, maybe outside of the spaces I’ve worked there are more valuable features to be made this way. Of course, if you have a very well-specified system, you probably already have services that are accessing and combining the data you want. Is this functionality really so unique as to justify a new service? Why in the world do you want to put new services into production just to avoid having to talk to another team or work in an existing code base, all for a 2-week project? I’m sure that there are good cases for this, hell, I’m pretty sure my team did it once or twice, but you know what? Most engineers are far better at modifying existing systems than they are creating completely new ones from scratch. Two weeks to redo the work of speccing out the service, dependencies, writing tests to make sure the basic stuff is all working, then finally putting the business logic in there? I’m skeptical.

Ok but what about the cases where you’re actually producing new data, or worse, you need something changed in existing data. Let me be clear, I’m not talking about throwaway data, stuff you can act on and discard, I’m talking the fundamental information that you store to run your business. New features that touch and change this data are far more common, at least in my personal experience, than features that merely operate on existing data. So you need to think about what it means to take that fundamental data and change it, because there are big implications to doing that in an uncoordinated fashion. Do you really want to have to aggregate over multiple sources of the same baseline data, say, your Users, to get the true view of that data?

At a certain scale having multiple copies and versions of this data makes some sense, you can’t possibly support all the systems needing data from the same single source of truth. However, for most of us, having multiple sources of the same data with slightly different features is a fucking nightmare for functional, analytical and debugging purposes. Maybe you have an oldschool “Enterprise Service Bus” where you publish all the data as it changes, maybe you implement this with some new cool messaging framework like Kafka, so now you just have to debug who is sending this garbage update to our user data that whoops is crashing the admin tool. I’m not sure what the ideal solution is for this, but I can promise you that having multiple services able to change the same fundamental data is a guaranteed headache, and it had better be SUPER worth that team independence to let people create and modify their own copies of fundamental data. Microservices doesn’t HAVE to mean the worst distributed systems problems you’ve ever debugged, but if you go ahead and let a bunch of people run roughshod over your data, you definitely will get there.

OK also what about the place where this baby service shows up to the end user. Is that a website? An app? Who is changing that code? Is that code encapsulated in your services or, more likely (at least in the app case), still in a monolithic-ish code base? You know, you can’t just go throwing something completely off-brand into the app because you had a cool idea, so you’re probably going to have to actually talk to that team and change that shared code base, unless literally the only thing you’re changing is the data that feeds existing functionality. Most valuable features encompass more than the sort ordering of results. I too thought that I could make it so that you would change some logic on the backend and magically the frontend would change its behavior without having to deal with messy UI code, and I was wrooooong. So wrong. There’s a reason we need all these great front-end developers.

Now let’s get to brass tacks. Your product team is speccing out features and success criteria that are fine-grained enough to get something valuable out in two weeks and learn quickly whether to keep it or not. And when you decide not to keep it? Who tears it down? When you decide to keep it, who supports it? Does your business have enough data to measure the success of new tiny features quickly? Enough volume of users? Is this feature going to move the needle enough to prove success in two weeks? You’re a big enough company that you want to do microservices, so you must have a decent number of developers (or pretty major up-front scaling challenges), but you’re small enough that big needle-moving features can be thrown together in a matter of weeks? Or are you just shiterating over tiny ideas that mean nothing? Are you so big that you have infinite resources to throw tiny ideas at the wall because even the smallest move can be proven out quickly? Well, if you’re that big, you don’t need to listen to me, or to the original author, you know what you’re doing. But this isn’t for Google. This isn’t for Facebook, or even for Spotify. This is for the companies trying to cargo cult an architecture that they don’t understand the value of, because people keep promising that it will cure them of the woes of coordination.

I haven’t even gotten into the fact that your microservices are an inter-dependent environment, as much as you may wish otherwise, and one service acting up can cause operational problems for the whole team. Maybe if you have Netflix-scale operational hardening that’s not a problem. Do you? Really? Is that the best place to spend your focus and money right now, all so teams can throw shit against the wall to see if it sticks?

Don’t sell people fantasies. This is not the reality for a mid-sized tech team working in microservices. There are enough valuable components to building out such a system without the fantastical claims of self-organizing teams who build cool hack projects in 2 week sprints that change the business. Microservices don’t make organizational problems disappear due to self-organization. They allow for some additional degrees of team and process independence and force very explicit decoupling, in exchange, there is overall system complexity and overall system coordination overhead. I personally think that’s enough value, especially when you are coming from a monolith that is failing to scale, but this model is not a panacea.

BTW, if you’re curious for more details on the good and the bad of completing such a rewrite, here’s a talk I gave on this topic.

A final note: the original author rightly pointed out that I said a cruel thing about him on Twitter. I agree, in fact, I deleted the cruel comment a couple of hours after writing it and before his mentioning it to me, and apologized to him for that. I did not delete any other tweets on the matter. I am sorry for my thoughtlessly unkind comment. The rest of this piece of writing I believe stands on its own merit, and I welcome technical feedback from those who have had different experiences with microservices than my own. It is a wide world out there and I certainly haven’t experienced all of it.