Choose the stack technology based on your resources

The technology that we choose will affect our productivity in many ways. It is not about how secure, flexible, or cool it would be. It is also essential to consider how specialist your team has to be to handle them.

Some technologies require high specialization; sometimes, it is not apparent until things start going wrong.

SPA (Single Page Applications)

Leaving aside that I consider that the SPA approach is wrong most of the time, a Ruby on Rails team that decides to implement the frontend as a SPA will require some specialization on Node and frontend frameworks ecosystem.

Deployment

A small company with one or two services would be enough to deploy using Capistrano or pay for some PaaS like Heroku instead of managing a complex Kubernetes or similar setup. In any case, I would not expect that the same group of people can develop backend, frontend and also be up to date in all the knowledge required to manage a proper Kubernetes infrastructure.

(Micro)-Services

Before deciding to extract or implement a new feature as a service, the same company should consider the deployment and maintenance of the new service. If they are using Capistrano, it will mean a new set of servers to manage. If they are using a PaaS, it will mean spending much more money.

Event Sourcing

It is another trend in software development. There are valid use cases for this approach. Still, it entails high specialization for managing specific services like AMQP or Kafka, understanding the new technologies, researching the ecosystem for your base language, and sometimes introducing a new language.

New languages, frameworks, databases, and so on

The introduction of microservices and platforms like Kubernetes will allow experimenting on production with more languages, frameworks, and databases. All these new technologies require expertise for a good and reliable service.

If you are willing to switch to something different because you have many troubles with your current stack, consider that the new one will bring new issues and drag the ones that belong to other components of your stack.

Final thoughts

A high specialized stack requires specialized teams and makes it harder to share the knowledge and responsibilities.