Nano, Nano – Serving you on 15-Watts

The Dell XS11-VX8 Server

This is something I was asked about a few times at EMC World, power and form factors for servers. Here is the latest server from the Dell Data Center Solutions group (DCS). It’s only a little bigger than a disk drive, and you can get 252 servers in a 42U rack. While the form factor is interesting, very interesting, you need to think outside the “box” to get the true value.

It uses the Via Nano CPU, to deliver an incredibly low-power solution of 20-29 Watts/server when fully busy, and 15 Watts/server when the OS is idle. It includes enterprise features like 64-bit operating systems, 1-to-1 virtualization, and remote management via IPMI. What this does is turn the current server paradigm on it’s head. Instead of using more and more power hungry server chips that deliver more performance than you really need, which opens the gate for someone to tell you about server virtualization and consolidation to make the most of the power per watt, or cost of the server. The Dell XS11-VX8 just gives you “enough” performance, at a good price, and an effective price per watt. For those sensative to cross-charging, billing out IT services etc. it has another side effect of simplifying software licensing and allocation.

Over on the Direct2Dell blog community, Todd has written a post with some useful additional detail.

EMC World – standards?

Tucci and Maritz at EMC World 2009

I’ve been attending the annual EMC World conference in Orlando this week. A few early comments, there has been a massive 64,000ft shift to cloud computing in the messaging, but less so at ground level. There have been one or two technical sessions, but none on how to implement a cloud, or to put data in a cloud, or to manage data in a cloud. Maybe next year?

Yesterday in the keynote, Paul Maritz, President and CEO of VMware said that VMware is no longer in the business of individual hypervisors but in stitching together an entire infrastructure. In a single sentence laying out clearly where they are headed, if it wasn’t clear before. In his keynote this morning, Mark Lewis, President, Content Management and Archiving Division, was equally clear about the future of information virtualization, talking very specifically about federation and distributed data, with policy management. He compared that to a consolidated, centralized vision which he clearly said, hadn’t worked. I liked Lewis’s vision for EMC Documentum xCelerated Composition Platform (xCP) as a next generation information platform.

However, so far this week, and especially after this afternoons “Managing the Virtualized Data Center” BOF, where I had the first and last questions on standards, which didn’t get a decent discussion, there has been little real mention of standards or openness.

Generally, while vendors like to claim standards compliance and involvement, they don’t like them. Standards tend to slow down implementation historically. This hasn’t been the case with some of the newer technologies, but at least some level of openness is vital to allow fair competition. Competition almost always drives down end user costs.

Standards are of course not required if you can depend on a single vendor to implement everything you need, as you need it. However, as we’ve seen time and time again, that just doesn’t work, something gets left out, doesn’t get done, or gets a low priority from the implementing vendor, but it’s a high priority for you – stalemate.

I’ll give you an example: You are getting recoverable errors on a disk drive. Maybe it’s directly attached, maybe it’s part of a SAN or NAS. If you need to run multiple vendors server and/or storage/virtualization, who is going to standardize the error reporting, logging, alerting etc. ?

The vendors will give you one of a few canned answers. 1. It’s the hardware vendors job(ie. they pass the buck) 2. They’ll build agents that can monitor this for the most popular storage systems (ie. you are dependent on them, and they’ll do it for their own storage/disks first) 3. They’ll build a common interface through which they can consume the events(ie. you are dependent on the virtualization vendor AND the hardware vendor to cooperate) or 4. They are about managing across the infrastructure for servers, storage and network(ie. they are dodging the question).

There are literally hundreds of examples like this if you need anything except a dedicated, single vendor stack including hardware+virtualization. This seems to be where Cisco and Oracle are lining up. I don’t think this is a fruitful direction and can’t really see this as advantageous to customers or vendors. Notwithstanding cloud, Google, Amazon et al. where you don’t deal with hardware at all, but have a whole separate set of issues, and standards and openness are equally important.

In an early morning session today, Tom Maguire, Senior Director of Technology Architecture, Office of the CTO on EMC’s Service-Oriented Infrastructure Strategy: Providing Services, Policies, and Archictecture models. Tom talked about lose coupling, and defining stateful and REST interfaces that would allow EMC to build products that “snap” together and don’t require a services engagement to integrate them. He talked also talked about moving away from “everyone discovering what they need” to a common, federated fabric.

This is almost as powerful message as that of Lewis or Maritz, but will get little or no coverage. If EMC can deliver/execute on this, and do it in a de jure or de facto published standard way, this will indeed give them a powerful platform that companies like Dell can partner in, and bring innovation and competitive advantge for our customers.

