Is VM size an architectural smell?

Wed, 16 May 2012 08:01:04 GMT

A couple of months ago I went to an excellent set of talks at LJC night at QCon. This not only inspired my entry on staleness but also made me think about some more architectural smells.

Gil Tene from Azul spoke about the maximum size of VMs we all use. A quick show of hands indicated that the maximum size of VM heap memory most of us ran was 2-4GB. Gil argued, quite convincingly, that this was due to legacy issues with garbage collection but new techniques should make this limit redundant.

I sort of agree... However, even if all the issues surrounding garbage collecting large VMs is solved, the 2-4GB limit is still a useful one.

In Architectural Smells I argued that there are architectural smells in the same way that there are code smells (aspects of a system that indicate but not guarantee a possible issue) and the example I gave was caching. I also think that VM size is an architectural smell.

When designing complex systems one of the most common design guidelines is to split differing responsibilities into specific services. Non-functional requirements may complicate this but most of us try to avoid having all functionality in a single service. Certain services are obviously distinct and can be isolated. However it's easy for functionality creep to result in a service gaining a lot of responsibilities and this often results in a larger run-time footprint.

During testing this shows itself as a service requiring a large VM - certainly in comparison to other services. I view this as an architectural smell and analyse the service to see if it should be split up. (Easier if you have some form of lightweight and iterative design process.)

This is very similar to the code smell of long method. It's rare that your code size or service size starts out by being too large but tends to happen over time. This is a good reason why an architect can't just throw it over the wall but needs to stay involved with the project. As developers add code to the system the design might need to change.

Whether you take an absolute size or relative size will depend on your system in question. Personally, I get concerned when a service is larger than 1GB unless its prime purpose is data storage and even then the data should probably be clustered across services rather than in a single block - but that's an argument for a different occasion.

Using new technology will make it faster

Fri, 15 May 2009 10:57:11 GMT

I heard an interesting throwaway comment recently that I thought I'd share. To paraphrase...

The system is being rewritten with new technology, so it won't be slower than what we have now.

While it's true that new and updated technology *can* improve performance, it's also very easy to misuse that technology and come up with something that performs perceivably slower. I've seen this a few times, predominantly where simple websites have been rewritten using new technologies. One of the biggest contributing factors is that new technologies often provider "better" and more complex ways to solve the same problem. For example, it's easy to see how a simple two-tier web application could be rewritten with a web-MVC framework and a distributed middle-tier added to make the architecture more fashionably SOA-like. Here, the added complexity could result in net performance gains or losses, depending on how the technology is applied through the design and architecture.

There's nothing wrong with refreshing a software (or hardware) system with new technology, but it's naive to assume that performance won't degrade. New technology generally brings added complexity, and this complexity introduces more things that can go wrong. Any software/hardware architecture should undergo *some* non-functional testing before it goes live, and this still holds true for systems that are being rewritten as part of a technology refresh strategy. Don't assume anything ... test it.

Coding the Architecture - non-functional tag

Is VM size an architectural smell?

Using new technology will make it faster