It would be heresy among marketers at many
vendors, but the MuleSource CTO is actively discouraging architects and developers from using an enterprise service bus (ESB), including his company’s open-source version, unless they are sure they really need one.Misuse of ESBs leads to overly complex architectures that can be more difficult to remedy than a straightforward Web services-based architecture that omits the ESB in early versions of an enterprise application, Mason argued in a phone conversation about his blog.
“There are two main mistakes I see most of the time,” he told BriefingsDirect. “There’s not enough of an integration requirement or there’s not enough use of the ESB features to warrant it.”
You don’t need an ESB if your project involves two applications, or if you are only using one type of protocol, he explains.
“If I’m only using HTTP or Web services, I’m not going to get a lot of value from an ESB
as opposed to using a simpler Web services framework,” Mason said. “Web services frameworks are very good at handling HTTP and SOAP. By putting in an ESB, you’re adding an extra layer of complexity that’s not required for that job.”Architects and developers using an ESB in these cases are probably engaging in "resume-driven development (RDD)." If anybody asks you if you’ve deployed an ESB in an application you’ve worked on you can say, yes. And then you can hope the hiring manager doesn’t ask if the application really required the technology.
Another mistake, Mason cites, is using an ESB and thinking that you are future-proofing an application that doesn’t need it now, but might someday.
“You’ll Never Need It (YNNI), that acronym has been around awhile for a reason,” Mason says. “That’s another killer problem. If you select an ESB because you think you might need it, you definitely don’t have an architecture that lays out how you’re going to use an ESB because you haven’t given it that much thought. That’s a red flag. You could be bringing in technology just for the sake of it.”
Adding his two-cents to the “Is service-oriented architecture (SOA) dead” debate, the MuleSource CTO says such over-architecting is one of the things that contributes to the problems being encountered by IT in SOA that has given the acronym a bad name. “Architecture is hard enough without adding unnecessary complexity,” he said. “You need to keep it as simple as possible.”
Ironically, adding an ESB because you might need it someday can lead to future problems that might be avoided if you left it out to begin with and then added it in later, Mason said.
“The price of architecting today and re-architecting later is going to be a lot less than architecting badly the first time,” he explained. “If you have a stable architecture, you can augment it later with an ESB, which is going to be easier than trying to plug in an ESB where it’s not going to be needed at that time.”
While the conversation focused on the pitfalls of using an ESB where you don’t need one, the MuleSource CTO naturally believes there are architectures where the ESB makes sense. To begin with, you need to be working on a project where you have three or more applications that need to talk to each other, he explained.
“If you’ve got three applications that have to talk to each other, you’ve actually got six integration points, one for each service, and then it goes up exponentially,” Mason said.
The ESB technology is also needed where the protocols go beyond HTTP. “You should consider an ESB when you start using Java Message Service (JMS), representational state transfer (REST), or any of the other protocols out there,” Mason said. “When communications start getting more complicated is when an ESB shows its true value.”
BriefingsDirect contributor Rich Seeley provided research and editorial assistance on this post. He can be reached at RichSeeley@aol.com.
No comments:
Post a Comment