There are at least two things that spring to mind when thinking about microservices or decomposition in general. The first is that large projects and code bases tend to be full of risks. The more code you have the more complexity you have, which makes it hard to manage, debug, etc..
The other thing is that good companies allow their people to experiment. This can come in many forms, of course, but one important one is the ability to grab code from a repository, build it and mess about with it. If the code has tests, great, but even if it doesn’t you can experiment a bit with refactoring and see how much you can learn before you blow the whole thing up. The key to this sort of experimentation is that the systems have to be easy to build and run. Keep that thought in mind.
In many companies we visit, code is not easy to build. In the same companies there are often pushes to continually integrate code or even to continually deploy it. But code has to want to be continuously deployed.
Spotify have a great culture of engineering, at least they do according to the things they write about. Three of their principles are:
- Minimise the Risk of Big Projects
- Experiment Friendly Culture
- Internal Open Source Culture
I think the third point is vitally important as an enabler to the second point. If you can’t get stuff built quickly then you put a barrier up to experimentation. When I think of an open source culture the first thing that springs to mind is that it should be easy to grab the code, build and deploy. If a company's code fails that simple test, then they shouldn't be thinking about continuous deployment or microservices but rather the boring basics of software delivery and deployment. A return to the boring basics is often as simple as finding a manager who actually gives a shit about the state of the code.
Previous article
