Appliances for IT infrastructure have evolved to include everything from email servers to network routers to XML accelerators. Some would argue that "appliances" can be hardware, software, or both. Purists have a more strict definition that they say will make the locked-down and all-inclusive devices of great appeal to growing legions of IT operators and SOA architects.
For the latest BriefingsDirect SOA Insights Edition podcast, our panel of IT analysts and experts are joined by someone who knows appliances inside and out, Jim Ricotta, vice president and general manager of appliances within IBM’s software group. Jim offers some hints that IBM is betting big on appliances across more aspects of IT solutions.
Our expert panel digs into this and other recent trends in SOA and enterprise IT architecture in the latest BriefingsDirect SOA Insights Edition, volume 21. Our group also examines the emerging BPEL4People specification for making humans and SOA better, if only loosely, coupled. The discussion ends with a look at the GPL v3 and the importance, or not, of the Apple iPhone.
So join noted IT industry analysts and experts Tony Baer, Jim Kobielus, Brad Shimmin, and Todd Biske for our latest SOA podcast discussion, hosted and moderated by yours truly.
Here are some excerpts:
... On IT infrastructure appliances and SOARead the full transcript for more IT analysis and SOA insights. Listen to the podcast. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.
The basic concept of an appliance is to allow customers to get their projects going more quickly, experience lower total cost of ownership (TCO), etc. ... We have a broader remit and we are looking at a number of different appliance efforts for different parts of the IBM product set.
The idea with an appliance is that the clients don’t care what’s inside. They care about the functions that the device does. The way we have architected our product, we do have lots of choices. We can pick the right processors.
[But] it’s really much more ... than performance. ... it’s about TCO and then "time to solution" and "time to deployment."
I’ve heard big global IT organizations, when they do their TCO calculation, say a router is $100 a month to support, a server is $500, and a DataPower SOA appliance is maybe $200 to $250. Those are the kind of ranges I hear.
So, we are talking a potential 50 percent reduction in total cost? Yes.
Our customers say, “Geez. We could do what your box does with software running on a server, but the operations folks tell us it would be two times or four times more expensive to maintain, because we have to patch all the different things that are on there. It’s not the same everywhere in the world in our infrastructure. Whereas with your box, we configure it; we load a firmware image, and it’s always the same wherever it exists.”
So, our view is an appliance is three things that the customer buys at the same time: They buy hardware, software, and support, and it’s all together. That’s really what we think is the core value proposition.
A manager I worked for had the term "Dial-tone Infrastructure." You want to plug it in, pick it up, and it works. That’s the model that everybody is trying to get to with their solutions. But, when you're dealing with an appliance, you have to have that level of integration between the hardware and the software, so that you're getting the absolute best you can out of the underlying physical infrastructure that you have it on.
Any software-based approach that’s on a commodity hardware is not going to be optimized to the extent that it can be. You look at where you can leverage hardware appropriately and tune this thing to get every last ounce of performance out of it that you can.
[SOA and appliances] dovetail because the very concept of an appliance is something that’s loosely coupled. It’s a basic, discrete component of functionality that is loosely coupled from other components. You can swap it out independently from other components in your architecture, and independently scale it up or scale it out, as your traffic volume grows, and as your needs grow. So, once again, an appliance is a tangible service.
SOA has its own version of an ISO stack with the WS-Standards and the layers from things like BPEL, all the way down to XML and the basics. That’s what enabled this approach of putting together a device that supports a bunch of these standards and can fit right into anybody’s SOA architecture, no matter what they are doing with SOA.
We see ESB as a key part of any SOA architecture and deployment. If you do it properly ... you tend to get a performance solution. You’ve done optimization. You’ve done a pruning back of all the potential functions. ... You tend to have good performance from, as well as the other benefits I pointed to, easy deployment and low TCO. So, given that ESB is the core of SOA, in many ways having an appliance alternative is important.
A lot of this space in the middle in SOA is all about what I would call a "configure-not-code" approach. Appliances, by definition, are something you configure, not something that you are going to be developing code for. So, it’s really tuned for an operational model, and not for a developer having to go in and tinker around with it.
And that’s really where a lot of the savings can come in the total cost of ownership. It isn’t how much work you have to go through it to actually make a change to the policies that are being enforced by this software appliance or device, and there are big differences between the products out there.
An appliance can act as an enabler for other pieces of software in terms of providing that level of performance and scalability that those pieces can't do on their own. Such as we are seeing with ESBs and other areas. Those pieces of software need desperately some piece of hardware somewhere that can get them the information need in any timely manner.
We [at IBM] have some discussions underway with network providers that have big corporate clients who are now launching their first B2B Web services, and they are basically utilizing SOA-type functions between organizations across Wide Area Networks. These carriers are looking at how to provide a value-added service, a value-added network to this growing volume of XML, SOA-type traffic. We see that as a trend in the next couple of years.
On BPEL4People for SOA ...
The BPEL4People specification came to fruition this week. ... It’s interesting that they made both spec proposals separate. But, it’s not any type of surprise. IBM and SAP have been talking about this for about 18 months to two years, if I recall. What was a little interesting was that Oracle originally dissented from this, and now Oracle is part of that team.
The SOA folks have looked at BPEL and find something interesting. It does well with machine-to-machine, or at least with designed-for-automated processes to trigger other automated processes based on various conditions and scenarios, and do it dynamically. But, the one piece that was missing was most processes are not 100 percent automated. There’s going to be some human input somewhere. It was pointed out that this is a major shortcoming of the BPEL spec.
So, IBM, SAP, Oracle, BEA, Adobe and Active Endpoints have put together a proposal to patch this gap, and they’re going to submit it to OASIS ... BPEL4People. We’re going to add a stopping point to say, "Put a human task here." That’s essentially BPEL4People. It’s a little more than that, but essentially boils down to that.
Where I tend to see the value in this is that invoking a human task as a service is not necessarily a call for relationship with orchestration. You don’t necessarily have to orchestrate in order to invoke a human task.
I think that we definitely need this. There's a constant tension with trying to take a business-process approach within IT when developing solutions. If you look at the products that are out there, you have one class of products that are typically called "workflow products" that deal with the human task management, and then you have these BPM products or ESBs with orchestration in them that deal with the automated processes. Neither one, on their own, gives you the full view of the business process.
As a result, there’s always this awkward hand-off that has to occur between what the business user is defining as the business process and what IT has to turn around and actually cobble together as a solution around that. Finally getting to a point where we’re saying, "Okay, let’s come up with something that actually describes the true business process in the business definition of it," is really important.
No comments:
Post a Comment