Robin Bloor asks what is dynamic infrastructure

Over on his have mac will blog blog, Robin Bloor asks What Does IBM Mean By Dynamic Infrastructure?

Rather than burden his comments section with a long trail of corrections, based on my suppositions, I thought I’d post my answer here and correct it as appropriate.

Robin, You might want to google for IBM Dynamic Infrastructure for MY SAP. or similar, or go look at this redbook. There is also a useful overview PowerPoint from Gerd Breiter, one of the architects and development leads, here

I’d guess the architects/development team for IDI have been moved internally from Systems Group to Tivoli. IDI was an early implementation of on demand and was developed in Boeblingen. As initially envisaged, IDI was a Systems Group initive and the bulk of the early implementation done before on demand, and then carried over and modified as and when possible.

Of course, I’m sure now that this mission is over in Tivoli the thinking and delivery will have evolved. Obviously cloud computing has become as major focus area in the industry since then, and would have to be factored in.

Unless you know better

IBM et clouds

I note from Cotes People over Process Redmonk blog, that Sam Palmisano, CEO at IBM, has given Erich Clemente, Vice President, Strategy and General Manager of Enterprise Initiatives the mission of sorting out IBM’s disperate cloud initiatives.

I worked for Erich for 3-years, he was a great 2nd line, had good vision and great business acumen, as a former Systems Engineer, understood technology better than I think a lot of people would give him credit for.

If I was still at IBM, I’d have loved to work with Erich on this, and helped him carve through the silos, the marketing treacle, the services dilema and the hosting potential. I only hope he doesn’t allow himself to get  tied up in knots by people trying to define global architectures and claims of leading by creating all encompassing standards.

Oh, Now it’s legacy IT that’s dead. Huh?

I got a pingback Dana Gardners ZDNet blog for my “Is SOA dead?” post. Dana, rather than addressing the issue I raised yesterday, just moved the goalposts, claiming “Legacy IT is dead“.

I agree with many of his comments, and after my post “Life is visceral“, which Dana so ably goes on to prove with his post. I liked some of the fine flowing language, some of it almost prosaic, especially this “We need to stop thinking of IT as an attached appendage of each and every specific and isolated enterprise. Yep, 2000 fully operational and massive appendages for the Global 2000. All costly, hugely redundant, unique largely only in how complex and costly they are all on their own.” – whatever that means?

However, thinking about a reasonable challenge for anyone considering jumping to a complete services or cloud/services, not migrating, not having a roadmap or architecture to get there, but as Dana suggests, grasping the nettle and just doing it.

One of the simplest and easiest examples I’ve given before for why I suspect as Dana would have it, “legacy  systems” exist, is becuase there are some problems you just can NOT be split apart a thousand times, whose data can NOT be replicated into a million pieces.

Let’s agree. Google handles millions of queries per seconds, as do ebay and Amazon, well probably. However, in the case of the odd goggle query not returning anything, as opposed to returning no results, no one really cares or understands, they just click the browser refresh button and wait. Pretty much the same for Amazon, the product is there, you click buy, and if every now and again there was one item of a product left at an Amazon store front, if someone else has bought it between the time you looked for it and decided to buy, you just suffer through the email that the item will be back in stock in 5-days after all, it will take longer than that to track down someone to discuss it with.

If you ran your banking or credit card systems this way, no one would much care when it came to queries. Sure, your partner is out shopping, you are home working on your investments. Your partner goes to get some cash, checks the balance and the money is there. You want to transfer a large amount of money into a money market account, you check and there amount is just there, you’ll transfer some more into the account overnight from your savings and loan and you know your partner only ever uses credit, right?. You both proceed, a real transactional system lets one of you proceed and the other fails, even if there is only 1-second, and possibly less difference between your transactions coming in.

In the google model, this doesn’t matter, it’s all only queries. If your partner does a balance check, a second or more after you’ve done a transfer, and see’s the the wrong balance, it will only matter when they are embarressed 20-seconds later trying to use that balance, that isn’t there anymore.

Of course, you can argue banks dont’ work like that, they reconcile balances at the end of the day. You will though when that exceptional balance charge kicks-in if both transactions work. Most banks systems are legacy systems from a different perspective, and should be dead. We, as customers, have been pushing for straight through processing for years, why should I wait for 3-days for a check to clear? 

So you can’t have it both ways, out of genuine professional understanding and interest, I’d like to see any genuine transaction based systems that are largely or wholly services based or that run in the cloud.

In order to what Dana advocates, move off ALL legacy systems, those transaction systems need to cope with 1000, and upto 2000 transactions per second. Oh yeah, it’s not just banks that use “legacy IT”, there are airlines, travel companies, anywhere where there is finite product and an almost infinite number of customers.

