Cloud computing, defined as a subscription-based or pay-per-use service that in real time, and over the Internet, extends existing capabilities of Information Technology, remains at an early stage of conceptual development. Services do range from full scale applications such as accounting and storage to niche services such as spam filtering.
Proponents of cloud computing contend that it erodes the requirements for major capital expenditures on IT infrastructure to customer applications. However, will cloud computing replace outsourcing and does Cloud computing "represents a fundamental shift in how financial companies pay for and access IT services?"
Cloud computing differs from traditional outsourcing in a number of respects. The contractual commitments, sometimes defined as subscriptions, tend to be for short periods of time, as little as a session to a month. The contracts rarely have up-front tariff charges.
The services are available are on demand but, while cloud computing services may be capable of some scaling they are most certainly not capable of unlimited instant scaling and addition of near unlimited resource. Semantically, cloud computing may be defined as "instant outsourcing."
Indian outsourcers may consider extending their outsourcing services to the cloud computing domain, where their existing IT infra-structure services have spare resources capacity. They do have the resources to fill that gap in instant outsourcing through almost unlimited scaling and addition of near unlimited resources.
Where Indian outsourcers consider formally entering the area of cloud computing services, they should position cloud computing services as separate and distinct from their existing outsourcing services, containing no overlapping services with core outsourcing, even to existing clients. Pricing models differ.
While delivery of cloud computing services may be personalized, its services and service strategy is not collaborative. Outsourcers may consider using cloud computing as a means of selling non-core applications and services, which can impede the financial incremental benefits of major outsourcing contracts.
Many institutions, particularly in the financial services sector, are unlikely to entrust major aspects of data use and application to cloud computing services, unless and until their trust in those services has grown.
So, issues such as data security, systems integration, unexpected and tactical demand for capacity will be critical service hurdles that all cloud computing providers will have to clear to engage major clients in cloud computing in core areas of their technology structure and services provision.
Major external technology service provision is likely to remain a traditional strategically based outsourcing service. The need to respond tactically and spontaneously to immediate and short term business demands will erode the non-core elements of technology outsourcing.
If cloud computing can position itself an element of strategic information technology planning, then it will start to make more substantial inroads into traditional outsourcing.
Saturday, April 30, 2011
How to write fast code
How to write fast code
There was a time, early in my programming career, when I needed to rewrite a particular program (a very small one) to make it run faster. I was quite new to programming and thought that the way to get something to run faster was to rewrite it in assembly. In those days, you could unroll a loop in assembly and pretty much count on getting a worthwhile speedup, if it was a tight loop to begin with.
Fortunately, I had a fabulous mentor in those days, a coder with wisdom and experience far beyond his years. The person in question was a first-class code ninja and a master circuit designer, a genius of Woz-like proportions. Silicon obeyed him the way marble obeyed Michelangelo.
When it came to code, John could do astounding things. He could optimize (and did optimize) virtually any algorithm for any situation, and do it in so little code that you'd sit there studying the printout, wondering where the heck the algorithm went! I remember John had this peculiar way of making loops vanish, for example. They'd turn into table-lookups or recursion or self-modifying code, or some combination of the three.
One day my mentor asked me what I was working on and I told him. I mentioned that I was frantically searching for a way to speed up my little program. I described a few of the things I'd tried so far. He listened intently.
When I was done talking, John gave me some of the most profound advice any programming expert has ever given me. (It was profound for me, at the time. Maybe it'll be stupid-sounding to you.)
"The CPU," he said, "runs at a certain speed. It can execute a fixed number of instructions per second, and no more. There is a finite limit to how many instructions per second it can execute. Right?"
"Right," I said.
"So there is no way, really, to make code go faster, because there is no way to make instructions execute faster. There is only such a thing as making the machine do less."
He paused for emphasis.
"To go fast," he said slowly, "do less."
To go fast, do less. Do less; go fast. Yes, of course. It makes perfect sense. There's no other way to make a program run faster except to make it do less. (Here, when I say "program," I'm not talking about complex, orchestrated web apps or anything with fancy dependencies, just standalone executables in which there's a "main loop.")
Key takeaway: Don't think in terms of making a slow piece of code run faster. Instead, think in terms of making it do less.
In many cases, doing less means using a different algorithm. Then again, it may be as simple as inserting a few if-elses to check for a few trivial (but frequently encountered) "special cases" and return early, before entering a fully-generalized loop.
It may mean canonicalizing your data in some way before passing it to the main routine, so that the main routine doesn't have to include code that checks for corner cases.
The tricks are endless, but they end up with the CPU doing less, not more; and that's the key.
The "go fast do less" mantra has been a valuable one for me, paying off in many ways, in many situations, over the years. It has helped me understand performance issues in a different kind of way. I'm grateful to have been exposed to that concept early in my career. So I provide it here for you to use (or not use) as you see fit
There was a time, early in my programming career, when I needed to rewrite a particular program (a very small one) to make it run faster. I was quite new to programming and thought that the way to get something to run faster was to rewrite it in assembly. In those days, you could unroll a loop in assembly and pretty much count on getting a worthwhile speedup, if it was a tight loop to begin with.
Fortunately, I had a fabulous mentor in those days, a coder with wisdom and experience far beyond his years. The person in question was a first-class code ninja and a master circuit designer, a genius of Woz-like proportions. Silicon obeyed him the way marble obeyed Michelangelo.
When it came to code, John could do astounding things. He could optimize (and did optimize) virtually any algorithm for any situation, and do it in so little code that you'd sit there studying the printout, wondering where the heck the algorithm went! I remember John had this peculiar way of making loops vanish, for example. They'd turn into table-lookups or recursion or self-modifying code, or some combination of the three.
One day my mentor asked me what I was working on and I told him. I mentioned that I was frantically searching for a way to speed up my little program. I described a few of the things I'd tried so far. He listened intently.
When I was done talking, John gave me some of the most profound advice any programming expert has ever given me. (It was profound for me, at the time. Maybe it'll be stupid-sounding to you.)
"The CPU," he said, "runs at a certain speed. It can execute a fixed number of instructions per second, and no more. There is a finite limit to how many instructions per second it can execute. Right?"
"Right," I said.
"So there is no way, really, to make code go faster, because there is no way to make instructions execute faster. There is only such a thing as making the machine do less."
He paused for emphasis.
"To go fast," he said slowly, "do less."
To go fast, do less. Do less; go fast. Yes, of course. It makes perfect sense. There's no other way to make a program run faster except to make it do less. (Here, when I say "program," I'm not talking about complex, orchestrated web apps or anything with fancy dependencies, just standalone executables in which there's a "main loop.")
Key takeaway: Don't think in terms of making a slow piece of code run faster. Instead, think in terms of making it do less.
In many cases, doing less means using a different algorithm. Then again, it may be as simple as inserting a few if-elses to check for a few trivial (but frequently encountered) "special cases" and return early, before entering a fully-generalized loop.
It may mean canonicalizing your data in some way before passing it to the main routine, so that the main routine doesn't have to include code that checks for corner cases.
The tricks are endless, but they end up with the CPU doing less, not more; and that's the key.
The "go fast do less" mantra has been a valuable one for me, paying off in many ways, in many situations, over the years. It has helped me understand performance issues in a different kind of way. I'm grateful to have been exposed to that concept early in my career. So I provide it here for you to use (or not use) as you see fit
Subscribe to:
Posts (Atom)