Languages and Architecture — The Importance of Being Language/Architecture Agnostic

Today, I decided to discuss languages and the importance of being language/architecture agnostic.

Main

Firstly, I observe that the backend world is rediscovering itself and criticizes microservices architecture. For example: Amazon Prime recently reverted to a monolithic structure. For me, the key idea is that we shouldn't blindly follow all mainstream trends. Rather, we should carefully decide which architecture to choose. Maybe the optimal decision for you is to either stick with a monolith or strike a balance between monolith and microservices.

Following that, Tobi demonstrated that Rails can now be fast and exhibit high performance. Let's delve into it. Ruby on Rails is often regarded as a framework for startups, providing faster development of new features – a reputation that holds. However, when modern Ruby is combined with contemporary Rails, in capable hands, it can deliver speed even in the late stages of a product's life cycle.

Now, let's consider PHP. This language has a bad reputation because it has a low border to enter and if you want to achieve fast and cheap product development you can do it with PHP. In my career, I saw that spaghetti code and mutant architecture can be produced even on fancy Golang or old-school C#/Java. Hence, projects with low maintainability can be agnostic to language and architecture.

Examples

A few years ago I joined a project that was rewritten from Java to Golang (monolith to microservices). However, the team decided to rewrite the code to another language at first and then extract microservices from it. I think that decision was made because Golang is fancy and it's cool to use it and microservices. However, progress was stopped when a few micro-services (like authorization and some other user services) were implemented. So, after some speed improvements from faster user login and increasing database health. We stumped with a huge half-monolith legacy in Golang that was hardly comprehensible by newbies in that project. Also, it was hard to sell continuous extraction to micro-services to businesses to whom a monolithic architecture and Golang would have been sufficient.

Additionally, I can provide a positive example wherein a 10+ TB database was split into distinct databases, each serving specific purposes and supporting discrete microservices. Originally, it was a Ruby on Rails monolith, but due to load growth, certain components were extracted and transitioned into Golang microservices. These modifications caused development velocity improvement and added the ability to sustain high load

Pieces of Advice

Besides, you have to think over the use cases of your product. For example, maybe you want to analyze how your clients operate with your product. Or you need some monthly report that locks database tables for a long time. So, maybe you need to move analytical work to another service or database. And you always have to think and google about ready solutions instead of reinventing the wheel.

Looking forward I hope that all mainstreams will be closely inspected before applying it to a real project. Because now, leading opinion can be just wrong and cause a lot of trouble with understanding and maintaining in the future.

Conclusion

Ultimately, I want to ask you: What will you choose or how will you adapt and work with various concepts of architectures and languages?

What will be your choice?