Remember, Amazon and ebay and paypal don’t do their own credit card processing as far as I’m aware, they are just merchants who pass the transaction on to a, err, legacy system.

Some background reading should include one that I used early in my career. Around the time I was advocating moving Chemical Bank, NY’s larger transaction systems to virtual machines, which we did. I was attending VM Internals education at Amdahl in Columbia, MD. One of the instructors thought I might find the paper useful.

It was written by a team at Tandem Computer and Amdahl, including the late, great Jim Gray. It was written in 1984. Early on in this paper they describe environments that support 800 transactions per second in 1984. Yes, 1984. These days, even in the current economic environment, 1000tps are common, and 2000tps are table stakes.

Their paper is preserved and online here on microsoft.com

And finally, since I’m all about context. I’m an employee of Dell, I started work there today. What is written here is my opinion, based on 34-years IT experience and much of it garned from the sharp end, designing an I/O subsystem to support an large NY banks transactional, inter-bank transfer system, as well as being responsible for the worlds first virtualized credit card authorization system etc. but I didn’t work for Dell, or for that matter, IBM then. 

Speakers corner anyone?

Is SOA dead?

There has been a lot of fuss since the start of the new year around the theme “SOA is dead”. Much of this has been attributed to Anne Thomas Manes blog entry on the Burton Groups blog, here.

Infoworlds Paul Krill jumper on the bandwagon with a SOA obituary, qouting Annes work and say “SOA is dead but services will live on”. A quick fire response came on a number of fronts, like this one from Duane Nickull at Adobe, and then this from James Governor at Redmonk, where he charismatically claims, “everything is dead”.

First up, many times in my career, and James touches on a few of the key ones, since we were there together, or rather, I took advantage of his newness and thirst for knowledge as a junior reporter, to explain to him how mainframes worked, and what the software could be made to do. I knew from 10-years before I met James that evangelists and those with an agenda, would often claim something was “dead”. It came from the early 1980’s mainframe “wars” – yes, before there was a PC, we were having our own internal battles, this was dead, that was dead, etc.

What I learned from that experience, is that technical people form crowds. Just like the public hangings in the middle ages, they are all too quick to stand around and shout “hang-him”. These days it’s a bit more complex, first off there’s Slashdot, then we have the modern equivalent of speakers corner, aka blogs, where often those who shout loudest and most frequently, get heard more often. However, what most people want is not a one sided rant, but to understand the issues. Claiming anything is dead often gives the claimer the right not to understand the thing that is supposedly “dead” but to just give reasons why that must be so and move on to give advice on what you should do instead. It was similar debate last year that motivated me to document my “evangelsim” years on the about page on my blog.

The first time I heard SOA is dead, wasn’t Annes blog, it wasn’t even as John Willis, aka botchagalupe on twitter, claims in his cloud drop #38 him and Michael Cote of Redmonk last year. No sir, it was back in June 2007, when theregister.co.uk reprinted a Clive Longbottom, Head of Research at Quocirca, under the headline SOA – Dead or Alive?

Clive got closest to the real reasons of why SOA came about, in my opinion, and thus why SOA will prevail, despite rumours of its’ demise. It is not just services, from my perspective, it is about truly transactional services, which are often part of a workflow process.

Not that I’m about to claim that IBM invited SOA, or that my role in either the IBM SWG SOA initiative, or the IBM STG services initiative was anything other than as a team player rather than as a lead. However, I did spend much of 2003/4 working across both divisions, trying to explain the differences and similarities between the two, and why one needed the other, or at least its relationships. And then IBM marketed the heck out of SOA.

One of the things we wanted to do was to unite the different server types around a common messaging and event architecture. There was  almost no requirement for this to be syncronous and a lot of reasons for it to be services based. Many of us had just come from the evolution of object technology inside IBM and from working on making Java efficient within our servers. Thus, as services based approach seemed for many reasons the best one. 

However, when you looked at the types of messages and events that would be sent between systems, many of them could be cruicial to effective and efficient running of the infrastructure, they had in effect, transactional charateristics. That is, given Event-a could initiate actions A, then b, then c and finally d. While action-d could be started before action-c, it couldn’t be started until action-b was completed, and this was dependent on action-a. Importantally, none of these actions should be performed more than once for each instance of an event.

Think failure of a database or transactional server. Create new virtual server, boot os, start application/database server, rollback incomplete transactions, take over network etc. Or similar.

