Many years ago, after working with PHP for about 8 years, I was pushed to start development in Python for the first time. My mentality at the time was to focus on one thing and become the expert on the subject. I wanted to be the expert of PHP & MySQL world and thought moving away from it would make me less focused on the subject.

I was very resistant to this change and facing a new world.

As I delved more into Python and learning it, I realized I was solving almost the same problems but in a very different approach. Features of the language are very similar, but the way they are used is different. The community of Python developers approach problems in a different way than PHP developers. I started learning their approach and how they thought and approached problems. And started liking it.

As I became more comfortable with Python, I started thinking through problems differently. Since I knew two languages, I had the option of approaching problems in two different ways. Whichever best solved the problem, won.

A few years passed, and again I switched projects. And again, I learned another language: This time, Node.JS. The language was not new to me, but the stack was. But just as I had lost my prejudice on programming languages, I was willing to take the opportunity to learn the platform and polish my skills.

I learned that in practice that each language has its own advantages and each is good to solve particular problems. The more I learned different technology stacks, the less I became biased in solving problems with a certain technology stack or language. When thinking about solving a problem, I spend most of my time thinking what the problem actually is, the best approach to solve it, and what tool fits the best for that approach. I then pick the best tool for the problem out of the toolbox.

Being technology and language agnostic helps the development teams to approach the problem with the best possible tools but also introduces its own business values and challenges. When you use the best tool for the job, development time decreases, the code base simplifies, and you stand to see an increase the overall performance.

However, as with any other technological and architectural choices, there are advantages and disadvantages associated with Polyglot technologies.

Simply solving the problem

When choosing multiple technologies to co-exist in an environment, the goal is to pick the best solution for the problem in hand. By picking the appropriate technology the implementation become easier and simpler.

So if you are building a bi-directional notification system, you can choose the technology stacks that are most suited for this. Or if you want to have high performance data throughput, there are variety of different technologies to look at.

Of course a single language is capable of doing a lot, but when you pick the stack that’s more appropriate for a particular problem, you will have less time spent on trying to bend the problem to fit with the capabilities of the chosen language.

Performance

No single language is best at solving all problems. When it is needed to solve a problem with a specific technology which is not designed for that, it takes more time from the development team to handle it. Also it is very probable that the actual performance is affected by numerous tweaks that developers had to do. Also usually more work is involved to adapt a technology to do something which is not initially designed for. By picking the right technology stack, not only it reduces the development time, but also the overall performance of that component is highly affected as well.

You have a toolbox, not only hammer

When you have variety of tools from which to choose, you will pick the tool that is best for the problem, not the one with which you are most comfortable.

Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” When the development team has more tools in their toolbox, only nails look like nails.

Team of full-stack developers

I believe architecture of a software application is a collaborative responsibility. Everyone in the team should have a firm understanding of the architecture.

The architecture includes the full spectrum of the software development, build, deployment, and operations. Everyone in the team should understand the big picture of what is happening under the hood. This helps the entire team to have inputs for the architecture of the application and everyone is equally responsible. Also in cases of emergencies, every individual within the team is capable of jumping in and help.

DevOps and Maintenance

Operation of Polyglot systems is the biggest concern for development team.

When the number of different technologies grows, it becomes more difficult for the DevOps team to maintain the application and infrastructure. Each language and technology requires its specific environment, setup, and skill set to monitor and maintain.

Complexity of a system grows exponentially. The more complex a system gets the more difficult it becomes for maintenance.

No better time than now

Being able to use polyglot technologies and programming languages is not a new idea. Throughout the history of software development there have been many attempts to facilitate this and make integration of completely different technologies easier. CORBA, Java RMI, and different RPC methods are all examples of different approaches to solve the same problem; acting as a liaison to make different technologies communicate with one another.

It has never been easy to do so. Each of these technologies has its own drawbacks, which made them popular for certain situations. But with the increasing popularity and growth of containers, it is easier to package an application with its dependencies into one isolated image, which in turn makes it easy to deploy anywhere. Containers, in combination with microservices, makes polyglot technologies a good solution.

In a microservices approach, an application is broken into several smaller services, each could potentially be built on a different technology stack. But when packaged in a container it is ready for deployment in any environment, a lot easier.

The beauty of microservices is the isolation of each component. You can assign a single responsibility to each component and use a technology stack that best solves that particular responsibility. Each component provides a standard interface with which the rest of the microservices communicate.

Conclusion

When facing a technical problem, being technology agnostic enables you to pick the best tool for the job. You can also break a problem in to several smaller components and pick the best suitable technology for each.

With the emerge of containers and microservices, it is more convenient than ever to build software systems consisting of several different technologies and have them communicate with one another. One main concern is complexity. The more technologies we have, the more complex it becomes to monitor and maintain a system.

Software engineering is the science of knowing and understanding the tools and picking the right ones for the job.

RV Tech has been a great example of this. In the past few years, we have been able to decouple our monolith applications and break them in to tiny microservices and use variety of different technologies to solve our problems. The beauty lies under the fact that we don’t necessarily need to be certain for a specific technology when we are picking it. It’s small enough so it can be easily replaced. Relatively!