"If you rely on a feature that only a minority uses and that feature is bugridden, a customer-controller priority system will ensure that it'll never get fixed."
And the problem is?
It's the customer's money, not yours, and it's the customer's customers, not yours. If your customer's POV is "fuck my customer base bugged by #876" why should you dare to tell or act otherwise? If you think you can lead your customer's business better than him you might try to start a business competing against him instead of one servicing him, don't you think so?
"Extreme Programming is in itself a form of Agile development (cf wikipedia). SCRUM isn't the only thing people mean when they say Agile."
The problem here is that "agile"'s definition has shifted and, in this case, for very good and sensible reasons: XP is for developers and developers only. The customer has shit to say about programming in pairs, code review or the sursum corda because all a customer is (and should be) interested in is the output.
More mature definitions of "agile" understand this and add the customer as an integral and unavoidable part of the equation in that you can't have "agile" if all what your process can add is going fast and convincingly to a place nobody is interested in being at. Scrum belongs to that second wave that takes that into account.
"You're NOT DOING AGILE if you have to integrate components at the end [...] Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now"
OK. When did the customer asked you to add a jenkins deployment to the backlog? When, exactly, that jenkins was a must the customer accepted?
"One of the main things you should be doing when practicing agile is continuous integration."
Well, tell me exactly in which sprint did the customer asked for "continous integration" then. Because, you remember, if you are not promoting the customer's needs from his own point of view first, you are not doing agile, do you?
"If Marketing cannot see through the fast version that has yet to get any bells and whistles, the issue is with Marketing or perhaps the Project Managers."
Which is a pretty good way to deflect blame but adds nothing to the odds of the project to succeed.
"Every experienced designer knows [...] The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist."
Right.
"In the end it doesn't matter what methodologies you use."
Wrong. They may matter more or less, but they *do* matter. For instance, your approach to an "experienced designer" lacks a critical observation that the agile processes take into consideration even if the "experienced designer" forgets about it: the customer won't tell what they want because he doesn't know yet. Well, the designer won't get to what the customer really needs because he doesn't know it yet either: the iterative process with strong feedback between developers and customers with no people in the middle copes for the fact that neither the askers nor the doers know what's needed yet but by means of the strong feedback they maximize the chances to discover it on their way or, at least, to weight the highest responsibility to the ones that have the most chances and/or the most stakes to do it right (business to business and technology to techies) on a tighted loop.
So in the end: methodologies *do* matter. People *do* matter even more. Near, but not exactly the same thing you said.
"There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick."
Exactly. But even then, there are ways and ways to reach to that.
"Agile" (in its various incarnations, but I'm specifically talking about Scrum) is not a project management methodology but a people expectations' management methodology. Most people have this wrong.
And it is a kind of people expectations' management methodology that leans *a lot* on giving power to the people that do the work -the pigs.
Just paying attention at the two observations above is the difference between a successful and a failed "agile" implantation:
1) "Chickens" that "forget" that agile is about empowering pigs: a lot of observations about that have already been cited here (i.e. "we do agile", which in fact means "we set your goals for each fortnight in stone and you'd better acomplish them by living in a permanent sprint or you are fired").
2) "Pigs" that are not up to the challenge: the Sturgeon's revelation works on every scenario but its results are even more wherever you depend on people more than in processes. With Scrum you are letting programers work like artisans or craftsmen (which, due our current state of the art is what they are no matter how much we'd want it to be consider an engineering); but once they are considered artisans, the difference between good and bad artisans is the more acute. And most (as in 90% of them per Sturgeon) are not up to the challenge. Here is where goes those "programmers want agile because it's the way they find to scape from whatever they don't like". It works the other way too: agile is most demanding for programmers but it increases demands for the business guys too: they forcibily need to understand what they are asking for and they won't be able to hide their responsibility pushing it towards the freakoids: *you* had the responsiblity to choose what was the best for the business and you failed; you can't hide the fact that it was *you* the one that wanted the "selling ice to the skimos" feature first.
3) And then, there are the "cargo cult guys". You find this kind very easy: they say "we are doing scrum" but then you learn that they interviewed the customer once on the kick-off meeting and they won't see him again till six months down the road (but, of course, they have their morning stand up meetings, their sprints, their cards, their pomodoros... even an internal manager -the one that sets the goals for next milestone in stone, acting as "internal customer" in lieu of the real one...).
So, just like always, you either take the work to stablish a high quality, commited, well imbricated team -and then methodologies doesn't mean so much, or you use the methodology in vogue to hide your lack of abilities and/or lack or commitment. And, just like always, it is the ones in command those that really have the greatest portion on the success of a project -and even a greater portion on its failure. But, hey, since they are in command they are in the best position too to make the successes to be theirs and the failures everybody else's.
"I for one don't understand why they would really care that much."
Because it was (and still it can be, since it's bundled on Windows for free) a cornerstone on their lock-in strategy (along with Office and Exchange, and currently Sharepoint too). If they allow "the cloud" to reach the point when vendor lockin is not possible, Microsoft will have a very worrisome future.
You talkin' to me? (with de Niro's voice). I didn't mentioned "communism" but "damn communism".
"For that matter, I never even heard of communism being successfully used on even the scale of a large village."
You should listen more carefully.
"many features of communism that just don't scale."
Beware you words: times are changing. Maybe what didn't scale in the past, do scale now.
"What we in the US tend to call communism is any group the the government didn't like in the 1950's through around the late 1990's"
Yes. That's why I talked about "damn communism" (aka "I don't know exactly what am I talking about but it's a convincing scapegoat)".
Anyway, I stand in my position: it's not about real political systems but about perceptions and you can bet South Korean perceptions are influeced by the fact of sharing borders with North Korea.
"But ordinary English speakers will often take the other definition. They'll take it to mean 'concentrating on the accumulation of ownership of stuff rather than on social relationships, personal achievements, intellectual matters, helping people, being a good member of society and so on'"
There's a third "ordinary" interpretation that is -I guess, given their North neighbourghs, the one working here: "atheist materialism" == "damn communism".
"I personally think it's funny that people would even say that (if yoru a professional stuff doesn't happen BS). As someone who works in the infrastructure business I can tell you with 100% certainty that no design, location or setup will be perfect."
Truly. In fact, the professional is the one that knows that shit happens, what's the recurrence of a certain kind of shit, how it will impact the business and what's the best countermeasure to achieve the best bang for the buck: sometimes is avoiding the shit to happen, sometimes adopt measures for the shit to happen but still not let it to affect the business and sometimes let the shit happen and just cross your fingers so it doesn't happen in your time -are you really covering a global nuclear war scenario, really?
It's easy to say "this wouldn't happen to me"...when you are not in a position that this could happen to you.
"About 600 homes around me (average about 5 acres per house) all get our power from a single source"
That means, for the case of a datacenter, that you automatically get discounted for a tier one qualification. That you don't have more outages is basically a matter of luck.
"we rarely ever lose power and when we do, It's never been more than 30 minutes before I see multiple power trucks driving around"
Yes, if the only problem in the area is your power line. Wait for a wide area incident and, of course, limited resources will have to be priorized; then you probably won't see those power trucks arriving so soon.
"Some preventative maintenance and an adequate crew numbers could reduce outages and times of outages."
Truly. Now define "adequate crew". You will find "adequate crew" means "people enough for the usual case". No utility company will pay a lot of people to do nothing but once every ten years.
But that's not even the point. The problem here seems to me that people think they are talking about a "datacenter" when we are talking here about an "Amazon datacenter". Even usual "datacenters" are tiered by the efforts they go to protect themselves against a blowout: it is not professional to expect Tier One capabilities on a Tier Three datacenter as it is not professional to expect capabitilities on a infrastructure without taking the due diligence of attesting them. And then, we're talking here about datacenters from a company which value proposition is not that a single datacenter won't fail -there are other providers for that, but that their services allow to protect yourself from a single datacenter failing. Given that, why would someone expect Amazon to incur the expenditures of having top notch datacenters when they don't need them and, as a rule of thumb, each extra 9 on reliability adds x10 in costs?
And even if someone foolishly could expect this, is it so much to ask someone reading Amazon's SLA to learn they are offering "just" three nines over a monthly window?
I have standards tied to reality and I know Amazon offers[1] "a Monthly Uptime Percentage [...] of at least 99.9% during any monthly billing cycle". On top of that, I know what the value of an SLA exactly is.
"No, if you are a professional stuff doesn't 'happen'"
No, if you are a professional you evaluate risks and adjust your behaviour to an acceptable level and you don't expend a bazillion to protect half a bazillion.
In example, Google designed their applications in a way that stand for a failing server: what's the benefit in their case going with RAID10, doubled PSUs and hot swappable RAM and CPUs? What gives to the table but lost money?
Amazon offers out of Fortune 100 people the ability to do the same, only at the datacenter level. But then, if you can stand a whole datacenter failure by properly using the services they offer, what's the advantage of making the expenditure of making their datacenters five nines instead of four?
"They are still amateurs"
They are there for the money and they are making a lot of money: that's what make them professionals.
I'll tell you who's being unprofessional: all those that think that their critical services are propely protected within a single datacenter just because they read it was "the cloud" in a colourful brochure.
"Any decent IaaS cloud provider will offer CDN and GSLB products at a reasonable price."
Which helps you with your authoritative dynamic data exactly how?
And even with your mostly read-only data you will get only the lowest advantage if going the "automagical" route: to take most benefit from CDN or GSLB you need to engineer and develop you apps with those services in mind -which is exactly what I already said.
"So the problem to me, is that data center redundancy is often an after though, and IaaS hardly has easy answers to this problem yet."
It won't. For a very basic physical reason: it's always cheaper to move data near than far away. If you have a given piece of data in one place you either will lose it if that place goes nuts or you will need to go expensive to make sure such data piece is replicated out of that place fast enough.
IaaS can help comoditizing compute and storage resources but has nothing to offer with regards to move data cheaply from place A to place B and not all business (not even a minority) have the luck of managing mostly low value (i.e. Google) or read-only (i.e. Netflix) data.
"Being in a rural area does not make you statistically more likely to be hit by a tornado.. Tornadoes don't have any sort of inborn preference. Tornado danger is a function of geography, not population density."
You can't be so dense, can you? Do you think that being a tornado area might have something to do with people avoiding such a place -specially given that due to needed geography, tornado areas tend to be in the middle of nowhere?
"The only drawback of being in the sticks is it is harder to access multiple power feeds [...] You can still do it, but it costs more since those power lines are being run just for YOU."
So you are going to expend a big chunk of the savings of placing your datacenter in the middle of nowhere with the recurring costs of an utilitily that you rarely if ever will need for a service that *on purpose* relies on multiple placements to be able to serve out of out-of-the-mill hardware and capabilites.
"If your generators are maintained and functioning properly, they should be able to run for weeks with a steady supply of fuel."
Which is easier to say than do when a) your site is in the middle of nowhere and b) the "steady supply of fuel" crew is diverted to hospitals, banks, and other important places *not* in the middle of nowhere.
It's is the cloud, you fool! Why do you think companies like Amazon expend a lot to be able to offer to you a *distributable* service? If your service is minor and you can't re-deploy it on another datacenter in some few hours, you are doing it *WROOOONG*. If your service is producing a lot of money 24x7 and you can't reroute on the fly out of a failing datacenter, you are doing it *WROOOONG*. In the end, if you believe the weasels that sold you that having a virtual private server (or a few) in a (unnamed) datacenter will magically protect you from a failure in that (unnamed) datacenter just because "it's a cloud provider", you are doing it *WROOOONG*.
"If they don't have proper backup generators, they have no business running a data center."
*Or* they are in a business that recognizes that shit happens, even at the datacenter level, and provide services so you can spread your load out of more than one datacenter, making the x10 expenditures needed to go from a "decent" datacenter to a "top notch" one moot and avoidable.
Hey, doesn't that look like this funny "cloud" concept they are waving so oftenly?
A datacenter is a datacenter is a datacenter. You are not in "the cloud" if you can't scape from a datacenter-level incident.
Given that there is no "cloud" provider (not yet, at least) that will automagically protect your services from a datacenter-level incident, is up to you, the customer, to do it.
It's certainly possible with current technology but it's neither cheap nor straightforward, no matter what the "cloud" providers insist in sell and the PHBs in believe.
"Given that - sure, if we really wanted a housecat-descended math professor in a million years it probably wouldn't be hard to do at all"
You forgot a critical element. We can provide the steering wheel, but we can't provide the gasoline. You can select for pawn dexterity all you want but if there's no mutations that go that way, you'll get exactly zilch no matter how long you try.
"The point is whether or not being smart will help a cat pass on their genes more than a cat with less intelligence."
That's not the point. If it's not detrimental and it has a high enough probability of ocurrence, it'll happen, even if there's no fitness difference. That's genetic derive. Remember evolution doesn't pursue a goal, it just happens.
Slashdot Mirror
"If you rely on a feature that only a minority uses and that feature is bugridden, a customer-controller priority system will ensure that it'll never get fixed."
And the problem is?
It's the customer's money, not yours, and it's the customer's customers, not yours. If your customer's POV is "fuck my customer base bugged by #876" why should you dare to tell or act otherwise? If you think you can lead your customer's business better than him you might try to start a business competing against him instead of one servicing him, don't you think so?
"Extreme Programming is in itself a form of Agile development (cf wikipedia). SCRUM isn't the only thing people mean when they say Agile."
The problem here is that "agile"'s definition has shifted and, in this case, for very good and sensible reasons: XP is for developers and developers only. The customer has shit to say about programming in pairs, code review or the sursum corda because all a customer is (and should be) interested in is the output.
More mature definitions of "agile" understand this and add the customer as an integral and unavoidable part of the equation in that you can't have "agile" if all what your process can add is going fast and convincingly to a place nobody is interested in being at. Scrum belongs to that second wave that takes that into account.
"You're NOT DOING AGILE if you have to integrate components at the end [...] Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now"
OK. When did the customer asked you to add a jenkins deployment to the backlog? When, exactly, that jenkins was a must the customer accepted?
"One of the main things you should be doing when practicing agile is continuous integration."
Well, tell me exactly in which sprint did the customer asked for "continous integration" then. Because, you remember, if you are not promoting the customer's needs from his own point of view first, you are not doing agile, do you?
"If Marketing cannot see through the fast version that has yet to get any bells and whistles, the issue is with Marketing or perhaps the Project Managers."
Which is a pretty good way to deflect blame but adds nothing to the odds of the project to succeed.
Any other valuable suggestion, Mr dmomo?
"Every experienced designer knows [...] The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist."
Right.
"In the end it doesn't matter what methodologies you use."
Wrong. They may matter more or less, but they *do* matter. For instance, your approach to an "experienced designer" lacks a critical observation that the agile processes take into consideration even if the "experienced designer" forgets about it: the customer won't tell what they want because he doesn't know yet. Well, the designer won't get to what the customer really needs because he doesn't know it yet either: the iterative process with strong feedback between developers and customers with no people in the middle copes for the fact that neither the askers nor the doers know what's needed yet but by means of the strong feedback they maximize the chances to discover it on their way or, at least, to weight the highest responsibility to the ones that have the most chances and/or the most stakes to do it right (business to business and technology to techies) on a tighted loop.
So in the end: methodologies *do* matter. People *do* matter even more. Near, but not exactly the same thing you said.
"There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick."
Exactly. But even then, there are ways and ways to reach to that.
"Agile" (in its various incarnations, but I'm specifically talking about Scrum) is not a project management methodology but a people expectations' management methodology. Most people have this wrong.
And it is a kind of people expectations' management methodology that leans *a lot* on giving power to the people that do the work -the pigs.
Just paying attention at the two observations above is the difference between a successful and a failed "agile" implantation:
1) "Chickens" that "forget" that agile is about empowering pigs: a lot of observations about that have already been cited here (i.e. "we do agile", which in fact means "we set your goals for each fortnight in stone and you'd better acomplish them by living in a permanent sprint or you are fired").
2) "Pigs" that are not up to the challenge: the Sturgeon's revelation works on every scenario but its results are even more wherever you depend on people more than in processes. With Scrum you are letting programers work like artisans or craftsmen (which, due our current state of the art is what they are no matter how much we'd want it to be consider an engineering); but once they are considered artisans, the difference between good and bad artisans is the more acute. And most (as in 90% of them per Sturgeon) are not up to the challenge. Here is where goes those "programmers want agile because it's the way they find to scape from whatever they don't like". It works the other way too: agile is most demanding for programmers but it increases demands for the business guys too: they forcibily need to understand what they are asking for and they won't be able to hide their responsibility pushing it towards the freakoids: *you* had the responsiblity to choose what was the best for the business and you failed; you can't hide the fact that it was *you* the one that wanted the "selling ice to the skimos" feature first.
3) And then, there are the "cargo cult guys". You find this kind very easy: they say "we are doing scrum" but then you learn that they interviewed the customer once on the kick-off meeting and they won't see him again till six months down the road (but, of course, they have their morning stand up meetings, their sprints, their cards, their pomodoros... even an internal manager -the one that sets the goals for next milestone in stone, acting as "internal customer" in lieu of the real one...).
So, just like always, you either take the work to stablish a high quality, commited, well imbricated team -and then methodologies doesn't mean so much, or you use the methodology in vogue to hide your lack of abilities and/or lack or commitment. And, just like always, it is the ones in command those that really have the greatest portion on the success of a project -and even a greater portion on its failure. But, hey, since they are in command they are in the best position too to make the successes to be theirs and the failures everybody else's.
"all illegal immigrants should be sent back to whence they came. america for americans."
Wasn't that Sitting Bull motto?
"I for one don't understand why they would really care that much."
Because it was (and still it can be, since it's bundled on Windows for free) a cornerstone on their lock-in strategy (along with Office and Exchange, and currently Sharepoint too). If they allow "the cloud" to reach the point when vendor lockin is not possible, Microsoft will have a very worrisome future.
"What has North Korea got to do with communism?"
You talkin' to me? (with de Niro's voice). I didn't mentioned "communism" but "damn communism".
"For that matter, I never even heard of communism being successfully used on even the scale of a large village."
You should listen more carefully.
"many features of communism that just don't scale."
Beware you words: times are changing. Maybe what didn't scale in the past, do scale now.
"What we in the US tend to call communism is any group the the government didn't like in the 1950's through around the late 1990's"
Yes. That's why I talked about "damn communism" (aka "I don't know exactly what am I talking about but it's a convincing scapegoat)".
Anyway, I stand in my position: it's not about real political systems but about perceptions and you can bet South Korean perceptions are influeced by the fact of sharing borders with North Korea.
"But ordinary English speakers will often take the other definition. They'll take it to mean 'concentrating on the accumulation of ownership of stuff rather than on social relationships, personal achievements, intellectual matters, helping people, being a good member of society and so on'"
There's a third "ordinary" interpretation that is -I guess, given their North neighbourghs, the one working here: "atheist materialism" == "damn communism".
"I personally think it's funny that people would even say that (if yoru a professional stuff doesn't happen BS). As someone who works in the infrastructure business I can tell you with 100% certainty that no design, location or setup will be perfect."
Truly. In fact, the professional is the one that knows that shit happens, what's the recurrence of a certain kind of shit, how it will impact the business and what's the best countermeasure to achieve the best bang for the buck: sometimes is avoiding the shit to happen, sometimes adopt measures for the shit to happen but still not let it to affect the business and sometimes let the shit happen and just cross your fingers so it doesn't happen in your time -are you really covering a global nuclear war scenario, really?
It's easy to say "this wouldn't happen to me" ...when you are not in a position that this could happen to you.
"About 600 homes around me (average about 5 acres per house) all get our power from a single source"
That means, for the case of a datacenter, that you automatically get discounted for a tier one qualification. That you don't have more outages is basically a matter of luck.
"we rarely ever lose power and when we do, It's never been more than 30 minutes before I see multiple power trucks driving around"
Yes, if the only problem in the area is your power line. Wait for a wide area incident and, of course, limited resources will have to be priorized; then you probably won't see those power trucks arriving so soon.
"Some preventative maintenance and an adequate crew numbers could reduce outages and times of outages."
Truly. Now define "adequate crew". You will find "adequate crew" means "people enough for the usual case". No utility company will pay a lot of people to do nothing but once every ten years.
But that's not even the point. The problem here seems to me that people think they are talking about a "datacenter" when we are talking here about an "Amazon datacenter". Even usual "datacenters" are tiered by the efforts they go to protect themselves against a blowout: it is not professional to expect Tier One capabilities on a Tier Three datacenter as it is not professional to expect capabitilities on a infrastructure without taking the due diligence of attesting them. And then, we're talking here about datacenters from a company which value proposition is not that a single datacenter won't fail -there are other providers for that, but that their services allow to protect yourself from a single datacenter failing. Given that, why would someone expect Amazon to incur the expenditures of having top notch datacenters when they don't need them and, as a rule of thumb, each extra 9 on reliability adds x10 in costs?
And even if someone foolishly could expect this, is it so much to ask someone reading Amazon's SLA to learn they are offering "just" three nines over a monthly window?
"You have exceptionally low standards."
No, I don't.
I have standards tied to reality and I know Amazon offers[1] "a Monthly Uptime Percentage [...] of at least 99.9% during any monthly billing cycle". On top of that, I know what the value of an SLA exactly is.
[1] http://aws.amazon.com/s3-sla/
"No, if you are a professional stuff doesn't 'happen'"
No, if you are a professional you evaluate risks and adjust your behaviour to an acceptable level and you don't expend a bazillion to protect half a bazillion.
In example, Google designed their applications in a way that stand for a failing server: what's the benefit in their case going with RAID10, doubled PSUs and hot swappable RAM and CPUs? What gives to the table but lost money?
Amazon offers out of Fortune 100 people the ability to do the same, only at the datacenter level. But then, if you can stand a whole datacenter failure by properly using the services they offer, what's the advantage of making the expenditure of making their datacenters five nines instead of four?
"They are still amateurs"
They are there for the money and they are making a lot of money: that's what make them professionals.
I'll tell you who's being unprofessional: all those that think that their critical services are propely protected within a single datacenter just because they read it was "the cloud" in a colourful brochure.
"Any decent IaaS cloud provider will offer CDN and GSLB products at a reasonable price."
Which helps you with your authoritative dynamic data exactly how?
And even with your mostly read-only data you will get only the lowest advantage if going the "automagical" route: to take most benefit from CDN or GSLB you need to engineer and develop you apps with those services in mind -which is exactly what I already said.
"So the problem to me, is that data center redundancy is often an after though, and IaaS hardly has easy answers to this problem yet."
It won't. For a very basic physical reason: it's always cheaper to move data near than far away. If you have a given piece of data in one place you either will lose it if that place goes nuts or you will need to go expensive to make sure such data piece is replicated out of that place fast enough.
IaaS can help comoditizing compute and storage resources but has nothing to offer with regards to move data cheaply from place A to place B and not all business (not even a minority) have the luck of managing mostly low value (i.e. Google) or read-only (i.e. Netflix) data.
"Being in a rural area does not make you statistically more likely to be hit by a tornado.. Tornadoes don't have any sort of inborn preference. Tornado danger is a function of geography, not population density."
You can't be so dense, can you? Do you think that being a tornado area might have something to do with people avoiding such a place -specially given that due to needed geography, tornado areas tend to be in the middle of nowhere?
"The only drawback of being in the sticks is it is harder to access multiple power feeds [...] You can still do it, but it costs more since those power lines are being run just for YOU."
So you are going to expend a big chunk of the savings of placing your datacenter in the middle of nowhere with the recurring costs of an utilitily that you rarely if ever will need for a service that *on purpose* relies on multiple placements to be able to serve out of out-of-the-mill hardware and capabilites.
"If your generators are maintained and functioning properly, they should be able to run for weeks with a steady supply of fuel."
Which is easier to say than do when a) your site is in the middle of nowhere and b) the "steady supply of fuel" crew is diverted to hospitals, banks, and other important places *not* in the middle of nowhere.
It's is the cloud, you fool! Why do you think companies like Amazon expend a lot to be able to offer to you a *distributable* service? If your service is minor and you can't re-deploy it on another datacenter in some few hours, you are doing it *WROOOONG*. If your service is producing a lot of money 24x7 and you can't reroute on the fly out of a failing datacenter, you are doing it *WROOOONG*. In the end, if you believe the weasels that sold you that having a virtual private server (or a few) in a (unnamed) datacenter will magically protect you from a failure in that (unnamed) datacenter just because "it's a cloud provider", you are doing it *WROOOONG*.
"If they don't have proper backup generators, they have no business running a data center."
*Or* they are in a business that recognizes that shit happens, even at the datacenter level, and provide services so you can spread your load out of more than one datacenter, making the x10 expenditures needed to go from a "decent" datacenter to a "top notch" one moot and avoidable.
Hey, doesn't that look like this funny "cloud" concept they are waving so oftenly?
A datacenter is a datacenter is a datacenter. You are not in "the cloud" if you can't scape from a datacenter-level incident.
Given that there is no "cloud" provider (not yet, at least) that will automagically protect your services from a datacenter-level incident, is up to you, the customer, to do it.
It's certainly possible with current technology but it's neither cheap nor straightforward, no matter what the "cloud" providers insist in sell and the PHBs in believe.
" It was money that was forcibly removed from you before you ever saw it!"
Which is the very definition of "money he never had". Thanks for making his point so clear.
"the US imports more oil from Canada than any country in the Middle East"
But of course yes. Why the hell would any Middle East country import oil from Canada?
"Given that - sure, if we really wanted a housecat-descended math professor in a million years it probably wouldn't be hard to do at all"
You forgot a critical element. We can provide the steering wheel, but we can't provide the gasoline. You can select for pawn dexterity all you want but if there's no mutations that go that way, you'll get exactly zilch no matter how long you try.
"The point is whether or not being smart will help a cat pass on their genes more than a cat with less intelligence."
That's not the point. If it's not detrimental and it has a high enough probability of ocurrence, it'll happen, even if there's no fitness difference. That's genetic derive. Remember evolution doesn't pursue a goal, it just happens.
"SchrÃdinger's cat only has a 50% chance of evolving into a math teacher."
Copenhagen interpretation is more that the cat both is and isn't a math teacher... till you look at its sandbox.