Around the same time, inside IBM, Beth Hutchison and others at IBM Hursley, along with smart people like Steve Graham, now at EMC, and Mandy Chessell also of IBM Hursley were trying to solve similar trascational type problems over http and using web services.

While the Server group folks headed down the Grid, Grid Services and ultimately Web Service Resource  Framework, inside IBM we came to the same conclusion, incompatible messages, incompatible systems, different architectures, legacy systems etc. need to interoperate and for that you need a framework and set of guidelines. Build this out from an infrastructure layer, to an application level; add in customer applications and that framework; and then scale it in any meaningful, that need more than a few programmers working concurrently on the same code, or on the same set of services, and what you needed was a services oriented architecture.

Now, I completely get the REST style of implementation and programming. There is no doubt that it could take over the world. From the perspective of those frantically building web mashups and cloud designs, already has. In none of the “SOA is dead” articles has anyone effectively discussed syncronous transactions, in fact apart from Clive Longbottoms piece, no real discussion was given to workflow, let alone the atomic transaction.

I’m not in denial here of what Amazon and Google are doing. Sure both do transactions, both were built from the ground-up around a services based architecture. Now, many of those who argue that “SOA is dead” are often those who want to move onto the emporers new clothes. However, as fast as applications are being moved to the cloud, many businesses are nowhere in sight moving or exploiting the cloud. To help them get there, they’ll need to know how to do it and for that they’ll need a roadmap, a framework and set of guidelines, and if it includes their legacy applications and systems, how they get there, For that, they’ll likely need more than a strategy, they’ll need a services “oriented” architecture.

So, I guess we’ve arrived at the end, the same conclusion that many others have come to. But for me it is always about context.

I have to run now, literally. My weekly long run is Sunday afternoon and my running buddy @mstoonces will show up any minute. Also, given I’m starting my new job, I’m not sure how much time I’ll have to respond to your comments, but I welcome the discussion!

Any to any fabric

I’ve spent the last few months working on IBMs’ plans for next generation data center fabric. It is a fascinating area, one ripe for innovation and some radical new thinking. When we were architecting on demand, and even before that, working on the Grid Toolbox, one of the interesting futures options was InfiniBand or IB.

What made IB interesting was that you could put logic in either end of the IB connection. Thus turning a standard IB connection into a custom switched connector by dropping your own code into the host channel adapter (HCA) or target channel adapter (TCA). Anyway, I’m getting off course. The point was that we could use an industry standard protocol and connection to do some funky platform specific things like specific cluster support, quality of service assertion, or security delegation without compromising the standard connection. This could be done between racks at the same speed and latency as between systems in the same rack. This could open up a whole new avenue of applications and would help to distribute work inside the enterprise, hence the Grid hookup. It never played out that way for many reasons.

Over in the Cisco Datacenter blog, Douglas Gourlay is considering changes to his “theory” on server disaggregation and network evolution – he theorises that over time everything will move to the network, including memory. Remember, the network is the computer?

He goes on to speculate that “The faster and more capable the network the more disaggregated the server becomes. The faster and more capable a network is the more the network consolidates other network types.” and wants time to sit down and “mull over if there is an end state”.

Well nope, there isn’t and end state. First off, the dynamics of server design and environmental considerations mean that larger and larger centralized computers will still be in vogue for a long time to come. Take for example iDataplex. It isn’t a single computer, but what is these days? In their own class are also the high end Power 6 595 Servers, again not really single servers but intended to multi-process, to virtualise etc. There is a definite trend for row scale computing, where additional capacity is dynamically enabled off a single set of infrastructure components and while you could argue these are distributed computers, just within the row, they are really composite computers.

As we start to see fabric settle down and become true fabrics, rather than either storage/data connections or network connections, new classes of use, new classes of aggregated systems will be designed. This is what really changes computing landscape, how they are used, not how they are built. The idea that you can construct a virtual computer from a network was first discussed by former IBM guru Irving Wladawsky-Berger. His Internet computer illustration was legend inside IBM and used and re-used in presentations throughout the late 1990s.

However, just like the client/server vision of the early ’90s, the distributed computing vision of the mid 90’s, and Irvings’ Internet computer of the late 1990s, plus all those those that came before and since, the real issue is how to use what you have, and what can be done better. That for me is the crux of the emerging world of 10Gb Ethernet, Converged Enhanced Ethernet, fibre channel over Ethernet et al. Don’t take existing systems and merely break them apart and network them, because you can.

As data center fabrics allow low latency, non-blocking, any to any and point to point communication, why force traffic through a massive switch and lift system to enable this to happen? Enabling storage to talk to tapes, for networks to access storage without going via a network switch or a server, enabling server to server, server to client, device to device surely has some powerful new uses. The live dynamic streaming and analysis of all sorts of data, without having to have it pass through a server. Appliances which dynamically vet, validate and operate on packets as they pass through from one point to another.

