Coding the Architecture - design tag

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.

Start with the big picture

Wed, 18 Nov 2009 08:05:57 GMT

One of the hardest things about the software architecture role is being asked to come up with a software architecture when all you're given is a set of requirements and a blank piece of paper. It's certainly one of the most fun parts of the role, but it can be a daunting prospect trying to figure out where to start and what to do. Many software teams dive straight into the code and this can initially be very productive but many teams soon start to venture down the slippery slope of constant refactoring while they try to find a design that works. Often, a little forethought is all that's needed to get the architecture definition process heading in the right direction. So where do you start?

Read the full essay...

Testing Times

Fri, 26 Sep 2008 13:09:00 GMT

Having recently taken another look at my project's unit testing strategy I thought I'd share some of my thoughts on how I see unit testing as just another force on the system's design. As such it needs to be weighed in the balance with the other forces.

Unfortunately it's a force that tends to get more influence than it perhaps deserves, not least because it's a force typically backed by the development team.

Designing the tactical solution

Wed, 27 Jun 2007 20:16:00 GMT

In my previous post I asserted that there's really no such thing as a tactical solution, but what should you do if you are asked to design one? Before I answer that, let's summarise what a tactical solution is all about.

... a tactical solution can be thought of as a stopgap. It's an interim solution. It's something potentially quick and dirty. It satisfies a very immediate need. Importantly, it has a limited lifespan.

Tactical solutions are all about fast delivery and limited lifespans. You need to take *both* of these into account if you are asked to design a tactical solution because they will undoubtedly influence your design decisions. Let's look at each in turn.

Fast delivery
Compressed timescales will alter the way in which you tackle the design process, so here are my suggestions for dealing with this.

Don't agonise over design decisions. Do the simplest thing that could possibly work in the available time and then stop.
Be explicit about what your solution will and *won't* do. If the timescales have made you choose a design with limited future extensibility and flexibility, make this explicit so that everybody (including the stakeholders) understands the trade-offs that have been made and the impact they have in the future.
On a similar note, make sure any assumptions you're working with are known by everybody.

Limited lifespan
A limited lifespan typically provides you with some boundaries for your key non-functional requirements and you can use this to your advantage.

A tactical solution with a one year lifespan means your solution (in theory) only needs to scale to support data volumes for one year (plus a bit for safety). This makes some design decisions much easier, such as whether you need to design a solution that is horizontally scalable.
Be explicit about what your solution will and *won't* support. If the limited lifespan has influenced your decision to build something that is simple rather than highly scalable, make this explicit so that everybody (including the stakeholders) understands the trade-offs that have been made and the impact they have in the future.
Again, don't agonise over design decisions. Do the simplest thing that could possibly work for the anticipated lifespan and then stop.

As Kevin commented, a better approach to building a tactical solution is to make it the first delivery of a larger and more strategic solution. Sometimes this isn't possible though and delivering a solution with a limited lifespan in compressed timescales means that you have to make some trade-offs. If you find yourself in this situation, don't agonise over design decisions and make sure you're explicit about what the solution will and *won't* do.

Simplicity

Fri, 17 Feb 2006 21:24:29 GMT

As an architect, you'll undoubtedly be called upon to make decisions about how a particular requirement should be fulfilled. Remember, you bring together the appropriate balance between functional and non-functional requirements to produce what the end-users need. However, some decisions are easy and others are hard. To take an example, imagine that you're building a new website to replace a couple of sites that exist already. Also, let's say that all users of the new website must re-register their accounts in order to consolidate their logins across the existing sites.

Now, clearly there several ways to make this happen. The first of these is to provide a transparent re-registration process so that users can enter their existing username/password combination. Upon logging in with these credentials, an initial attempt is made to authenticate them against the new consolidated authentication realm and, when this subsequently fails, tries to authenticate them against the existing realms. Assuming that the user is authenticated against one of these existing realms, their credentials are then automatically migrated into the new realm.

Ideally, this is great because users can just use the new website without any knowledge of the re-registration process because they use their existing username/password as normal. From a technical perspective, however, this raises some interesting issues, particularly if you want to take advantage of something like Java EE's container managed authentication or any other mechanism that expects you to perform authentication in a specific way. True, you could customize a security framework (such as Acegi) to incorporate this credential migration behaviour, but would you really want to pollute a simple authentication process with it? Think about how difficult this would become to implement/test and what happens if a particular username is shared by different users across the different existing realms?

There is, of course, a much simpler solution whereby the user is offered a facility to explicitly migrate their account via a "click here if you've not used the new site before" link. Just think about it. No complex authentication/migration logic and the user knows exactly what's going on because you can explicitly ask them for a specific username/password combination.

For me, the latter solution represents something that's much easier to design, build and test, which leads me to imply that it's going to be developed quicker. Also, it's potentially more secure and can easily be "switched off" when it's deemed that all users have (or should have) migrated their existing accounts.

Simplicity is something that an architect should strive for, especially when the elements (such as time) are against you. Clever solutions are often complex, but simple ones can be clever. Always strive for simplicity.

The Top Ten Ways to Botch an Enterprise Java Application

Wed, 25 Jan 2006 13:28:33 GMT

If you're planning on heading to JavaOne this year, Cameron Purdy will be presenting what sounds like a very interesting talk on the top ten ways to botch an enterprise Java application. From his blog...

Two of my presentations were accepted for JavaOne, including a new one that I've been working on: The Top Ten Ways to Botch an Enterprise Java Application. I think the hard part will be limiting myself to only talking about ten of the things that I've seen! ;-)

I've given some funny (and unfortunately real-world!) anecdotes as part of some of the presentations that I've done on scalable performance and distributed caching, including the "checking the HR database on each HTTP request to see if the current user got fired since his/her last HTTP request" (one of my favorites). So what is your personal "Top 10 List" for ways to completely botch an application?

Reading through the comments, there are some funny stories and I only wish that I could say I've not seen these myself. One of the best ways to learn about architecture, what works and what doesn't, is to listen to others talking about their experiences. If you're at JavaOne, don't miss this opportunity.

High-Assurance Design

Wed, 18 Jan 2006 20:11:09 GMT

This week, Cliff Berg is doing a promotion of his latest book entitled High-Assurance Design : Architecting Secure and Reliable Enterprise Applications. I'm sure you've encountered this yourself, but on many projects there's often a disconnect between the development team that build the software and the security experts that reside elsewhere in the organisation. I've certainly seen this happen and due to the different skillsets involved, it's hard to get these two groups of people talking the same language. As a result, security is often inadequately implemented and reliability ... well that sometimes doesn't even feature.

If this sounds familiar then Cliff's book might be for you. Stop by the OO, Patterns, UML and Refactoring at the JavaRanch Saloon to see the discussion and have the chance to win a copy.