Should we allow different technology stacks in a micro services landscape?

April 11th, 2019 Software Architecture 'Handmade Ravioli' by Davide Ragusa on Unsplash

Don't worry, I'm not going to explain how to create ravioli. That's not my piece of cake. My daughters recognize my style of cooking by the boil-over fires. Some time ago I saw a caricature of comparing software architecture to Italian food, micro services were compared with ravioli. I was wondering whether or not we should have different technology stacks in a micro services landscape, so I wrote it down. Buon appetito!

Knowledge and experience

The world of tech is moving fast. It has been moving fast for decades, however it seems to me that it's going faster than ever. This might be due to the fact that the market is asking for full-stack, whatever that may be. I will dedicate a future post explaining why I think full-stack is bullshit. If you don't have readily available knowledge of at least a couple of dozen technologies you might feel not as effective as your colleges that do understand those technologies. This is already the case when you're only working in a single stack of technology. So I don't believe in developers being elite in multiple platforms. Of course there are exceptions that confirm this rule.

So within one developer you preferably specialize in one stack. If you're doing scrum you might be able to do some stacks with overlap in frontend technologies, but still being effective means you choose one technology stack for the team. And to be honest if you have multiple teams building software in your company, you would loose flexibility it moving members between teams if they work on different stacks of technology. Not that moving members between teams helps in scrum, but that's yet another story.

Micro services in an enterprise environment

Architecture in an enterprise is never build on a mono stack. One of the things you'll notice within enterprises is the large amount of different technologies that are used. This is partly caused by off-the-shelve products that have been purchased regardless of the technology they are build on and are customized to the needs. The other part is caused by the slow movement of changes within an organization. If you look at the past decades, we've seen things like Corba, Service-Oriented Architecture, Restful APIs and now Micro Services. It's not strange that we see some pieces of each in an enterprise organization. Those new architectures come faster than light!

But let's be honest, we understand choices like best-of-breed, but is it ideal? For those who never heard the term best-of-breed, it basically means choosing the software that matches the functional requirements best. This could mean the choice for SalesForce as the CRM system, while this would not necessarily fit in the infrastructure and technology knowledge within the company. This is a total different world compared to the past, SAP for everything, or Microsoft only environment. But still apart from the standard software there's enough custom build. I think it makes sense to choose one stack for the custom build software. So either go for Oracle Java, Microsoft .NET or Node JS, don't combine everything if there's no absolute need for this.

Intra micro service communication

Early evolutions of micro services quite often use Restful APIs to communicate to each other. It's good to build upon a standard, but to be honest, I'd rather both consume my Restful API and produce the Restful API in the same technology stack. Integration will be just easier. This is no different when using a message broker like RabbitMQ instead of APIs. Even though we serialize contracts to JSON and use AMQP as a protocol, using typed contracts and same message bus framework all around the landscape helps you focus on build functionality. In the past I've had quite a lot of trouble using Soap between Java and .NET, the WS-* specs still give me shivers. I will dedicate a future post explaining why I think intra micro service communication should mostly be based on messaging.

Best technology matching the functional and non-functional requirements

Sometimes you will see the need for a micro service that has some functional or non-functional requirements that can be implemented much easier in some different technology stack. These situations aren't even rare, quite often it's just a matter of using a different storage technology. Instead of using a regular RDBMS like SQL Server or Oracle you might see the need for key-value database like Redis or document database like Azure Cosmos DB. Somehow we accept something like that easier than suddenly adding Linux to the stack where Windows Server was the standard, or creating a very specific Restful API in NodeJS instead of the standard .NET Core based Web API. The truth is all have similar pain, it's not standard within the company yet. So that means not every developer has understanding of this new technology, yet. But more important this technology needs to live somewhere in production so the operation guys that maintain your production environment need to know how to run this correctly in production. Don't forget installing a MongoDB on your dev box is not the same as having it in a production environment where availability and security has different needs. You don't want to be the company where your MongoDB is held hostage.

I'm not saying you should always prevent to introduce new technology, but do it with care.

No conclusion

These were some thoughts that came to my mind. There are probably more viewpoints to this topic, but it's enough for now. There's no real answer to this question, I think. The only valid answer: It depends. So if you are in the situation where you think too much or too little technology is introduced within your micro services landscape, you have some of my viewpoints.