I was in a meeting at work discussing deployment strategies for various SOA components. Let me take a subset of the problem as today's topic.
The issue was how to deploy a bunch of ESB instances and App Server instances onto server boxes. One of the infrastructure guys said he preferred to have one ESB instance and one App Server instance on each box for ease of administration. Now, since we were going to run the instances on virtual servers, I suggested that we not worry about it at a SOA topology level. We would only talk about virtual servers running ESB instances and virtual servers running App Server instances. If the infrastructure guy wanted, he could always run a virtual server of each type on each physical box and would then get what he wanted. He had the ability to tune the configuration, allocating 0.5 CPUs to each virtual server, etc.
He objected to that idea, saying the performance of the virtual servers was bad if he deployed them like that. He wanted to deploy one instance of the ESB and one instance of the App Server on each virtual server.
I said, "OK, then deploy the two instances on the same virtual server, but don't assume that they're on the same virtual server."
This statement was a bit too cryptic for the others in the room, and they asked me to explain. This is how I explained it:
Assume that you have to write a deployment script that installs one instance of the ESB and one instance of the App Server on a virtual server. There are at least two ways you could do it.
Script option 1:
DEPLOY_ADDR=192.168.1.2
# Deploy ESB to $DEPLOY_ADDR
# Deploy App Server to $DEPLOY_ADDR
Script option 2:
ESB_DEPLOY_ADDR=192.168.1.2
AS_DEPLOY_ADDR=192.168.1.2
# Deploy ESB to $ESB_DEPLOY_ADDR
# Deploy App Server to $AS_DEPLOY_ADDR
In both cases, the scripts will deploy one instance of the ESB and one instance of the App Server onto a single server.
However, in the first script, the two servers are assumed to be the same. In the second, they happen to be the same. That is the difference between tight coupling and loose coupling.
However, in the first script, the two servers are assumed to be the same. In the second, they happen to be the same. That is the difference between tight coupling and loose coupling.
In the second script, a simple change in the value of (say) AS_DEPLOY_ADDR to 192.168.1.3 will see the two instances running on different servers. This is not possible with the first script. Changing DEPLOY_ADDR to 192.168.1.3 will move *both* instances to the new server address but will not separate the two instances.
I was therefore recommending the approach exemplified by the second script - deploy the two instances on the same server if you must, but don't hardcode the assumption that they are on the same server into your scripts.
It took a while for this concept to sink in, but the idea was finally accepted.
I guess a decade of SOA experience has sensitised me to looking out for needless dependencies, but most people in IT still don't think this way. I wonder how much rigidity and subsequent operational inefficiency is in IT systems all over the world because people are not sensitised towards the elimination of needless dependencies.
2 comments:
Socioeconomics. The underlying principals from OO, the loose coupling, the design patterns and so on, emerge from the earlier works of Rational and those who preceded them. Their personalities wrt to computing were formed in the seventies and eighties, and things were about conservation, efficiency and meticulousness. These personalities contributed to the basic conceptual model of modern software thinking, but while these things were being adopted in the eighties,nineties and later, a consumerist Thatcher-Reagan deregulated debt-driven world was both formed and destroyed (2007 fin. crisis). The new paradigm was adapted from the internet bubble: bubble thinking, unlimited growth, exponential curves, short term profit, build a mess and sell it before the share price tanks. Everyone has been educated to sacrifice quality, precision and robust sustainability, for immediacy and rapid growth. This has led to a software engineering culture that is short on educated, thinking designers and long on firefighting reactionists. At the end of the day, it's a prolonged period of deleveraging and financial worry that will undo the damage that was left by the bubble years of 1980-2007.
Post a Comment