![[Avatar]](/images/avatar26.png){kind=avatar}
Michael Edwards
1p2 comments posted · 0 followers · following 0
15 years ago @ Online Aspect - Managing code releases · 1 reply · +1 points
Makes sense, but why not use one of the caching mechanisms? This will not just eliminate the need to do what you're doing, but will keep precompiled versions of all the code that ultimately can increase your speed by 2-100X.
15 years ago @ Feld Thoughts - The Beginning of the R... · 0 replies · +1 points
The problems described in this post loosely mirror those in, for example, a slightly heterogeneous Linux server farm where you have different revs of RedHat with slightly different system libraries and slightly different SATA and network controllers on the Dell boxes. We're at firmware version 2.01B instead of 2.01A on the hard drives...
In fact, you can be suffering from the above explicitly + vagaries in the cloud level services that appear in similar ways.
So, we could say that we've moved one step backward since across the total solution stack someone (like the cloud provider) is dealing with all of the same problems as before, plus new ones.
The promise though, is perhaps the cloud software will become much more advanced to the point that you end up with less problems than you had without cloud computing. Some of this might be opsware type solutions (as referenced in the latter article). On the macro level it will push people towards better real-time tracking of system faults and corresponding solutions that get rolled back into standard setups. Things we could be doing already, but often fall short of.
Specifically in regards to the SSH issue, hot starts should just work.
I would model the different issues with hot starts the way the database crowd, specifically Oracle (just for a standard), model ACID transactions. For instance, the system you describe sounds like it is supporting a 'dirty' or 'phantom' hot start capability.
The is-service-up question sounds a lot like asking 'did this transaction commit successfully?'
There are going to be a lot of strategies for optimizing the spawning and running of services. For instance, why not try starting 3 servers across a grid and use the one that is up first?
Advocating for that kind of technology will result in a better solution, but will also create a market environment where there will be higher demand for management applications.
In fact, you can be suffering from the above explicitly + vagaries in the cloud level services that appear in similar ways.
So, we could say that we've moved one step backward since across the total solution stack someone (like the cloud provider) is dealing with all of the same problems as before, plus new ones.
The promise though, is perhaps the cloud software will become much more advanced to the point that you end up with less problems than you had without cloud computing. Some of this might be opsware type solutions (as referenced in the latter article). On the macro level it will push people towards better real-time tracking of system faults and corresponding solutions that get rolled back into standard setups. Things we could be doing already, but often fall short of.
Specifically in regards to the SSH issue, hot starts should just work.
I would model the different issues with hot starts the way the database crowd, specifically Oracle (just for a standard), model ACID transactions. For instance, the system you describe sounds like it is supporting a 'dirty' or 'phantom' hot start capability.
The is-service-up question sounds a lot like asking 'did this transaction commit successfully?'
There are going to be a lot of strategies for optimizing the spawning and running of services. For instance, why not try starting 3 servers across a grid and use the one that is up first?
Advocating for that kind of technology will result in a better solution, but will also create a market environment where there will be higher demand for management applications.
Branch