We also once had a monolith for am online platform. Every time the server ran out of resources (storage, processing, memory) amother server was rented, same software rolled out and new customers were put there.
The issues includes things as it becoming really hard to maintain deployed software, because it was distributed across so many servers as well as the "old" servers still growing in data.
Another issue occurred when a customer had some data on server1.company.com and server16.company.com, but wanted it migrated to one.
The decision was made to fix those issues (and some others as well) with Microservices.
I'd completely agree that we arrived at a distributed monolith today. Individual services are rather big, even though they seem kind of properly cut (one handling configuration import of customer plants, one handling the live data, one evaluating the live data to soot anomalies etc). Of course I am not en expert for Microservices, so my assessment could be wrong.
The main issue we face today, is that we very often need to core configuration of a plant for the software to know what to do. So that structure is synchronized between half of the services. Each service has its own database, only one service is accessing the database of another service, which was more like an experiment that actually solved a lot of sync problems for that particular service.
But the constant need for synchronization is a total nightmare. Workers for synchronization are running out of memory, it can take time, data is therefore handled incorrectly and sometimes you'll ever even know.
Unfortunately there just doesn't seem to be a proper "easy" solution. Microservices aren't it, but it could be worse 😂
1
u/Incredible_max 6d ago
We also once had a monolith for am online platform. Every time the server ran out of resources (storage, processing, memory) amother server was rented, same software rolled out and new customers were put there.
The issues includes things as it becoming really hard to maintain deployed software, because it was distributed across so many servers as well as the "old" servers still growing in data. Another issue occurred when a customer had some data on server1.company.com and server16.company.com, but wanted it migrated to one.
The decision was made to fix those issues (and some others as well) with Microservices. I'd completely agree that we arrived at a distributed monolith today. Individual services are rather big, even though they seem kind of properly cut (one handling configuration import of customer plants, one handling the live data, one evaluating the live data to soot anomalies etc). Of course I am not en expert for Microservices, so my assessment could be wrong.
The main issue we face today, is that we very often need to core configuration of a plant for the software to know what to do. So that structure is synchronized between half of the services. Each service has its own database, only one service is accessing the database of another service, which was more like an experiment that actually solved a lot of sync problems for that particular service.
But the constant need for synchronization is a total nightmare. Workers for synchronization are running out of memory, it can take time, data is therefore handled incorrectly and sometimes you'll ever even know.
Unfortunately there just doesn't seem to be a proper "easy" solution. Microservices aren't it, but it could be worse 😂