If you follow enterprise IT, you can't miss SAP's HANA in-memory database. SAP claims this product is a game changer, and they have managed to run their enterprise software on it. It also runs in the Cloud -- both the Amazon Cloud and now SAP's own Cloud.

True, software will run faster on an in-memory system vs. a traditional hard drive-supported install. And as you would expect, your storage requirements will show a corresponding drop. But we've had the technology to emulate storage in memory for decades. I ran a computer lab back in the early 1990s, and I'd use RAM disk software on Macintosh Plus computers. They didn't have hard drives (hard to imagine now!) so I'd boot them with a RAM disk in order to eject the boot floppy. Today, you can run SAP software in HANA and free up your storage the same way my RAM disk trick freed up that old floppy drive.

It goes without saying today's systems have far more RAM than the 1.5 megabytes my old Mac Plusses had. But then as now, RAM is more expensive than magnetic (hard drive) storage, megabyte for megabyte. And of course, RAM is more volatile. One blip in the power supply and goodbye data. Just ask any of my students who lost their work when their Macs crashed.

In my opinion, however, the problem with an in-memory system like HANA is that it gives you an excuse to run poor software, since after all, even the crappiest software will run faster in-memory. But if you think that running a partition-intolerant relational database in-memory will make it any more Cloud friendly, then you're missing the point of the Cloud.

Cloud storage is plentiful, cheap, and horizontally scalable. Memory per virtual machine (VM) is limited and volatile. The last thing you want to do is run a partition intolerant system in-memory! HANA is nothing more than a stopgap measure by a desperate vendor trying to maintain its revenue in the face of an ancient code base that is inherently Cloud-unfriendly.

             

I'm a big fan of DevOps. So when I read a thought-provoking blog post on why organizations shouldn't implement DevOps, well, I had to chime in.

The author of the post, Ben Kepes, makes an important point. Organizations that transition from siloed development and operational environments to a siloed DevOps environment haven't solved the core problem they're hoping to solve. After all, the original problem isn't that dev and ops aren't working together. It's the fact that the IT organization is siloed to begin with.

The problem, therefore, isn't with DevOps in principle, it's with the notion of a "DevOps team." To implement DevOps properly, it's important to reorganize the IT organization along entirely different lines. The DevOps effort must cut across functional areas, rather than being a new functional area of its own.

What's confusing about this point is the superficial Fight Club-type paradox ("the first rule of Fight Club is you do not talk about Fight Club"). The first rule of DevOps is don't implement a DevOps team. But we've seen this paradox before: the first rule of Scrum is don't do Scrum. But make no mistake: such statements are not true paradoxes. Rather, they indicate the need to think differently about the problem at hand.

To get Scrum right, you must be willing to change the methodology of Scrum itself, since responding to change over following a plan is Agile principle #4. To get DevOps right, you must be willing to rethink the IT organization along similar lines. As Kepes says, DevOps is all about communication and collaboration -- Agile principles #1 and #3. But remember, being dogmatic about Agile misses the point of Agile entirely. Rule #2 of Fight Club: you do not talk about Fight Club.

             

Want Cybersecurity? Get Cloud. That's the perspective of General Keith Alexander, director of the National Security Agency and commander of the U.S. Cyber Command, speaking at an event on May 10^th. He pointed out that the U.S. Department of Defense (DoD)'s networks are impossible to defend, and he's looking to the Cloud to solve the problem.

Say what?

If anyone has a handle on Cybersecurity, it's the NSA. But the NSA admits that their networks are indefensible. If anyone has reason to be wary of security in the Cloud, it's the NSA. But the NSA is looking to the Cloud to provide greater security, not less.

Oh, and by the way, smartphones are also going to be an essential part of the DoD's Cybersecurity strategy going forward. Because everyone knows how secure smartphones are.

General Alexander's proclamations may strain the credulity of many an IT manager, but in fact, the NSA is well ahead of the typical enterprise in their pursuit of robust Cybersecurity. They've learned the hard lessons of the old ways of thinking: proprietary hardware, expensive protocols, and other approaches that had promise in their day but ended up falling short.

Perhaps it's time to follow the NSA's lead here. Instead of shunning the Cloud and mobile technologies when building your Cybersecurity strategy, embrace them. These trends represent the future whether you like it or not.

             

On May 6^th, a hacktivist group going by the Syrian Electronic Army (SEA) hacked the Onion. After amusing us with a series of satirical fake-news articles and associated tweets, it seems the joke was on them for once.

However, while the Onion's Twitter accounts are a rather juicy target because of the number of followers (who nevertheless have limits to their credulity), the attack was so simple and repeatable that it makes one wonder how vulnerable we all are to similar attacks.

This article on Ars Technica lays out the details. A simple phishing email to Onion staffers linked to a bogus news Web site. Sure enough, someone fell for it, giving up his or her Google apps login. The hackers then sent staffers another phishing email from the compromised account, snaring two more staffers who provided their login credentials, one of whom had access to all the social media accounts.

