Microservice Re-architecture Part 3: Performance Paranoia

Tags: microservices

This is part 3 of a series of posts about the re-architecting of a monolithic web application to microservices. Today's topic: performance!

Our proposed microservice architecture is, among other things, a bunch of REST services. The idea of going over the wire with http requests for data that used to retrieved from a join in MSSQL is a scary one. That's guaranteed to be much slower than before! Yikes!


One of the early conversations we had in our design meeting and informal discussions was how we should not do this. This will kill performance!

Core Objects

One of our microservices' domain boundaries contains our core business objects. This is the hub; the service most of the other services will need. We call this our Management Service.

Monolith Thinking

A decision was made to directly reference the repository of the Management Service in the other services, or at least the ones with performance concerns. Unfortunately this is completely against the core concept of a microservice architecture. We've just gone and coupled our services together again!

Coupled

Our data access technology for our microservices is Entity Framework. Our Repositories return IQueryable so we can create linq queries at the business layer that will translate to SQL joins in the DB. Directly referencing the Management Repository DLL means one domain will actually end up joining on the back end to the management schema in MySQL! That means we are coupled all the way down to the DB level! Red alert!

Don't Be Scared

I pushed back pretty hard on this idea. I urged that we can use a direct reference if and only if we have some kind of critical performance emergency that we cannot dig ourselves out of. There are plenty of other avenues to exhaust to improve performance that adhere to the domain boundary restrictions of microservices before we make this direct coupling decision: in memory caching, data replication, etc.

The Righteous Path

Fortunately my team agree with keeping our domain boundaries actual boundaries! We have reversed our decision to directly reference one domain's dll from another domain. Unfortunately there is some unwinding of code that needs to be done, but we are on the right path.


Check out part one and two of this monolithic series of blog posts :-)

No Comments

Add a Comment