To ESB or not to ESB?

Discussions

News: To ESB or not to ESB?

  1. To ESB or not to ESB? (12 messages)

    When is it a good fit to use an ESB? This blog post by Ross Mason outlines guidelines for when an ESB may or may not be appropriate.

    Threaded Messages (12)

  2. Some further thoughts[ Go to top ]

    I blogged about this too: Paul Fremantle on To ESB or not to ESB
  3. Ok, but this applies to everything: To EJB or not to EJB? To SOAP or not to SOAP? To JSF or not to JSF... You know, only a few of us, developing RPC's for all flavors of UNIX in the past, welcomed J2EE, especially EJB1.1 greatly! Of course, the "EJB on my resume" was the real problem regarding all the noise with J2EE! As for ESB, appreciated the list from Ross, but this is just a short list. Every situation and requirements are unique. For example, ESBs are good for encapsulating legacy applications, even if you have only one! Sure, plenty more situations could be mentioned, my point, why is it that someone else knows more about your problem? Cheers
  4. Re: To ESB or not to ESB?[ Go to top ]

    Ok, but this applies to everything:

    To EJB or not to EJB?

    To SOAP or not to SOAP?

    To JSF or not to JSF...
    Well, not really. The challenge with ESBs and other technologies like BPM is that they are versatile platforms that give you some real power to create very flexible architectures. The problem is that flexibility comes at a price. You need to be able to identify where you need that flexibility.
    You know, only a few of us, developing RPC's for all flavors of UNIX in the past, welcomed J2EE, especially EJB1.1 greatly! Of course, the "EJB on my resume" was the real problem regarding all the noise with J2EE!

    As for ESB, appreciated the list from Ross, but this is just a short list. Every situation and requirements are unique.
    Absolutely, but what happens is people start making technology decisions by checking boxes rather than considering the value that the technology is going to add to their environment (and what trade-offs there may be in using it)
    For example, ESBs are good for encapsulating legacy applications, even if you have only one!
    Not quite. An ESB can do this but WebServices or CICS adapters are good for integrating legacy applications too. Do you really need an ESB product to integrate or just a WS or CICS client? An ESB would be good if you then need to serve the data from the legacy application to other applications in your organisation. The point is an ESB can do a lot of things, but using it for just one function is not a great way to leverage the product and is likely to introduce complexity into what otherwise may just be a client server architecture. Cheers, Ross Mason MuleSource Inc
  5. Wrong perspective[ Go to top ]

    One problem with this blog is that it makes the ESB a project level decision. An ESB is a strategic investment of the enterprise. It's not a decision you should make on the basis of one project or application. It's not worth it. If you are not going SOA in a big way, then instead of an ESB you might just need an EAI hub or hub and spoke messaging. The payoffs for an ESB are primarily in the areas of 1) simplifying integration and service reuse and 2) removing a number of cross-cutting concerns from the services implementing them in a shared infrastructure independent of the technologies used to implement your services. Studies I've read say ESB's are worth it when you have 50 services or so. (End points, not operations and not finer-grained components masquerading as services.) Another problem is that he is confusing a product (Mule) marketed as an "ESB" with an ESB. An ESB - enterprise service bus - is an architectural concept/construct - a managed set of service level integration pathways. It is not a product. There is no single "ESB" product that is a full ESB implementation. There are "ESB" products that are very good fits for the core of an ESB you might construct. As time goes on we'll find that our ESBs will include appliances (network and application), messaging middleware, JVMs or CLRs, components, governance software, load balancers, etc. It won't be all software and it won't be one product.
  6. Re: Wrong perspective[ Go to top ]

    One problem with this blog is that it makes the ESB a project level decision. An ESB is a strategic investment of the enterprise. It's not a decision you should make on the basis of one project or application.
    THis is a very traditional way of thinking and much of the disillusionment around SOA has been caused by organizations defining strategic big-bang projects that struggle to take flight due to the sheer number of stakeholders, applications, and complexity and eventually goes the way of the Dodo. I can only really speak for our customers but I have seen a magnitude more successful projects where the project started small and grew over time. By taking an incremental approach you achieve a few important goals - 1) You reduce disruption in the organisation while you figure out how your architecture is really going to play out (hint it is very rare that the architecture is correct first time round) 2) You reduce the complexity of the problem but only addressing a small portion of it. This will mean that you'll have to evolve your architecture over time, but it's much better to evolve a small piece rather than the whole thing. 3) You reduce timescales to delivery and are sooner in a position to demonstrate value to the organisation. This is key to any SOA success. If you can demonstrate value to the people affected by the change they re much less likely to resist it.
    If you are not going SOA in a big way, then instead of an ESB you might just need an EAI hub or hub and spoke messaging.
    Agreed, and Mule is very good at this. Deploying Mule as an ESB is one option, but it can also be deployed as a hub. The point of Mule is to provide a flexible light-weight integration platform. This means its suited for a variety of scenarios but not everything. The point of my post is that architects should understand the tools they select so that they pick the right technology for the Job.
    The payoffs for an ESB are primarily in the areas of 1) simplifying integration and service reuse and 2) removing a number of cross-cutting concerns from the services implementing them in a shared infrastructure independent of the technologies used to implement your services.
    Agreed
    Studies I've read say ESB's are worth it when you have 50 services or so. (End points, not operations and not finer-grained components masquerading as services.)
    I don't think it has much to do with the number of endpoints, its more about the diversity of the environment, such as the protocols, data formats, routing requirements, etc. If I have 50 HTTP web services do I need an ESB, probably not (I may want a service registry though).
    Another problem is that he is confusing a product (Mule) marketed as an "ESB" with an ESB. An ESB - enterprise service bus - is an architectural concept/construct - a managed set of service level integration pathways. It is not a product. There is no single "ESB" product that is a full ESB implementation.
    This is really a product of the Analysts and vendor marketing. We certainly did not create the ESB market space but we solve the problems that products in that space solve. Hence people are looking for an "ESB" and will only find Mule if it is called an ESB. I'm not particularly excited about that since Mule's architecture is more around the concept of building Enterprise Service Networks (ESN) where a bus concept is not required but you still need to host and manage services and move and transform data between those services. Using Mule as an ESB is just one topology, but it is a popular one. Cheers, Ross Mason MuleSource Inc
  7. Re: Wrong perspective[ Go to top ]

    One problem with this blog is that it makes the ESB a project level decision. An ESB is a strategic investment of the enterprise. It's not a decision you should make on the basis of one project or application.

    THis is a very traditional way of thinking and much of the disillusionment around SOA has been caused by organizations defining strategic big-bang projects that struggle to take flight due to the sheer number of stakeholders, applications, and complexity and eventually goes the way of the Dodo. I can only really speak for our customers but I have seen a magnitude more successful projects where the project started small and grew over time. By taking an incremental approach you achieve a few important goals -
    1) You reduce disruption in the organisation while you figure out how your architecture is really going to play out (hint it is very rare that the architecture is correct first time round)
    2) You reduce the complexity of the problem but only addressing a small portion of it. This will mean that you'll have to evolve your architecture over time, but it's much better to evolve a small piece rather than the whole thing.
    3) You reduce timescales to delivery and are sooner in a position to demonstrate value to the organisation. This is key to any SOA success. If you can demonstrate value to the people affected by the change they re much less likely to resist it.
    Your response addresses how one might best enable a strategic capability and I agree with you. However, I was responding the the text in the blog about how to determine whether or not you should implement an ESB. When calculating the ROI of an ESB and determining what you might want to include in it, you need to consider something much broader than a single project. If your project has only one or two services you might still want to implement an ESB - or at least the foundation for one, not because this one project needs it but because you are looking at the bigger picture and because you want to take the very (incremental) approach that you are advocating.
  8. Re: Wrong Perspective[ Go to top ]

    One problem with this blog is that it makes the ESB a project level decision. An ESB is a strategic investment of the enterprise. It's not a decision you should make on the basis of one project or application. It's not worth it. If you are not going SOA in a big way, then instead of an ESB you might just need an EAI hub or hub and spoke messaging.
    I didn't get that from either of these posts. I think their point was that using an ESB has a very real cost, and so shouldn't be used as a golden hammer. They're advocating basic cost/benefit analysis to decide where to use an ESB, and sharing a useful observation that projects and even SOA initiatives fail when this isn't done. Sounds like a warning _not_ to go SOA in a big way out of the starting gate. And assessing whether an ESB makes sense for a given project doesn't in any way imply that it's a decision that is made by a project team. It can and probably should be made a level or two higher up, with an enterprise perspective in mind.
  9. Re: Wrong perspective[ Go to top ]

    One problem with this blog is that it makes the ESB a project level decision. An ESB is a strategic investment of the enterprise. It's not a decision you should make on the basis of one project or application.
    I kind of agree with Ross that thinking about ESB (or other similar-scale technology) in terms of strategic investment is rather limiting and narrow. Exactly that thinking is what was hampering grid computing adoption for the last decade, for example. In my opinion, technologies like ESB (and products like Mule, ServiceMix, etc.) have equal or even much greater applicability on smaller scale like in per-project or per-application. Best, Nikita Ivanov. GridGain - Cloud Development Platform
  10. Re: Wrong perspective[ Go to top ]

    What's interesting about our different perspectives is that you and Ross are pushing products and I'm an enterprise architect who has to justify to management why such products are needed. I think you perspectives are narrow and that leads you to fail to communicate the full value propositions of the technologies you are trying to sell. I, and probably most experienced people agree that you don't want to roll this stuff out enterprise wide all at once. Even one or two pilot projects are not sufficient for technologies that are as significant as data grids and ESBs. However, unless an organization is stupidly continuing to plan enormous projects that seem to never end, you will rarely find a single project that makes a compelling case for what you are trying to sell.
  11. Re: Wrong perspective[ Go to top ]

    What's interesting about our different perspectives is that you and Ross are pushing products and I'm an enterprise architect who has to justify to management why such products are needed.
    Actually, we are pushing for people to be smarter about their technology decisions. I don't want to 'push' (open source is more like pull than push) product, I want to enable users to make more informed technology decisions since it leads to better satisfaction all round. It's your job as the architect to have a compelling architecture that you can sell to management. If management buy into your architecture it becomes much easier to recommend the products to help you reach the end goal. You should be selling an architecture not a product to management.
    I think you perspectives are narrow and that leads you to fail to communicate the full value propositions of the technologies you are trying to sell.
    Do you realise how ridiculous that statement sounds? Maybe you should elaborate to get your point across.
    I, and probably most experienced people agree that you don't want to roll this stuff out enterprise wide all at once. Even one or two pilot projects are not sufficient for technologies that are as significant as data grids and ESBs. However, unless an organization is stupidly continuing to plan enormous projects that seem to never end, you will rarely find a single project that makes a compelling case for what you are trying to sell.
    So are you saying you think there is never a compelling reason to use products like ESBs and Grids? Cheers, Ross Mason MuleSource
  12. Re: Wrong perspective[ Go to top ]

    It's your job as the architect to have a compelling architecture that you can sell to management. If management buy into your architecture it becomes much easier to recommend the products to help you reach the end goal. You should be selling an architecture not a product to management.
    Duh! Tell me something I don’t know. Two points - 1) My architecture is not based on the needs of one project - it takes a holistic enterprise perspective. 2) We don’t let projects make product decisions. You cannot manage an enterprise architecture that way. My company spends almost a billion dollars a year on IT. Reducing redundancy in the technologies we use can save us tens of millions of dollars in training, licensing, development and other costs. Among other things, I’m responsible for the ESB architecture and leading the selection of the technologies that go we use to build it. We look at our target application architecture for the enterprise and the needs of multiple major projects in order to get a firm grasp of what our SOA infrastructure needs are. Now don’t try to twist this again by claiming that I’m advocating a big bang implementation. I’m not. I’m a firm believer that big successful things started out as small successful things; however you need to know where you will be taking it - a target architecture. As Lewis Carroll wrote, “if you don’t know where you are going, any road will take you there.” You don’t want to have to back out of bad architecture, product or design decisions later. You don’t want to paint yourself into a corner.
    So are you saying you think there is never a compelling reason to use products like ESBs and Grids?
    Apparently you didn’t read or didn’t understand a thing I wrote in my first post. Of course there are compelling reasons to use ESBs and Grids, but rarely will you find one project that by itself gets you to the tipping point. This is especially true once you’ve moved away from implementing monolithic tightly coupled vertically integrated applications to implementing discrete services. In SOA projects can and should be smaller in size and scope, faster to implement and entail less risk. It’s the ability to reuse - designs, patterns, technologies, frameworks and components that gets you to the tipping point and beyond. If you do a good job, you will get a lot of reuse across projects, not just within a project. The latter is relatively easy. The former is what enterprise architecture tries to achieve. You do understand that the “E” in ESB stands for “enterprise”, do you not? It doesn’t stand for “Project” or “eProject”. The “E” is there for a reason, otherwise it would be called just a “service bus”. So, my problem with your blog centers on the notion you seem to have that projects can and should be making ESB decisions. In the real world where ESBs are really needed, that is not true and it’s a poor approach for the companies that have to pay for it. If you were just explaining to folks the benefits an ESB or Mule can provide in a project setting then I’d have had no disagreement. As for data grids. If you have a large enterprise you may not be the only user of a database your application reads and writes to. In many cases the databases you read the most from are not your own. They may be operational data stores that are fed through ETL or a data movement bus. They may be someone else’s transactional store. If a project tries to add a data grid or data/object caching solution just for itself, it may find other applications not using that solution will making changes to the underlying database that keep your cache out of synch with its source. If you look at the database itself (a more enterprise perspective) instead of just one project, you’ll get more value from your grid or cache.
  13. 2 cents...[ Go to top ]

    My observation are that SOA and ESB are a waste of time for corporations, regardless of the enterprise. Why? Because very few have the architectural or technical know how to implement and maintain them. The end results as I've seen is are smattering of services which are hard to find, discover, and/or use. You can say with the right tools and expertise, it advantageous, but I've heard the same arguments for EJB 1 and 2. When the dust settled, Hibernate ruled. Same here for SOA and ESB. At the end of the day, SOAP with some wiki doc works. Clean and simple, and hits 90% of enterprise needs. I've seen it work well. ESB... I've seen it flop at least in 3 enterprise environments.