Daniel's Blog
The Office Monolith
3 min read | Last Updated: June 20, 2020
Breaking the Monolith
Let’s say you have a classic monolith system. All services write into the same database and the code is intertwined in truly spaghetti fashion. At some point, whether by choice or by unsolvable capacity problems the team decides that is time for the monolith to go.
The team sits down and carefully thinks on the architecture of the system. Perhaps you want to move to a domain-driven design and define proper boundaries before you start slicing out that monolith. You start with a somewhat decoupled service and slowly deprecate the monolith out of its current function.
The thing is…this takes time, a lot of time.
So..you don’t have time and the team starts to cut and paste code in a bunch of microservices, put an API in front of it, and shard the services data on their databases. Hopefully, you plan a lot of tech debt to iron out those distributed system issues and figure out all possible error modes and boundaries as you go.
Remote Working
Now let’s say we have a company where everyone is always in the office. Sure, you work from home here and there, but all the important meetings happen in the office. Maybe there is one person that starts hangouts or zoom on their laptop but there are audio problems and the one working remotely usually misses out a bit.
That’s the monolith.
Breaking the Office Monolith
While most companies are now working remotely, we are not really remote working companies. Because of lack of time, we declared everyone to work from home and defined our APIs to be Zoom and Slack. We just split the monolith in a rushed way without carefully planning it.
We have now spent a few weeks playing catch up with our remote ways of working (culture tech debt), coming up with new ways to communicate, knowledge and idea sharing, trust and virtually bond. And there’s so much work else to do.
The Monolith is Coming Back
The good news is that it seems that some people might start going back to the office soon. This means we will end up with some hybrid solution where some people will continue working from home and some will go back to the office.
The thing is, if you have split off some services out of the monolith and they are working perfectly fine (or even better!), you don’t really want a dependency back to the good old database. Same situation here, unless everyone is back in the office, you need to continue following some of the practices you have discovered while working remotely. Remember what it was like being the only one working from home during a planning session? Picture having half a team remotely while the other half is having a design session on a whiteboard. No, thanks.
Business as Usual
I see a lot of companies shedding all remote work and going back to business as usual. Why not? It was working before.
What will you do when everyone is back to the office? Will you go back to the old monolith ways or take some of the learnings with you? I know I will.
Written by Daniel Lopez Rovira who likes talking about engineering stuff.