I've noticed that my company has adopted a microservices architecture for a semi-internal system. While I understand the appeal of microservices for scalability and reliability, this implementation seems unnecessarily complex. Essentially, they've set up multiple instances of PostgresSQL databases, each serving as a separate 'service' via PostgREST, but they all share the same minimalist structure—two columns with an ID and a JSONB column for data storage. Why not just use NoSQL instead? Additionally, they employed Kafka for messaging, which seems excessive given the expected message size.
It feels like this design was influenced by someone keen on showcasing their skills for a big tech company rather than serving our project's needs. We only have a handful of internal users and will generate modest amounts of data each month. I really believe that we could run this system effectively on a single laptop using Flask and SQLite.
However, management is pushing for everyone to adopt this microservice approach across other projects. I seem to be the only one expressing concerns, and many senior staff don't have programming backgrounds, which makes it tough to advocate for a simpler solution like a monolith. Am I wrong to think this way? Should I voice my concerns more forcefully or accept the current direction?
5 Answers
I feel you on this one! It seems like the consensus is leaning towards a misguided optimism about microservices. Keep in mind that just because it's trendy doesn’t mean it’s the best fit for every scenario. If you find things aren't making sense, a friendly chat with a manager might clear up some intentions behind the architecture choices. It's also a chance for you to express your concerns without coming off as overly confrontational.
I've worked with microservices before, and they can definitely provide benefits like independent scaling and faster development cycles. But, if the teams aren't separate or the project is small, sticking to a monolith might be wiser. Operation costs and how the system scales are key factors to consider. In your case, it might make more sense to use a simpler architecture. Check if they might be using microservices as a way to experiment with new tech rather than actual project needs.
Honestly, it sounds like a design looking for a problem to solve. Go ahead and build what you've been tasked with—sometimes the best learning happens by seeing how these decisions play out in practice. If it ends up being a mess, you'll have the experience to bolster your resume regardless. If you're truly unhappy, it might also be worth exploring other job options where you can have more influence over the design decisions.
It sounds like you've encountered a classic case of over-engineering. Microservices can be fantastic when done right, but from what you described, this setup seems like a distributed monolith that complicates things unnecessarily. It's worth talking to someone in charge about your concerns—especially regarding how the architecture aligns with the project's actual needs. Maybe there's more to the design that you're not seeing, or it could just be a poor decision based on buzzwords without practical application.
You've raised some excellent points about the design's complexity. If this system stays small and manageable, sometimes it's okay to experiment, as long as the stakeholders are satisfied. Your input is important, so sharing your perspective clearly can help guide decisions without stepping on toes. If they want to explore microservices, just document the challenges you observe. You'll learn a lot from this experience, regardless of the outcome.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically