I was cycling home one day and this thought popped into my mind: I’m trying to address the issues of multi-tenancy in software systems. In other words, that is to say that I’m trying to make it easier for several software systems to co-exist, as tenants, in the same piece of hardware. When we think about it from a software perspective, it is definitely novel – big names out there like Microsoft, VMWare, Salesforce, etc are working hard on this (each in their own way of course) and it’s a rather hot topic. Companies provide their employees with Microsoft Azure training and there’s this growing need to fit more (tenants) in less (hardware). Come to think of it, it’s a bit like what’s happening in big cities all over the world.
Wait a minute.
That’s exactly what’s happening in big cities all over the world!
And why does this matter, you ask. Well, we’ve been doing this with people and cities for the best part of a century, so maybe some of the problems we face in software have already been dealt with in the “physical world”. “Sure, Tiago, that’s obvious! Why are you still writing this blog post and not out there reading books on urbanization?”. Yeah, yeah, yeah… have you read the title of the post? How we can’t always learn from other disciplines.
Multi-tenancy in software engineering presents its own challenges. How can you compare the concept of software versioning to any concept of the physical world? Same goes for concepts like deploying several instances of the same piece of software in different servers. Surely we can’t deploy the same person across several buildings (well, quantum physics says we can, but let’s stick to classical mechanics for the purpose of this post) and we definitely don’t want to have a tenant with a bathroom on one street, the bedroom two blocks away and finally the living room in a different town. That doesn’t work for people, it’s not convenient, but it works for software. Software doesn’t care if it has to invoke method foo() in its own memory stack or if it has to wrap its request in SOAP and have it traverse all over the world to have it executed.
So what’s the point of this post, really? While it’s always good to have a broad cross-disciplinary view and keep an open mind and an eye out for other fields which might be (metaphorically) solving the same problems as yourself, it’s also very important to identify genuine problems in your field. Sure, resorting to metaphors is perfect to learn from other fields but these don’t always apply perfectly and when they don’t apply perfectly, my theory is that they are no good.
In other news, I just submitted my paper to WCRE 2012 
let’s see how convincing am I with my maintenance techniques for distributed systems…