It’s this combination of powerful server computers, distributed network appliances, and secure fabric services that

Since Douglas ended his post with a qoute, I thought this apropo “And each day I learn just a little bit more, I don’t know why but I do know what for, If we’re all going somewhere let’s get there soon, Oh this song’s got no title just words and a tune”. – Bernie Taupin.

Cloud commentry

I posted my thoughts on some comments received, as well as a few emails I got offblog, as a response in this thread.

More on blue clouds

Thanks for the comments and emails on my recent posts on cloud computing wrt IBM, I’ll post some more useful discussion, feedback shortly but am bust traveling now. This flashed past my screen this morning though, net net, it is a press release announcing that our HiPods team is opening a cloud computing center in Dublin. Worth a brief read.

And so on Amazon and clouds

Here is the post I mentioned in yesterday’s Clouds and the governor post. I’ve deleted some duplicate comment but wanted to publish some of the things left over.

It was an unexpected pleasure to catch-up with Redmonk maestro and declarative liver(?) James Governor over Christmas, while back in the UK. It wasn’t a tale of Christmas past, but certainly good to see him at Dopplr mansions in East London. Sorry to Matt and the Dopplr guys for busting in on them in my xmas hat and not introducing myself.

James and I didn’t have much time together, I’d just got through handing in my IBM UK badge, and returning all three of their laptops, bidding fairwell to Larry, Colin and Paul, and wanted to head off to see my parents. We squeezed in a quick coffee and a chat, James was keen to discuss his theory on Linux distributions, I didn’t have any reason to really pitch for, or against this and just told him what I knew. We didn’t have time for much else, we did discuss erlang briefly both as a language, but also on explotation of multi-core, multi-threaded chips, and I’ll come back to that one day. What we didn’t get to discuss was Amazon, cloud computing and James on/off theory on IBM and Amazon.

There is no doubt in my mind that on demand computing, cloud, ensembles, call it what you will computing is happening and will continue apace. I’ve been convinced since circa ‘98, and spent 6-weeks one summer in 1999 with now StorageTek/Sun VP, then IBM System z marketing guy, Nigel Dessau getting me in to see IBM Execs to discuss the role of utility computing. After that I did a stint in the early Grid days, and then on demand architecture and design.

So, whats this with Amazon? Yes, their EC2 and S2 offering are pretty neat; yes Google is doing some fascinating things building their own datacenters and machines, so is Microsoft and plenty of others. One day, is it likely that most computing will come over the wire, over the air, from the utility? Yes.

Thats not just a client statement, there is plenty of proof that is happening already, but a server or applications statement. Amazon API’s are really useful. I wish we had some application interfaces, and systems that worked the same way, or perhaps as James might have it, we had Amazons web services, perhaps without the business that goes behind it. Are we interested in Amazon, don’t know, I’m neither in corporate or IBM Software group business development.

It comes back to actionable items, buying, partnering or otherwise adopting Amazons web services, really wouldn’t move the ball forward for the bulk of our customers.

Sure, it would open up a whole new field of customers who are looking for innovative ways to get computing at lower cost, so are our existing customers. This would be of little use short term as there are few tools built around. I work at a company that helps customers. There are some things we are doing that are very interesting for the future, but what is more interesting is bridging from the current world and the challenges of doing that. Like every new technology, cloud computing will have to be eased into. We can’t suddenly expect customers to drop what they have and get up into the clouds and so that means integration.

Clouds and the governor

I’ve been meaning to respond to Monkchips speculation over IBM and Amazon from last year his follow-up why Amazon don’t need IBM. James and I met-up briefly before Christmas, the day I resigned from IBM UK but we ran out of time to discuss that. I wrote and posted a draft and never got around to finishing it, I was missing context. Then yesterday James published a blog entry entitled “15 Ways to Tell Its Not Cloud Computing”.

The straw that broke the camels back was today, on chinposin Friday, James was clearly hustling for a bite when he tweeted “amazed i didn’t get more play for cloud computing blog”.

Well here you go James. Your analysis and simple list of 15-reasons why it is not a cloud is entertaining, but it’s not analysis, it’s cheerleading.

I’m not going to trawl through the list and dissect it one by one, I’ll just go with the first entry and then revert to discussing the bigger issue. James says “If you peel back the label and its says “Grid” or “OGSA” underneath… its not a cloud.” – Why is that James? How do you advocate organizations build clouds?