[xmcqdpt2]

The example in the article doesn't make sense to me. It basically says "You want to switch out a piece of a monolith to a new service, you do it with feature flags etc. That's hard." Which is true.

But then it says "Steel Threads is better. Instead of switching out a part of your monolith, you... switch out a part of your monolith but it's a smaller part. That's not as hard". Which is true but isn't that the same thing? It's not clear to me what the qualitative difference is that requires the introduction of new terminology?

[prmph]

Exactly, not sure what new insight this post is supposed to provide. On the other hand, sometimes switching over gradually, one small part at a time, actually increases the complexity of the whole migration.

[ta988]

Especially when you now have to sync two data stores and one only has a limited feature set.

[wwilim]

It provides a useful metaphor

[TeeMassive]

The main difference between the two is that the cutter approach means that the two features must coexist at more or less the same place in the code and that the architecture must be adapted to accommodate this half-dead half-alive chimera.

In the end you have three states two deal with with the code before the new feature, the chimeric code and then the code with the new code enabled.

With the steel thread approach the feature exists on its own and is used and tested in production at the very beginning, although with limited traffic first. Important to note that the author seems to assume a micro-service architecture.

[iandanforth]

Agree, when I'm looking to pull out a service I'm often looking for state boundaries. Is there some part of state or a data model which is separable? If so I can abstract around that and pull it out. If I try to pull out something smaller then I end up in trying to run a service with a split-brain backing datastore, which is far more problematic IME.