Is...is this something that's good for your career? Is it a promotion? Is it a lateral move?

If it's a promotion you didn't ask for, and you turn it down for very clear reasons, AND you're doing a good job at your current role, there's a good chance you'll be fine. After all a valuable employee at Position X who turns down a promotion to X+1, is still valuable at X. However, it is likely that future promotions will be unavailable to you, at least for a while, as you'll be perceived as "happy where you are"

On the other hand, if you're being moved laterally to a non-technical position, there's a decent chance they say something like, "Well, lunchlady55 is smart, and very organized, good manager, but not really hands-on technical enough for what we need. We don't want to lose lunchlady55, but we're suffering because of L55's technical weaknesses. Why don't we move L55 laterally to a project manager-type role where we can leverage his/her strengths and backfill the technical position with someone who's very technical but requires lots of oversight"

In that situation, they're actually being good managers, by recognizing that they have a valuable employee who is just in the wrong position, and trying to rectify the situation. On the gripping hand, they're being bad managers, because if this is the case, it should really be explained to you.

If the latter situation is the case, you put them in a much rougher position, because they like you, but you're not meeting their needs in one area or another. In this case, you may lose your job.

The best way to handle this is to have an open and frank conversation with your manager. Talk about what the organizational chart looks like. Who will you be reporting to? Is there a raise or other compensation for being on-call? Be frank - are there concerns about your current job performance that led to this lateral move? Are they eliminating your position and they're just trying to protect you personally?

Based on all this, you can make an informed decision about what the situation is. You may want to try to negotiate yourself a better deal. For example, you're on call for the weekends, but whenever you have to do off-hours work while on-call, you get 2x that amount of time off your regular day during the week. Or you get paid for on-call time. Don't try to negotiate this until you understand why this is happening.

Actually, in this case, it's very straightforward. He's using Amazon EC2. EC2 charges by the hour, and all you have to do is spin up the number of servers you want. In fact, I happened to run the numbers on what the costs are for running 50 "8-core" servers, and it happens to be...$34/hour. So, what he did was say, "If I run two jobs an hour, I make a small amount of money. If I run 4-5 jobs per hour, I make more money"

This is, of course, a textbook use case for EC2, and I'm surprised no one has done it sooner.

Well, if Oracle does hand this out, I don't get it certainly. And for the record, I think that Oracle is overpriced, and believe their pricing model is not sustainable over the long term.

But you see my point, no? These are features that are in more traditional enterprise RDBMS systems. If you don't need them, you don't have to spend the money. If you need them, you can spend the money, or you can cobble together a system on your own. If you do cobble together a system, you're responsible for supporting that infrastructure internally.

