Serverless computing

I’ve been watching and reading on developments around serverless computing. I’ve never used it myself so only have limited understanding. However, given my extensive knowledge of servers, firmware, OS, Middleware and business applications, I’ve had a bunch of questions.

Many of my questions are echoed in this excellent write-up by Jeremy Daly on the recent Serverless NYC event.

For traditional enterprise type customers, it’s well worth reviewing the notes of the issues highlighted by Jason Katzer, Director of Software Engineering at Capital One. While some attendees talk about “upwards of a BILLION transactions per month” using serverlesss, that’s impressive, that’s still short of many enterprise requirements, it translates to 34.5-million transactions per day.

Katzer notes that there are always bottlenecks and often services that don’t scale the same way that your serverless apps do. Worth a read, thanks for posting Jeremy.

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.

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?

On a clear day, can you see a cloud?

It’s not very often these days I get to escape my bunker in IBM Austin. On December the 6th I was asked to speak at the NCOIC Conference and work group in St Petersburg, Florida.

The invitation came in a roundabout way, via Massimo Re Ferre from IBM Italy, and Bob Marcus at SRI. The agenda and speakers looked interesting, and so I decided to take the opportunity and go run some of the current thinking by an influential audience. Speaking right before me was Roger Smith, CTO of the US Army PEO STRI division, and he gave a fascinating talk on warefare simulation and training.

I decided to talk about the evolution of Grid, On Demand, SOA and the Blue Cloud implementation of a Service Oriented Infrastructure. We had a useful discussion on what could be done now, net answer, pretty much all of it. You can’t buy it as a product or solution, but you can build it from either IBM or open standards/source parts now.

What’s made the difference is the ability to build around a common, composite infrastructure for management. Previously we’d tried to build and deliver this everywhere, now it’s much more focussed on platform by platform based implementation. Get it right in one place, move it to another.

I’ve posted the slides on slideshare.net here and I’ve also put the PDF on wordpress for download, here.