We'd like to think Onion staffers are smarter than your average bear. They are worldly, intelligent people familiar with the ins and outs of social media and associated risks, right? Sure they are. What about your colleagues? Think about everyone in your organization. Would any of them click a benign link to a news article, and then provide login credentials? Would any of them fall for an email from a trusted email account in your organization?

The SEA's goal was to send anti-Obama propaganda. A minor inconvenience, considering Fox News has been doing the same for a decade now. But what about your organization? What damage could a successful phishing attack cause?

             

Everybody knows that hard drives go bad. Some give up the ghost sooner, while others beat the odds, but eventually the storage grim reaper comes for all of them. When you have a data center full of hard drives, for example if you're running a Cloud, then bad drives are a daily occurrence. In fact, given that so much of the Cloud operational environment is (or should be) fully automated, replacing bad hard drives might be most of what your techs do to while away their workdays.

So, what do you do with all those bad drives? Remember, just because your drive has a problem doesn't mean that a nefarious and persistent hacker couldn't get some of your confidential information off it. Google, for example, takes bad hard drives and puts them into an industrial press, which deforms the platters so they won't spin, and then runs the entire drive, case and all, through a big shredder. All that's left are little bits of tech detritus even James Bond's Q couldn't make any sense out of.

Chances are, however, your data center is fresh out of industrial presses and shredders. Such items are not on your typical data center buildout wish list, after all. And what about your Cloud provider? I'm sure Amazon takes similar steps to Google, but what if your Cloud provider is a smaller, less experienced player? Or perhaps you have a hosted Private Cloud. What hard drive disposal process does your hosting provider go through?

This issue, of course, predates the Cloud. Any data center has had to dispose of bad drives since we first started putting hard drives into them. But now that we have the Cloud, you as the customer may not have any visibility or control over what your Cloud provider does with bad hard drives. Perhaps it's time to ask them?

             

One of the highlights of Dell's transformation from a low-cost PC provider to a purveyor of IT services and all things Cloud is their Boomi Cloud integration product. Originally billed as a Business-to-Business Integration (B2Bi) tool, Boomi revamped the product several years ago as a full-fledged Integration-as-a-Service offering, positioning it as the point of the spear of Dell's Cloud strategy.

What caught my eye about Boomi, however, is not simply their Cloud centricity. Instead, Boomi Suggest impressed me the most. Boomi Suggest allows any Boomi customer to publish their integration mappings anonymously to the community of Boomi customers. Subsequently, when another customer wants to perform an integration, Boomi suggests likely mappings. Dell reports that customers select the suggested mapping over 85% of the time.

As anybody who's monkeyed with application integration can attest, creating the mappings are the Dwarf-in-the-box step that is both hair-pulling and inherently manual. Having a list of such mappings pop up where most of the time you can simply select one can be a huge time and money saver.

The only reason Dell Suggest works, of course, is because Boomi is fully multi-tenant. As we explain in our Cloud Computing course, full multi-tenancy can be especially useful when you want tenants to share information, for example, for social media apps. In Boomi's case, they are crowdsourcing integration mappings. Finally, crowdsourcing for a more useful purpose than assembling flash mobs in airports. Imagine that!

             

It's my pleasure to be spending much of this week with hundreds of data-heads, learning about all things data at Dataversity's Enterprise Data World (EDW) in San Diego. As my focus is on architecture and Cloud Computing, the part of EDW that floats my boat is the Big Data story, especially when the Cloud is involved.

It's no surprise, then, that Qubole caught my attention. Qubole is a Big-Data-as-a-Service (BDaaS) service provider. I know, I know, yet another *aaS, right? However, in Qubole's case, it's not Cloudwashing. They truly have a BDaaS story.

Qubole enables the collection, refinement, and consumption of Big Data sets, offering the power of Hadoop and related Big Data analytics tools running in the Amazon Cloud. But that basic data in -> crunch -> results out equation doesn't illustrate what's special about Qubole: Qubole is a service for data analysts and business people, not for developers. It goes beyond what Amazon offers to provide a business-focused BDaaS capability.

Contrast Qubole with Amazon's alternative, Amazon Elastic MapReduce (EMR). Like Qubole, EMR offers Hadoop as a service. But to use EMR, you need to work directly with Hadoop, which means you need solid Java skills. Remember, Hadoop is a Java framework for writing analytics algorithms, more so than an analytics application itself. With Qubole, however, there's no need to monkey with Java. The Qubole interface abstracts the underlying Hadoop engine.

Another interesting twist to Qubole is that it works with objects stored in the customer's S3 object store (that's Amazon's Simple Storage Service). Point Qubole to your data and let it go. As a result, Qubole doesn't have to provide its own data security, as it's up to you the customer to properly configure S3's built in security capabilities.

One limitation of Qubole is that because it works directly with an object store rather than a relational database, it doesn't work well with normalized relational data. You can move relational data to S3 table by table, but you lose relational integrity. That being said, Hadoop itself isn't designed for relational data, either. Rather, it's intended to work with a mix of different data types including unstructured data. As a result, so is Qubole.

             

Given the dramatic and appalling events over the last few weeks, you may not have noticed a story that has similarly dramatic and appalling implications: the hacking of two Associated Press Twitter accounts. According to the New York Times, this hack caused markets to move, even though the erroneous information was called out in a matter of minutes. Twitter for its part now says it's planning to roll out two-factor authentication to help reduce the ease of hacking its accounts.

