Interesting point of view on how cloud service providers are haemorrhaging cash to sustain these models in the hope they'll win big in the long run.
As data storage and compute costs fall they may well be able to sustain existing pricing though I suspect ultimately they'll need to ratchet things up. Cost comparisons are also hard to get right due to the complexity of pricing from suppliers and I also believe the difference in architectural patterns used in the cloud versus on premise further complicates things (something for another day).
What I do know is that their are those in the industry who cannot afford to be left behind in the race to the cloud; IBM, Microsoft and Google notably. They will likely be pumping all they can into the cloud to establish their position in the market - and maintain their position generally...
2014/10/30
2014/10/26
The legality and morality of IT solutions
I’m often found ranting and raving about the legality or morality; or rather the illegality and immorality, of some solution or other – more often than I care to admit. This post should hopefully clarify what I mean when I say it’s “illegal” or “immoral”. I should point out that I'm using these terms as an analogy in context of some IT solution and of course the legality of a solution in technical terms is an entirely different question. Morality never was very well defined.
For further clarification I should state this post is in regard of IT solutions and not the behavioural rules and norms of society in general. That some of those IT solutions I’ve worked on may conflict with what society would expect is a separate issue…
Legality - TFD defines legality as “A requirement enjoined by law”. The key word here from a solution perspective is “requirement”. If we assume that all requirements are mandatory (of course they’re not) then when I say some solution or part of a solution is “illegal” I am simply (pompously) stating that it does not satisfy some requirement or other. This may be acceptable depending on the clients view of the requirement as some rules can be, err, bent.
Unfortunately, I often find that it’s the non-functionals that get eroded first. E.g.:
Or perhaps the worst (and all too common):
Morality - TFD defines morality as “The quality of being in accord with standards of right or good conduct”. Oh dear, all very subjective. Who’s to say what’s right and what’s good? The architect of course! (arguments commence)…
Anyway, when I say some solution is immoral, then I’m just saying it doesn’t fit with standards and best practices in the industry. In terms of architecture this could be due to poor division of responsibilities, tight coupling between components and sub-systems, incongruence with organisational structure, inconsistencies in implementations, complex dependencies and so on. None of this is black and white and sometimes compromise is the best solution – so long as you can sleep at night. But there are reasons why this stuff exists – partly because it works, partly it’s old wives tales – you’ll need to figure out which is which.
We’re often asked to bend requirements. Sometimes it’s the right thing to do, sometimes it’s just the easy thing to do. In any case, like the law, ignorance is no excuse. Make sure you understand the requirements and if you don’t satisfy them then, well, that’s your call.
When it comes to morality it’s best to follow standards and best practice – most of the time – if only so you can avoid confrontation with the high priest of architecture (aka the Chief Architect). What’s right and what’s good is always worth the debate though – and a pint or two helps to lubricate the argument…
For further clarification I should state this post is in regard of IT solutions and not the behavioural rules and norms of society in general. That some of those IT solutions I’ve worked on may conflict with what society would expect is a separate issue…
Legality - TFD defines legality as “A requirement enjoined by law”. The key word here from a solution perspective is “requirement”. If we assume that all requirements are mandatory (of course they’re not) then when I say some solution or part of a solution is “illegal” I am simply (pompously) stating that it does not satisfy some requirement or other. This may be acceptable depending on the clients view of the requirement as some rules can be, err, bent.
Unfortunately, I often find that it’s the non-functionals that get eroded first. E.g.:
- “It’s acceptable that such-and-such a function doesn’t work with IE7 because it looks great on other browsers and isn’t worth the cost to fix it” – breaking a compatibility requirement.
- “It’s acceptable that performance on some pages suck – it’s good enough generally!” – stretching performance requirements.
Or perhaps the worst (and all too common):
- “Just dump all the user data to a flat file and e-mail it to the marketing guys – they need it now!” – violating security policy. If found out you could get fired, if leaked you could bring the whole organisation down – low probability but very high risk. It’s interesting that the business focuses on the “probability” whilst the IT dept. focuses on the “risk”…
Morality - TFD defines morality as “The quality of being in accord with standards of right or good conduct”. Oh dear, all very subjective. Who’s to say what’s right and what’s good? The architect of course! (arguments commence)…
Anyway, when I say some solution is immoral, then I’m just saying it doesn’t fit with standards and best practices in the industry. In terms of architecture this could be due to poor division of responsibilities, tight coupling between components and sub-systems, incongruence with organisational structure, inconsistencies in implementations, complex dependencies and so on. None of this is black and white and sometimes compromise is the best solution – so long as you can sleep at night. But there are reasons why this stuff exists – partly because it works, partly it’s old wives tales – you’ll need to figure out which is which.
We’re often asked to bend requirements. Sometimes it’s the right thing to do, sometimes it’s just the easy thing to do. In any case, like the law, ignorance is no excuse. Make sure you understand the requirements and if you don’t satisfy them then, well, that’s your call.
When it comes to morality it’s best to follow standards and best practice – most of the time – if only so you can avoid confrontation with the high priest of architecture (aka the Chief Architect). What’s right and what’s good is always worth the debate though – and a pint or two helps to lubricate the argument…
2014/10/09
Internet Scale Waste
Whilst reading up on internet scale computing I came across a presentation on Slideshare which contains the page below.
23 millions domains for 24,000 customers = just under 1,000 domains per customer. Now that seems like a lot but I strongly suspect it's more like most customers have x1 domain with a few having many many thousands (something akin to a Zipfs distribution). Likely someone out there will have many hundreds of thousand of domains... I wonder who needs so many domains...
On an aside, eh-hem, I get a lot of comments from people pertaining to be from something like www.hu12gyd38hasjakdh8102e12e2djklasdagghkagqdncc.com, all of which turn out be spammers. Hummm..... I wonder how much spam/botware/malware waste resides in the cloud...?
23 millions domains for 24,000 customers = just under 1,000 domains per customer. Now that seems like a lot but I strongly suspect it's more like most customers have x1 domain with a few having many many thousands (something akin to a Zipfs distribution). Likely someone out there will have many hundreds of thousand of domains... I wonder who needs so many domains...
On an aside, eh-hem, I get a lot of comments from people pertaining to be from something like www.hu12gyd38hasjakdh8102e12e2djklasdagghkagqdncc.com, all of which turn out be spammers. Hummm..... I wonder how much spam/botware/malware waste resides in the cloud...?
2014/10/07
Subscribe to:
Posts (Atom)