You've made several separate points:
- RDBMS technology has never been "trialed under real-world conditions" and "transactions are a joke for scalability" - neither of those statements are true, nor have you backed them up with any data. A ~100TB DB2 or Oracle database is hardly impressive these days. (I'll also throw in that if ACID compliance bothers you that much, you can disable it at a session, table, or database level in an RDBMS. At least you have the option.)
- "Distributed atomic transactions don't scale" - this is demonstrably true, but irrelevant to the point at hand. 2PC has its place, but in the RDBMS world, has been largely discarded for the exact reasons you specify.
- "It's a good thing you have all those tools ...because you need them to make that complex pile of enterprisey spaghetti work. If only there was something out there that just worked, and didn't need all that hand-optimizing and tool-fiddling to kludge it into usability. - I think it's hysterical that you would throw this elsewhere into the thread, when you freely admit that NoSQL-esque systems are missing all sorts of features that you expect someone to implement outside of the solution.

Let me rewrite your sentence - "It's a good thing you have all of those third-party software packages...because you'll need them to get that immature open-source key-value store to work. If only there were something out there that had a fully integrated stack of DR, HA, and management capabilities that just worked, and didn't need all of that custom infrastructure around it, and had a large community of people and knowledge who know how to manage and operate it"

Let me restate AGAIN my point - NoSQL data stores are interesting, have their place, and will no doubt continue to grow and be an important part of the data management ecosystem. HOWEVER, to say that traditional RDBMS systems are done for, or don't scale, or are useless, displays an ignorance of reality that undermines the whole discussion.

I sort of agree with you, from the perspective that there's crusaders on either side - people who insist that traditional RDBMSes are the Only Way and people like you who insist they've "never been trialed under real-world conditions". Both statements are clearly incorrect on their face.

However, there are a multitude of features that these systems have that are not available in NoSQL systems, or only available in such a watered down form that its unfair to compare the two. A list:

- On-disk encryption
- Compression
- Schema/data versioning (present one picture of data to one set of clients, while presenting another layout of the same data to another set during a data migration)
- Automated failover between servers, clusters, facilities, datacenters
- "Flashback" - say "I want to run a query against my data as it looked last week at 3pm", and it just works.
- Shared-disk clustering

As far as transactions go, they may be a "joke" for scalability (not quite sure what that means), but they're awfully useful when dealing with sensitive information you need ACID compliance for. For example, I would prefer my bank not use an "eventual consistency" model when dealing with my credit card transactions.

Now, as I said above, a relational database *may not* be the right decision for your application. But the idea that relational databases don't scale is ridiculous. I've seen petabyte datawarehouses running teradata that absolutely scream through data. I've seen Oracle systems that do 10s of thousands of write transactions per second, and several times that in reads. They exist.

Uh, no, that is not correct. Relational DBMSes such as Oracle, Teradata, DB2, even SQL Server are all designed to scale into the multi-terabyte to petabyte range. The issue is one of a couple of things:

- Cost - "real" relational databases are expensive. I once had a conversation with someone who worked at Google, who talked about how much infrastructure they have written/built/maintain to deal with MySQL. Many of those problems were solved in an "enterprise" DBMS 3-10 years ago. However, the cost of implementing one of those enterprise DBMS is so high that it is cheaper to build application layer intelligence on top of a stupid RDBMS than purchase something that works out of the box
- Workload style - most of the literature around tuning DBMS is for OLTP or DSS workloads. Either small question, small response time (show me the five last things I bought from amazon.com) or big question, long response time (look through the last two years worth of shipping data and figure out where the best places to put our distribution centers would be). Many of these workloads are combos - there could be very large data sets and complex data interdependencies, with low latency requirements. It may be possible to write good SQL that does these things (in fact, I know a couple luminaries in the SQL space that will claim just that), but the community knowledge isn't there.
- Application development - when you're building your app from scratch, you can afford to work around "quirks" (bugs) and "gaps" (fatal flaws) to get what you need. This dovetails with the other issues, but when your core business is building infrastructure, it's worth your while to deal with this. When your core business is selling insurance or widgets, or whatever, it is not.

None of this is to say that the "nosql" movement is a bad thing, or that there's no reason for its existence, or that no one should bother looking at it. However, there is a definite trend of "this is so much better than SQL" for no good reason. SQL has scaled for years, and I know loads of companies who work with terabytes and terabytes of data on a single database without any issue.

A far more interesting discussion is the data warehouse appliance space - partitioning SQL down to a large number of small CPUs and pushing those as close to the disk as possible.

What are you talking about? They have:
- $3.4m in revenue
- $17m net loss

That means they lost 17 million dollars after earning 3.4 million - the 3.4m made up for some of the money they lost. If they had made zero dollars in revenue, they would have lost $20.4m - instead, they only lost $17m.

Revenue! Profit is not irrelevant, of course, but if a company is profitable, it simply means the multiplier increases. And many small tech companies get acquired when they're intentionally not profitable, because they're working towards growth rather than profitability.

I'm not quite sure what you mean by your second comment, but to be clear, they *lost* $17M net of their $3.4M - so their gross expenses were $20m. As far as paying someone to take it, if there's really no takers for buying the company, and no more money, they'll close things up and try to sell the intellectual property.

tftp is totally correct, and if I had to guess, in this case it was:

- no more water to draw from the well - i.e. with $70m raised and $3.5m in revenue, who's gonna put in more money?

- they knew that there was still a little mojo left in the virtualization market - but the reality is that once the dust settles, you're gonna have a small number of players - VMWare for sure, maybe MSFT, maybe citrix, maybe Oracle - anyone else who's making a virtualization platform has already been bought or isn't going to be, so this was their chance to get out.

Heh. Well, so, that's not exactly how it works. They had raised something around $60-70m in three or four rounds, including one round that involved firing/departures of most of the original founders, a new management team, and a totally new business focus.

So first of all, every time you do a round of fundraising, you create new shares of stock. Let's say my company has 100 shares of stock, and you're a 10% owner of stock - that means you own 10 shares of stock. When we want to raise money, we go convince an investor that our company is worth $100,000, or $1000 per share, making your shares worth $10k. We then have the investor give us $100,000, we create 100 new shares of stock, making the company worth $200k "post-money" - but now you only own 5%, and your investors own 50%. On top of that, the investors might say, "hey, we want liquidation preference, or participating preferred" - complex subjects that can't be delved into here, but suffice it to say that gives them more power.

Ok, time goes by - you spend that $100k you've raised, and while business is not terrible, it's not as good as your investors had hoped. You go back to get more money, and they say, "Sure, we'll give you another $100k, but we really don't think the company has progressed like we'd hoped, so the total company is worth $150k pre-money" - whoops, now your shares are worth $7,500. And after another 133 shares are created, you now own around 3% of the company.

See how fast individual ownership can drop? Now, let's extend this factor to someone like VirtualIron who was raising $10-25m *every time* they raised money, and changed business models once. You can bet that by the time they went through four rounds of funding, the VCs owned almost all of that company. (By the way, I realize that this is only the most simplistic model of how companies fund operations through VCs, so don't yell at me - I don't have the space to talk about every option).

According to some papers that had been leaked to the nytimes, in 2008 they did $3.4m in revenue and lost something like $17m on that $3.4m. How much can that company be worth? Typical rule of thumb in tech stock transactions is 5x-12x revenue, depending on a variety of factors. Given that it cost them $17m to make $3.4m - one could see how the multiplier is not gonna be so favorable. Let's make it 6x - that's $20m.

So, you have a company where investors have sunk and lost $60m, fired management at least once, changed business models once, changed products at least once, and in the end, they're getting bought for between $16-32m. Do you think that anyone got more than a "thanks for selling this dog of a company" bonus?

It's a shame, and I feel bad for the employees, but this is not a tech success story.

By your own example, though, clearly the current level of diversity hasn't helped mitigate the spread of malware, since conficker was able to install on many many PCs.

Then, if we decided we needed more diversity, how many more? I can't see having 10 major OSes making a difference, perhaps 50 with wide distribution.

So now, businesses, software developers, hardware manufacturers, tech support organizations have to support 50 different operating systems? Where's the ROI on that? How will we hire enough people who are trained on that many different configurations?

Certainly, we all want better computer security, but improving security by increasing IT complexity is like permanently banning travel between countries because of the fear someone might bring a disease in. It solves the problem, but damages everyone every other way.

Mostly, it just benefits Intel and AMD. Sun loses their high-end chip, which theoretically hurts their high-end offerings, but their high-end servers are an rapidly declining piece of their revenue. I've thought that Sun should drop SPARC entirely, except for supporting legacy customers. The niagara chip is an interesting concept, but most people today just want Intel/AMD chips in their servers.

Ah, it totally depends on the type of database cluster. For example, with Oracle, if you're using Oracle DataGuard, even in synchronous replication mode you can define an "apply delay" - basically, "Don't acknowledge this commit until it is written locally, and copied and acknowledged on the remote side, but don't actually apply the transaction for two hours"

That way, if someone does a delete * from blogs;, it will be reflected immediately on the production, but you've got a nice window to sort it out.

Plus, if you've got database flashback turned on, you can simply say, "Flash my database back to what it looked like before someone was an idiot", and all your data comes back.

These features are expensive in Oracle, but they can be very useful when you actually need them.