My response? Be afraid. Be very afraid. First, this hack was simple, and the damage was transitory. But the fact that even such a rudimentary attack can move the Dow is an indication of the power that Twitter has. The world increasingly looks to Twitter for current news and other information. That reliance on a single source of information promises to increase over time.

On the other side of the equation, will two-factor authentication solve the problem? Absolutely not. First, it will likely be optional, giving hackers plenty of leeway to hack unprotected accounts. And even for the accounts that do utilize two-factor authentication, attacks are only somewhat more difficult.

The combination of these two facts is chilling: Twitter is increasingly regarded as a trusted source of news while at the same time an increasingly easy target for attackers. One more front in the global Cyberwar we're woefully unprepared to defend.

             

When I first heard the marketing for IBM's PureSystems, I must admit I was amused. They're calling these systems "expert systems," but when they describe what they mean by an expert system, it sounds like they mean a system that works like it's supposed to without having to monkey around with it for weeks. You know, like any system you've bought this century.

In other words, Big Blue is poking their head out of the Twilight Zone they've been inhabiting for years, proclaiming a miracle that they could actually sell a piece of technology that worked properly. Hallelujah!

To illustrate this admittedly snarky perspective, take a look at the IBM graphic below, which I found in an IBM PureSystems flyer. Apparently, the PureSystems value proposition is that you don't have to make do with "traditional systems," which IBM describes as being "up and running in months," "overpurchased and overprovisioned," "hard to maintain, complex, and brittle," etc.

The irony of these statements, of course, is that by traditional systems, IBM means the crap we've been selling you for years. Anybody who's tried to install WebSphere Application Server from the 80-odd CD-ROMs that IBM shipped knows what I'm talking about.

But perhaps I'm being too hard on IBM. After all, they claim to be turning over a new leaf. Let's not complain about the way things were, let's look at what they're selling today. Fair enough.

Perhaps the most interesting angle on the PureSystems messaging is that IBM is billing certain configurations of the tool as a Private Cloud in a box. Preconfigured, template-driven, and essentially turnkey, PureSystems offers virtualized compute, network, and storage in one integrated package. Furthermore, it comes in three basic configurations: PureFlex for IaaS, PureApplication for PaaS, and PureData for Big Data. Each configuration comes in multiple sizes, maxing out with the 10-rack PureData system sporting a whopping 1,120 CPU cores and 1.28 petabytes of storage.

If this monster works as well as IBM says it does, it represents some serious enterprise firepower. But is it a Private Cloud in a box? In part, perhaps. The automated management and fully virtualized compute, storage, and network is much of what we mean by a Cloud, but I couldn't find any mention of automated self-service provisioning in the marketing. Without this critical feature, I'd be hard-pressed to consider PureSystems a Cloud.

But even if such capabilities are present, there is still the question of maximum capacity. What if you need more than 1,120 CPU cores? Buying another PureSystems won't help, since you'll have two separate systems instead of one seamless Cloud. And there's the rub, not just with PureSystems, but with virtually every Private Cloud in existence. Because they all have a maximum capacity, they don't hold a candle to true Clouds like the Amazon's AWS. Many finite "Clouds" do not add up to the "infinite" elasticity that the market leader can provide.

PureSystems, PureFlex, and PureApplication are IBM trademarks.

             

The more I learn about what Amazon Web Services (AWS) has done in the Cloud Computing arena, and the better I understand how Amazon's efforts are dramatically leaving all competitors in the dust, the more impressed I am. Sometimes I can't help but gush about how Amazon invented Infrastructure-as-a-Service (IaaS), and actually got it right.

You might conclude, therefore, that I'm a fan of Amazon, and you'd be right. Perhaps it's all my years as an industry analyst covering emerging markets, but I love marketplace disruption. Gimme chaos over calm any day. But while such turmoil tends to be good for the disruptors (and their shareholders), it's a very different story if you're the one getting disrupted.

Ironically, given the breath of Amazon's broader business, I can consider myself on the losing end of this equation as well. Case in point: how Amazon disrupted the used book marketplace. Before Amazon came along, if you wanted to shop for used books, you had to go to a used bookstore. And fundamentally, the reason used bookstores existed in the first place is that publishers refused to sell new books to any bookstore that also sold used books. As a result, the market contained (new) bookstores and used bookstores, but never the twain could meet.

Until Amazon, that is. Amazon is now such a dominant force in the book market that they basically told the publishers they were going to sell used books right alongside new ones, and if the publishers didn't like it, they could take their business elsewhere. But of course, no publisher could afford to do so, so they -- and the authors -- just have to suck it up. As an author myself (check out The Agile Architecture Revolution), I don't get a penny of royalties if you buy a used copy of my book from Amazon. I feel disrupted.

So, is Amazon good or evil? You be the judge. Clearly, disrupting markets is in a different category from, say, outsourcing manufacturing to Asian sweatshops, but tell that to the targets of such disruption. Excuse me while I go back to toiling over my keyboard for five cents per hour.