Monolith First (2015)
111–120 of 356 posts
Re: Monolith First (2015)
#112From my experience the issue with monoliths is organizational and cultural first, then technical (maybe). Monoliths are usually managed by 1 team (IT for instance). This 1 team has never had to collaborate with other teams on building/configuring/improving the monolith. Centralizing things works well for stability but it is horrible for innovation. For instance, ERPs like SAP are monoliths, how do you inject, say, an AI algo to improve productivity on managing invoices into it? That team pushing for that AI is probably super close to accounting but probably far from the SAP IT team. The SAP IT team is incentivized on stability while the accounting one on productivity, how do you resolve the conflict? How do you work together and collaborate? I am sure microservices have many issues, but they make these conversations not just easier but necessary. I think this is the biggest advantage of microservices.
Re: Monolith First (2015)
#113Here is interesting comparison of Microservices vs Monolith https://www.n-ix.com/microservices-vs-monolith-which-archite...
Re: Monolith First (2015)
#114Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this…
I think my biggest gripe with orgs that adopt microservices is they don't build out any of the testing, CI/CD, monitoring and debugging workflows to support it. It goes from shitty, slow monolithic application that super-pro can debug in a few minutes to.. Slow, shitty disparate services that are managed by different teams who don't share anything, suddenly you've got a Cuckoo's Egg situation where 1 guy needs to get…
I think this nails it. It's not the concept's fault if the implementation is half-assed.
Re: Monolith First (2015)
#115I always use monolith when building my servers. Only split microservices part when it is really required. Particular example:
I've built native C++ server that does some complex computations in some business domains.
When this monolith exposes generic JSON RPC based API where agents (human or software) can connect and do various tasks: admin, business rules design and configuration, client management, report design etc. etc. based on permission sets.
Now actual business client came. They have their own communication API and want integration with our server and of course being "customer is a king" they want communications tailored to their API. I was warned that this customer is one of many more that company is signing deals with. Not gonna put Acme specific code into main server.
This is where microservice part comes. Just wrote a small agent that mediates between client API and ours. Not much work at all. Come another client I can add more specific parts to this new microservice, or give it to other team to build their own based on first one as a template.
Physical scalability - I do not worry about. We re not Google and will never be due to nature of the business. Still main server can execute many 1000s of requests/s sustainably on my laptop (thank you C++). Put it on some real server grade hardware and forget about all that horizontal scalability. Big savings.
Re: Monolith First (2015)
#116Brilliant article Martin and brilliant discussion Hacker News. This is why this forum is still the best.
Re: Monolith First (2015)
#117Re: Monolith First (2015)
#118Earlier quoted context omitted.
It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case. The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.
But the network is so slooooooowwwwwwwww. Don't get me wrong, sometimes it's worth it (I particularly like Spark's facilities for distributed statistical modelling), but I really don't get (and have never gotten) why you would want to inflict that pain upon yourself if you don't have to.
I heartily agree. Don't treat yourself like a 3rd party.
Re: Monolith First (2015)
#119Not even just microservices. Even just unnecessary layers or tiers.
I'm working on a project right now trying to spin up the infrastructure in the public cloud for a simple application that some bored architecture astronaut decided would be better if it had an "API tier". No specific reason. It should just have tiers. Like a cake.
Did you know Azure's App Service PaaS offering introduces up to 8-15ms of latency for HTTPS API calls? I know that now. Believe, me I know that all too well.
To put things in perspective, back in the days I cut my teeth writing "4K demos" that would be added to zip files on dialup bulletin boards. In those days, I carefully weighed the pros and cons of each function call, because the overheads of pushing those registers onto the stack felt unnecessarily heavyweight for something that's used only once or maybe twice.
These days, in the era of 5 GHz CPUs with dozens of cores, developers are perfectly happy to accept RPC call overheads comparable to mechanical drive seek times.
I can hear the crunching noises now...
Re: Monolith First (2015)
#120Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this…
> There are actually ways to manage huge monolithic application that don't require each team to have their own repository, ci/cd, binary, etc.
Would be interested to hear about some of these.