Thursday, May 06, 2010
The Chewbacca Defense
I use it all the time when I run into things that just don't make sense. It's a light-hearted way of telling people they need to think more!
Tuesday, May 04, 2010
Monday, May 03, 2010
Plan 9 operating system
While reading about cult movies I was suddenly reminded about the Plan 9 operating system. It came out while we were deep into the original Arjuna development and a heavy user of Sun Sparcs, so naturally it was something we had to investigate (along with the Spring operating system)! It had some interesting ideas, and with distribution at its heart it was very relevant to what we were researching (the University was the home of the Newcastle Connection, with some similar aims from many years before.)
Anyway, it was an interesting time and I'm pleasantly surprised to learn that there's still work going on into Plan 9, twenty something years after it began. Very cool!
Anyway, it was an interesting time and I'm pleasantly surprised to learn that there's still work going on into Plan 9, twenty something years after it began. Very cool!
Friday, April 30, 2010
Cloudy days ahead for applications?
I've been thinking a lot recently about the Cloud and its potential as a disruptive technology. I got to wondering about how we arrived at where we are today, and one of my favourite books sprang to mind as a way of articulating that, at least to myself.
To misuse HG Wells ever so slightly, "No one would have believed in the last years of the first decade of the twenty first century that the world of enterprise software was being watched keenly and closely by intelligences greater than man's and yet as mortal as his own; that as men busied themselves about their various concerns they were scrutinised and studied, perhaps almost as narrowly as a man with a microscope might scrutinise the transient creatures that swarm and multiply in a drop of water. With infinite complacency men went to and fro over this globe about their little affairs, serene in their assurance of their empire over middleware. It is possible that the infusoria under the microscope do the same. No one gave a thought to some of the relatively new companies as sources of danger to their empires, or thought of them only to dismiss the idea that they could have a significant impact on the way in which applications could be developed and deployed. Yet across the gulf of cyberspace, minds that are to our minds as ours are to those of the beasts that perish, intellects vast and cool and unsympathetic, regarded enterprise applications with envious eyes, and slowly and surely drew their plans against us."
Of course the rise of Cloud practitioners and vendors was in no way as malevolent as the Martians, but the potential impact on the middleware industry may be no less dramatic (or drastic). Plus there was a level of ignorance (arrogance) on behalf of some middleware vendors against the likes of Amazon and Google just as the Victorians believed themselves unassailable and masters of all they surveyed.
But there are still a number of uncertainties around where this new wave is heading. One of them is exactly what does this mean for applications? On the one hand there are those who believe applications and their supporting infrastructure (middleware) must be rewritten from scratch. Then there are others who believe existing applications must be supported. I've said before that I believe as an industry we need to be leveraging what we've been developing for the past few decades. Of course some things need to change and evolve, but if you look at what most people who are using or considering using Cloud expect, it's to be able to take their existing investments and Cloudify them.
This shouldn't come as a surprise. If you look at what happened with the CORBA-to-J2EE transition, or the original reason for the development of Web Services, or even how a lot of the Web works, they're all examples of reusing existing investments to one degree or another. Of course over the years the new (e.g., J2EE) morphed away from the old, presenting other ways in which to develop applications to take advantage of the new and different capabilities those platforms offered. And that will happen with Cloud too, as it evolves over the next few years. But initially, if we're to believe that there are economic benefits to using the Cloud, then they have to support existing applications (of which there are countless), frameworks (of which there are many) and skill sets of the individuals who architect them, implement them and manage them (countless again). It's outsourcing after all.
To misuse HG Wells ever so slightly, "No one would have believed in the last years of the first decade of the twenty first century that the world of enterprise software was being watched keenly and closely by intelligences greater than man's and yet as mortal as his own; that as men busied themselves about their various concerns they were scrutinised and studied, perhaps almost as narrowly as a man with a microscope might scrutinise the transient creatures that swarm and multiply in a drop of water. With infinite complacency men went to and fro over this globe about their little affairs, serene in their assurance of their empire over middleware. It is possible that the infusoria under the microscope do the same. No one gave a thought to some of the relatively new companies as sources of danger to their empires, or thought of them only to dismiss the idea that they could have a significant impact on the way in which applications could be developed and deployed. Yet across the gulf of cyberspace, minds that are to our minds as ours are to those of the beasts that perish, intellects vast and cool and unsympathetic, regarded enterprise applications with envious eyes, and slowly and surely drew their plans against us."
Of course the rise of Cloud practitioners and vendors was in no way as malevolent as the Martians, but the potential impact on the middleware industry may be no less dramatic (or drastic). Plus there was a level of ignorance (arrogance) on behalf of some middleware vendors against the likes of Amazon and Google just as the Victorians believed themselves unassailable and masters of all they surveyed.
But there are still a number of uncertainties around where this new wave is heading. One of them is exactly what does this mean for applications? On the one hand there are those who believe applications and their supporting infrastructure (middleware) must be rewritten from scratch. Then there are others who believe existing applications must be supported. I've said before that I believe as an industry we need to be leveraging what we've been developing for the past few decades. Of course some things need to change and evolve, but if you look at what most people who are using or considering using Cloud expect, it's to be able to take their existing investments and Cloudify them.
This shouldn't come as a surprise. If you look at what happened with the CORBA-to-J2EE transition, or the original reason for the development of Web Services, or even how a lot of the Web works, they're all examples of reusing existing investments to one degree or another. Of course over the years the new (e.g., J2EE) morphed away from the old, presenting other ways in which to develop applications to take advantage of the new and different capabilities those platforms offered. And that will happen with Cloud too, as it evolves over the next few years. But initially, if we're to believe that there are economic benefits to using the Cloud, then they have to support existing applications (of which there are countless), frameworks (of which there are many) and skill sets of the individuals who architect them, implement them and manage them (countless again). It's outsourcing after all.
Thursday, April 29, 2010
SOA metrics post
I wrote this a while ago and someone forgot to let me know it had finally been published. Better late than never I suppose.
Wednesday, April 28, 2010
A Platform of Services
Back in the 70's and 80's, when multi-threaded processes and languages were still very much on the research agenda, distributed systems were developed based on a services architecture, with services as the logical unit of deployment, replication and fault containment. If you wanted to service multiple clients concurrently then you'd typically fire off one server instance per client. Of course your servers could share information between themselves if necessary to give the impression of a single instance, using sockets, shared memory, disk etc.
Now although those architectures were almost always forced on us by limitations in the operating systems, languages and hardware at the time, it also made a lot of sense to have the server as the unit of deployment, particularly from the perspectives of security and fault tolerance. So even when operating systems and languages started to support multi-threading, and we started to look at standardising distributed systems with ANSA, DCE and CORBA, the service remained a core part of the architecture. For example, CORBA has the concept of Core Services, such as persistence, transactions, security and although the architecture allows them to be colocated in the same process as each other or the application for performance reasons, many implementations continued to support them as individual services/processes.
Yes there are trade-offs to be made between, say, performance and fault tolerance. Tolerating the crash of a thread within a multi-threaded process is often far more difficult than tolerating the crash of an individual process. In fact a rogue thread could bring down other threads or prevent them from making forward progress, preventing the process (server) from continuing to act on behalf of multiple clients. However, invoking services as local instances (e.g., objects) in the same process is a lot quicker than if you have to resort to message passing, whether or not based on RPC.
However, over the past decade or so as threading became a standard part of programming languages and processor performance increased more rapidly than network speeds, many distributed systems implementations moved to colocating services as the default, with the distributed aspect really only applying to the interactions between the business client and the business service. In some cases this was the only way in which the implementation worked, i.e., putting core infrastructure services in separate processes and optionally on different machines was simply no longer an option.
Of course the trade-offs I mentioned kicked in and were made for you (enforced on you) by the designers, often resulting in monolithic implementations. With the coining of the SOA term and the rediscovery of services and loose coupling, many started to see services as beneficial to an architect despite any initial issues with performance. As I've said before, SOA implementations based on CORBA have existed for many years, although of course you need more than just services to have SOA.
Some distributed systems implementations that embraced SOA started to move back to a service-oriented architecture internally too. Others were headed in that direction anyway. Still others stayed where they were in their colocated, monolithic worlds. And then came Cloud. I'm hoping that as an industry we can leverage most of what we've been implementing over the past few decades, but what architecture is most conducive to being able to take advantage of the benefits Cloud may bring? I don't think we're quite there yet to be able to answer that question in its entirety, but I do believe that it will be based on an architecture that utilises services. So if we're discussing frameworks for developing and deploying applications to the cloud we need to be thinking that those core capabilities needed by the application (transactions, security, naming etc.) will be remote, i.e., services, and they may even be located on completely different cloud infrastructures.
Now this may be obvious to some, particularly given discussions around PaaS and SaaS, but I'm not so sure everyone agrees, given what I've seen, heard and read over the past months. What I'm particularly after is a services architecture that CORBA espoused but which many people overlooked or didn't realise was possible, particularly if they spoke with the large CORBA vendors at the time: an architecture where the services could be from heterogeneous vendors as well as being based on different implementation languages. This is something that will be critical for the cloud, as vendors and providers come and go, and applications need to choose the right service implementation dynamically. The monolithic approach won't work here, particularly if those services may need to reside on completely different cloud infrastructures (cf CORBA ORB). I'm hoping we don't need to spend a few years trying to shoehorn monoliths in to this only to have that Eureka moment!
The lack of standards in the area will likely impact interoperability and portability in the short term, but once standards do evolve those issues should be alleviated somewhat. The increasing use of REST should help immediately too though.
Now although those architectures were almost always forced on us by limitations in the operating systems, languages and hardware at the time, it also made a lot of sense to have the server as the unit of deployment, particularly from the perspectives of security and fault tolerance. So even when operating systems and languages started to support multi-threading, and we started to look at standardising distributed systems with ANSA, DCE and CORBA, the service remained a core part of the architecture. For example, CORBA has the concept of Core Services, such as persistence, transactions, security and although the architecture allows them to be colocated in the same process as each other or the application for performance reasons, many implementations continued to support them as individual services/processes.
Yes there are trade-offs to be made between, say, performance and fault tolerance. Tolerating the crash of a thread within a multi-threaded process is often far more difficult than tolerating the crash of an individual process. In fact a rogue thread could bring down other threads or prevent them from making forward progress, preventing the process (server) from continuing to act on behalf of multiple clients. However, invoking services as local instances (e.g., objects) in the same process is a lot quicker than if you have to resort to message passing, whether or not based on RPC.
However, over the past decade or so as threading became a standard part of programming languages and processor performance increased more rapidly than network speeds, many distributed systems implementations moved to colocating services as the default, with the distributed aspect really only applying to the interactions between the business client and the business service. In some cases this was the only way in which the implementation worked, i.e., putting core infrastructure services in separate processes and optionally on different machines was simply no longer an option.
Of course the trade-offs I mentioned kicked in and were made for you (enforced on you) by the designers, often resulting in monolithic implementations. With the coining of the SOA term and the rediscovery of services and loose coupling, many started to see services as beneficial to an architect despite any initial issues with performance. As I've said before, SOA implementations based on CORBA have existed for many years, although of course you need more than just services to have SOA.
Some distributed systems implementations that embraced SOA started to move back to a service-oriented architecture internally too. Others were headed in that direction anyway. Still others stayed where they were in their colocated, monolithic worlds. And then came Cloud. I'm hoping that as an industry we can leverage most of what we've been implementing over the past few decades, but what architecture is most conducive to being able to take advantage of the benefits Cloud may bring? I don't think we're quite there yet to be able to answer that question in its entirety, but I do believe that it will be based on an architecture that utilises services. So if we're discussing frameworks for developing and deploying applications to the cloud we need to be thinking that those core capabilities needed by the application (transactions, security, naming etc.) will be remote, i.e., services, and they may even be located on completely different cloud infrastructures.
Now this may be obvious to some, particularly given discussions around PaaS and SaaS, but I'm not so sure everyone agrees, given what I've seen, heard and read over the past months. What I'm particularly after is a services architecture that CORBA espoused but which many people overlooked or didn't realise was possible, particularly if they spoke with the large CORBA vendors at the time: an architecture where the services could be from heterogeneous vendors as well as being based on different implementation languages. This is something that will be critical for the cloud, as vendors and providers come and go, and applications need to choose the right service implementation dynamically. The monolithic approach won't work here, particularly if those services may need to reside on completely different cloud infrastructures (cf CORBA ORB). I'm hoping we don't need to spend a few years trying to shoehorn monoliths in to this only to have that Eureka moment!
The lack of standards in the area will likely impact interoperability and portability in the short term, but once standards do evolve those issues should be alleviated somewhat. The increasing use of REST should help immediately too though.
Tuesday, April 20, 2010
Some things really shouldn't be changed
There are some things that shouldn't change, no matter how good an idea it may seem at first glance. For instance, the original Coke formula, the name of Coco Pops, and remaking the Searchers. Then again there are some things that really do benefit from a revision, such as Battlestar Galactica or the laws of gravity.
So it was with some trepidation that I heard they were going to remake The Prisoner. The original is a classic of 1960's TV that stood the test of time. I remember watching it at every opportunity while growing up (in the days when we only had 4 TV channels, so repeats were few and far between). Patrick McGoohan was The Prisoner and while the stories were often "out there", the series had this pulling power that made it unmissable.
I wondered how anyone could remake it and capture the essence of the original show? But I decided to be open minded and sat down the other night to watch the first episode of the new series. Afterwards the first thought I had was "I'll never get that hour back again!" As a remake, it was terrible. As a stand-alone series, it was probably passable.
It looks like another good idea bites the dust. I'll be taking the series off my Sky+ reminder now and if I'm stuck for something to do at that time I'll either watch some wood warp or maybe watch some paint dry: both would be far more stimulating activities!
So it was with some trepidation that I heard they were going to remake The Prisoner. The original is a classic of 1960's TV that stood the test of time. I remember watching it at every opportunity while growing up (in the days when we only had 4 TV channels, so repeats were few and far between). Patrick McGoohan was The Prisoner and while the stories were often "out there", the series had this pulling power that made it unmissable.
I wondered how anyone could remake it and capture the essence of the original show? But I decided to be open minded and sat down the other night to watch the first episode of the new series. Afterwards the first thought I had was "I'll never get that hour back again!" As a remake, it was terrible. As a stand-alone series, it was probably passable.
It looks like another good idea bites the dust. I'll be taking the series off my Sky+ reminder now and if I'm stuck for something to do at that time I'll either watch some wood warp or maybe watch some paint dry: both would be far more stimulating activities!
Monday, April 19, 2010
Volcano activity spoils conference
I was an invited speaker as the first DoD sponsored SOA Symposium last year and really enjoyed it. I got invited to this year's event and was going to speak on SOA and REST. I think it would have been as good as last year (will be as good as last year), but unfortunately a certain volcano in Iceland has meant that my flights have been canceled. So I'll have to watch from afar and hope that the troubles in the sky clear up soon. My best wishes go to the event organizers and I hope that next year presents an opportunity to attend for a second time.
Tuesday, March 23, 2010
A sad day
I just heard that Robin Milner has died. I met him a couple of times and found him approachable, very articulate and friendly. A great loss. My sympathies to his family.
Friday, March 19, 2010
Meetings and work
Irresective of whatever title(s) I may have, I'm a software engineer. For well over 30 years I've been cutting code; whether it's games (my very first program was battleships on a paper-tape machine) or transaction systems, I get a lot of enjoyment out of it. I also love learning new programming languages (something that strangely enough doesn't translate to human languages, where I'm not so strong.) I don't think I'm happier than when I'm coding.
Now over the years I've spent a lot of time in various meetings, including standards efforts, project planning, customer engagements, architecture discussions etc. Some of them are also implicit, e.g., Stuart and I would talk a lot, often while coding, because we shared an office for over a decade. But most of them are explicit and you don't get a chance to code at the same time (paying customers tend to want your full attention, for instance!) I've been at a project planning meeting today in Brussels and although I could code on the evenings while in the hotel, it's not a lot of time to spend.
In general the majority of my days revolve around talking and writing documents. Most days I'll spend in meetings, either physically in a room with others or on a phone with them. Time for coding is limited during the day, so again it tends to happen late evenings, very early in the morning, weekends and on holiday. At times I believe I need to do it to keep myself grounded (and sane). And it doesn't have to be work coding that lets me energize my batteries (I think all engineers have their pet projects!)
When I was coding full-time it was easy for me to look back and see what I'd been doing with my time. These days it's not quite so easy as there is often no concrete evidence of what's been done on a daily basis. Of course that's a very short sighted view and when I look across the months/years and see the results those meetings generated it's very different. But for an engineer who has been coding for 75% of his life, it's hard at times when I'm sat in yet another meeting with a terminal, emacs and a programming language calling to me from a few inches away. Yes, meetings are important for what I have to do today, but my heart will always be elsewhere. Now back to some coding!
Now over the years I've spent a lot of time in various meetings, including standards efforts, project planning, customer engagements, architecture discussions etc. Some of them are also implicit, e.g., Stuart and I would talk a lot, often while coding, because we shared an office for over a decade. But most of them are explicit and you don't get a chance to code at the same time (paying customers tend to want your full attention, for instance!) I've been at a project planning meeting today in Brussels and although I could code on the evenings while in the hotel, it's not a lot of time to spend.
In general the majority of my days revolve around talking and writing documents. Most days I'll spend in meetings, either physically in a room with others or on a phone with them. Time for coding is limited during the day, so again it tends to happen late evenings, very early in the morning, weekends and on holiday. At times I believe I need to do it to keep myself grounded (and sane). And it doesn't have to be work coding that lets me energize my batteries (I think all engineers have their pet projects!)
When I was coding full-time it was easy for me to look back and see what I'd been doing with my time. These days it's not quite so easy as there is often no concrete evidence of what's been done on a daily basis. Of course that's a very short sighted view and when I look across the months/years and see the results those meetings generated it's very different. But for an engineer who has been coding for 75% of his life, it's hard at times when I'm sat in yet another meeting with a terminal, emacs and a programming language calling to me from a few inches away. Yes, meetings are important for what I have to do today, but my heart will always be elsewhere. Now back to some coding!
Monday, March 15, 2010
Dr Professor or Professor Dr?
Since I officially left The University I've been a Research Fellow (I was in my late 20's when the photo was taken), along with Stuart. The role involves a range of things such as being on PhD thesis committees, helping with research, co-authoring papers etc. It's something from which I've received a lot of enjoyment and satisfaction, and I think it's an important counterpoint to my normal day job.
It's a position that I think is a privilege. So you can imagine how I felt today when they made me a Professor! Despite the number of years I spent at The University it's a position I never thought I'd achieve, particularly after I left to pursue a career path through the likes of Arjuna (x2), Bluestone, HP, JBoss and Red Hat. I definitely need to thank Santosh, who over the past 20+ years has been my boss, colleague and friend. He's also epitomised for me what it means to be a Professor, something which I think has positively impacted who I am to this day.
It's a position that I think is a privilege. So you can imagine how I felt today when they made me a Professor! Despite the number of years I spent at The University it's a position I never thought I'd achieve, particularly after I left to pursue a career path through the likes of Arjuna (x2), Bluestone, HP, JBoss and Red Hat. I definitely need to thank Santosh, who over the past 20+ years has been my boss, colleague and friend. He's also epitomised for me what it means to be a Professor, something which I think has positively impacted who I am to this day.
QCon London slides on line
I just got confirmation that the QCon slides are on line now, with mine available at this location.
Sunday, March 14, 2010
Every Cloud has a silver lining
I've already stated that I think there's a lot Cloud can learn from the past and yet there is also more evolution of current approaches to come where Cloud is concerned. However, that doesn't mean that adding a little bit of Cloud pixie dust to everything immediately makes it better or more relevant.
I'm one of the reviewers for a special journal issue on Engineering Middleware for Service-Oriented Computing. Unfortunately several of the papers I've read seemed to be under the assumption that adding the words/terms 'Cloud' or 'SOA' to their works would make them relevant, when in fact it had almost the opposite effect. It didn't work with other technological waves such as Web Services or Java. If your work is relevant to a specific technology or a range of technologies then it should be obvious from the start and attempts to artificially push the reader into joining mental dots or making "intuitive leaps" reflect poorly on the author.
I'm one of the reviewers for a special journal issue on Engineering Middleware for Service-Oriented Computing. Unfortunately several of the papers I've read seemed to be under the assumption that adding the words/terms 'Cloud' or 'SOA' to their works would make them relevant, when in fact it had almost the opposite effect. It didn't work with other technological waves such as Web Services or Java. If your work is relevant to a specific technology or a range of technologies then it should be obvious from the start and attempts to artificially push the reader into joining mental dots or making "intuitive leaps" reflect poorly on the author.
Saturday, March 13, 2010
QCon London 2010 update
I mentioned earlier that I was presenting at QCon London. Well I had a good time at QCon giving a presentation which was basically about lessons learnt while developing, using and selling transaction systems. Hopefully the slides will go up soon, but it seemed to go down well. According to the organizers, it has the second highest audience for the track, which given that people were sitting on the floor, didn't surprise me. Everyone seemed to enjoy the talk and I hope they got as much out of it as I got putting it together.
What I did realise as I was giving the session was that I really have enough material for 4 or 5 presentations. Therefore, I may do some deep dives into specific aspects of the current presentation. I may even realise these as blog entries as well.
What I did realise as I was giving the session was that I really have enough material for 4 or 5 presentations. Therefore, I may do some deep dives into specific aspects of the current presentation. I may even realise these as blog entries as well.
Thursday, March 04, 2010
QCon London 2010
I'm going to QCon London again and speaking about one of my favourite subjects. If you're around then come by and say hello. Which reminds me ... I need to write the presentation!
Red Hat and Newcastle University
It's taken a while to get all of the pieces of the puzzle together, but we've now got a formal relationship with the University. As one of my friends would say: Onward!
Monday, March 01, 2010
Saturday, February 13, 2010
Cloud as the death of middleware?
Over the last few months I've been hearing and reading people suggesting that the Cloud ([fill in your own definition]) is either the death of middleware, or the death of "traditional" middleware. What this tells me is that those individuals don't understand the concepts behind middleware ("traditional" or not). In some ways that's not too hard to understand given the relatively loose way in which we use the term 'middleware'. Often within the industry middleware is something we all understand when we're talking about it, but it's not something that we tend to be able to identify clearly: what one person considers application may be another's middleware component. In my world, middleware is basically anything that exists above the operating system and below the application (I think the fact that these days we tend to ignore the old ISO 7 Layer stack is a real shame because that can only help such a definition.)
But anyway, middleware has existed in one form or another for decades. There are obvious examples of "it" including DCE, CORBA, JEE and .NET, but then some other not so obvious ones such as the Web: yes, the WWW is a middleware system, including most of the usual suspects such as naming, addressing, security, message passing etc. And yes, over the past few years I've heard people suggest that the Web is also the death of middleware. For the same reasons that Cloud isn't its deathknell, neither was the Web: middleware is ubiquitous and all but the most basic applications need "it", where "it" can be a complete middleware infrastructure such as JEE or just some sub-components, such as security or transactions. Now this doesn't mean that what consitutes middleware for the Cloud is exactly what we've all been using over the past few years. That would be as crazy a suggestion as assuming CORBA was the ultimate evolution of middleware or that Web Services architecture would replace JEE or .NET (something which some people once believed). Middleware today is an evolution of middleware from the 1960's and I'm sure it will continue to evolve as the areas to which we apply it change and evolve. I think it is also inevitable that Cloud will evolve, as we decide precisely what it is that we want it to do (as well as what 'it' is) based upon both positive and negative experiences of what's out there currently. (That's why we have the Web today, after all.)
Implementations such as Google App Engine are interesting toys at the moment, offering the ability to deploy relatively simple applications that may be based on cut-down APIs with which people are familiar in a non-Cloud environment. But I'm fairly sure that if you consider what consistutes middleware for the vast majority of applications, the offerings today are inadequate. Now maybe the aim is for people who require services such as security, transactions, etc. to reimplement them in such a way that they can be deployed on-demand to the types of Cloud infrastructures around today. If that is the case then it does seem to solve the problem (bare minimum capabilities available initially) but I take issue with that approach too: as an industry we simply cannot afford to revisit the (almost) NIH syndromes that have scarred the evolution of middleware and software engineering in general over the past 4 decades. For instance, when Java came on the scene there was a rush to reimplement security, messaging, transactions etc. in this new, cool language. The industry and its users spent many years revisiting concepts, capabilities, services etc. that existed elsewhere and often had done so reliably and efficiently for decades, just so we could add the "Java" badge to them. OK, some things really did need reimplementing and rethinking (recall what I said about evolution), but certainly not as much as was reworked. This is just one example though: if you look back at DCE, CORBA, COM/DCOM, .NET etc. you'll see it has happened before in a very Battlestar Galactica-like situation.
Therefore, if we have to reimplement all of the core capabilities that have been developed over the years (even just this century) then we are missing the point and it really will take us another decade to get to where we need to be. However, don't read into this that I believe that current middleware solutions are perfect today either for Cloud applications or non-Cloud applications. We've made mistakes. But we've also gotten more things right than wrong. Plus if you look at any enterprise middleware stack, whether from the 21st or 20th centuries, you'll see many core capabilities or services are common throughout. Cloud does not change that. In my book it's about building on what we've done so far, making it "Cloud aware" (whatever that turns out to mean), and leveraging existing infrastructural investments both in terms of hardware and software (and maybe even peopleware).
Of course there'll be new things that we'll need to add to the infrastructure for supporting Cloud applications, just as JEE doesn't match CORBA exactly, or CORBA doesn't match DCE etc. There may be new frameworks and languages involved too. But this new Cloud wave (hmmm, mixing metaphors there I think) needs to build on what we've learned and developed rather than being an excuse to reimplement or remake the software world in "our" own image. That would be far too costly in time and effort, and I have yet to be convinced that it would result in anything substantially better than the alternative approach. If I were to try to sum up what I'm saying here it would be: Evolution Rather Than Revolution!
But anyway, middleware has existed in one form or another for decades. There are obvious examples of "it" including DCE, CORBA, JEE and .NET, but then some other not so obvious ones such as the Web: yes, the WWW is a middleware system, including most of the usual suspects such as naming, addressing, security, message passing etc. And yes, over the past few years I've heard people suggest that the Web is also the death of middleware. For the same reasons that Cloud isn't its deathknell, neither was the Web: middleware is ubiquitous and all but the most basic applications need "it", where "it" can be a complete middleware infrastructure such as JEE or just some sub-components, such as security or transactions. Now this doesn't mean that what consitutes middleware for the Cloud is exactly what we've all been using over the past few years. That would be as crazy a suggestion as assuming CORBA was the ultimate evolution of middleware or that Web Services architecture would replace JEE or .NET (something which some people once believed). Middleware today is an evolution of middleware from the 1960's and I'm sure it will continue to evolve as the areas to which we apply it change and evolve. I think it is also inevitable that Cloud will evolve, as we decide precisely what it is that we want it to do (as well as what 'it' is) based upon both positive and negative experiences of what's out there currently. (That's why we have the Web today, after all.)
Implementations such as Google App Engine are interesting toys at the moment, offering the ability to deploy relatively simple applications that may be based on cut-down APIs with which people are familiar in a non-Cloud environment. But I'm fairly sure that if you consider what consistutes middleware for the vast majority of applications, the offerings today are inadequate. Now maybe the aim is for people who require services such as security, transactions, etc. to reimplement them in such a way that they can be deployed on-demand to the types of Cloud infrastructures around today. If that is the case then it does seem to solve the problem (bare minimum capabilities available initially) but I take issue with that approach too: as an industry we simply cannot afford to revisit the (almost) NIH syndromes that have scarred the evolution of middleware and software engineering in general over the past 4 decades. For instance, when Java came on the scene there was a rush to reimplement security, messaging, transactions etc. in this new, cool language. The industry and its users spent many years revisiting concepts, capabilities, services etc. that existed elsewhere and often had done so reliably and efficiently for decades, just so we could add the "Java" badge to them. OK, some things really did need reimplementing and rethinking (recall what I said about evolution), but certainly not as much as was reworked. This is just one example though: if you look back at DCE, CORBA, COM/DCOM, .NET etc. you'll see it has happened before in a very Battlestar Galactica-like situation.
Therefore, if we have to reimplement all of the core capabilities that have been developed over the years (even just this century) then we are missing the point and it really will take us another decade to get to where we need to be. However, don't read into this that I believe that current middleware solutions are perfect today either for Cloud applications or non-Cloud applications. We've made mistakes. But we've also gotten more things right than wrong. Plus if you look at any enterprise middleware stack, whether from the 21st or 20th centuries, you'll see many core capabilities or services are common throughout. Cloud does not change that. In my book it's about building on what we've done so far, making it "Cloud aware" (whatever that turns out to mean), and leveraging existing infrastructural investments both in terms of hardware and software (and maybe even peopleware).
Of course there'll be new things that we'll need to add to the infrastructure for supporting Cloud applications, just as JEE doesn't match CORBA exactly, or CORBA doesn't match DCE etc. There may be new frameworks and languages involved too. But this new Cloud wave (hmmm, mixing metaphors there I think) needs to build on what we've learned and developed rather than being an excuse to reimplement or remake the software world in "our" own image. That would be far too costly in time and effort, and I have yet to be convinced that it would result in anything substantially better than the alternative approach. If I were to try to sum up what I'm saying here it would be: Evolution Rather Than Revolution!
Monday, February 08, 2010
Code coverage
This may sound strange, but one of the things I really liked doing back when we were starting Arjuna, which was written in C++, was writing the code coverage tests using Pure Coverage (in fact we had all of the Purify suite back in those days.) I found it fun to do, trying to come up with tests that covered as much of the code as possible and there were times when I could get so immersed in writing tests, compiling, checking the coverage and cycling through again, that I'd forget my PhD work!
So it was with some excitement (yes, I know, it's sad!) that I discovered that the JBossTS team had configured in Emma to the builds. So guess what I did this past weekend? Yes, before I knew it the weekend was over and I'd added a few more tests to the build. Sweet!
So it was with some excitement (yes, I know, it's sad!) that I discovered that the JBossTS team had configured in Emma to the builds. So guess what I did this past weekend? Yes, before I knew it the weekend was over and I'd added a few more tests to the build. Sweet!
Wednesday, February 03, 2010
Subscribe to:
Posts (Atom)