# Microservices to drive agility

True monoliths are difficult to change. But, difficult change is _bigger_ than overcoming spaghetti code. Ask yourself, if you were modifying a couple of lines of code, how long would that change take to make it to production? For many organizations with monoliths, that answer would be at least a month. A month is too long and does not inhibit agility.

It’s important to use the [microservice principles](https://samnewman.io/talks/principles-of-microservices/) as a guiding light so that there’s a payoff. The risk of microservices for the sake of microservices is a distributed monolith. [Distributed monoliths](https://www.infoq.com/news/2016/02/services-distributed-monolith/) and [nanoservices](https://dzone.com/articles/soa-anti-pattern-nanoservices) have the worst of both worlds: extremely complex, brittle, and difficult to change.

Here’s a great [litmus test](https://blog.newrelic.com/engineering/distributed-monolith-vs-microservices/).

Don’t have a monolith? Then there’s no need to create microservices. Don’t get caught in the trap - if you are not creating microservices, it doesn’t mean you’re building a monolith. It takes _time_ to create a monolith. It also takes _momentum_ to create a piece of software that is **that** difficult to change. But if you do have one, then microservices can help.