Last week we hosted a very popular webcast with Dr. Stefan Ried, Forrester’s Principal Analyst and Vice President serving CIOs. Stefan provided a detailed overview of Forrester’s research on cloud-based integration, the trends in the market and he outlined why hybrid is the IT reality today and for the foreseeable future. The webcast also featured a high-level overview of the
SnapLogic Integration Cloud and an interactive Q&A on a wide variety of topics. The Q&A got into why the legacy enterprise service bus (ESB) is not well suited for cloud integration scenarios, the benefits of multi-tenancy and the challenges legacy integration technologies face when dealing with the modern integration requirements.
Before the discussion, Stefan summarized SnapLogic’s position in the market by saying:
“As you have seen, SnapLogic can really be both integration in the cloud and integration with the cloud. If you want the Snaplex on-premise you have on-premise data governance and you can point to the SaaS applications you want to connect to. But if you have the majority of apps in the cloud, you want the Snaplex in the cloud. Such architecture is very flexible to keep both options open.”
Here is the transcript of the Q&A:
Question: You mentioned ESBs typically aren’t multi-tenant and aren’t well suited for the cloud. Are there specific reasons why an ESB is not the right choice for cloud integration?
Answer: Couple of reasons.
- The scalability of an ESB. ESBs can become very big, as you might have seen in your own infrastructure if you run a large ESB, but ESBs struggle to become very small. It sounds funny, but it’s not. For example, if you use your cloud-based integration scenario to do B2B integration. So you can easily not only integrate your Salesforce.com system to your ERP system, you can also integrate all your channel partners of your Salesforce.com tenant into your ERP system. You can make a very elegant channel integration like this. If you would spin up for each of those guys an ESB and it’s used for only a couple of messages per day, you’d waste a lot infrastructure (and license by the way). These are examples that hit the limits of traditional ESB architectures.
- The paradigm of developing complex integration scenarios. These are helpful if you have very complex requirements, but if you want to synchronize your NetSuite customer data with your SAP customer data, or whatever ERP you have on-prem, this is tool overkill. I’ve seen customers that are trying to use a traditional ESB for those cloud scenarios end up with much higher costs hence skills that they need to buy even externally and really enjoy cloud based integration as an alternative.
Question: Why can’t I simply do this with my existing middleware and what’s my recommendation for using my existing middleware with some of these new scenarios?
Answer: First of all, I’d like to motivate and encourage everybody to try out the new solutions. Not only because this is a conversation sponsored by SnapLogic, but really because both the traditional application integration as well as the traditional data integration are simply too heavyweight in many cases for the requirements of synchronizing data with the cloud. That means I’d like to encourage you to try it out, to find out which use cases of your enterprise fit into that and then make the balance between using your old middleware and extending to those use cases or learning something new and licensing something new. Many mid and large enterprises end up using both. So cloud based integration is not a replacement, it complements it. It provides those cases where the traditional ESB or traditional data integration tools are simply overkill.
Question: Can you expand on your concept of metadata collaboration and why cloud integration platforms are better suited for that versus on-prem?
Answer: If you run the metadata in the cloud, obviously you can simply use cloud collaboration. So for example, you can put up a market place. Or you can put up crowdsourcing scenarios where you can simply share the metadata whether it’s a professional integrator or vendor created or the metadata that one of your peers created, maybe somebody in a totally different company with the same type of configuration or the same two endpoints. That means you can imagine dealing with metadata more like dealing with a Google spreadsheet, for example. You can easily share with other people in real time. The old way of dealing with metadata in traditional middleware was more the kind of traditional Microsoft Office, where you send around an Excel spreadsheet. When it arrives it’s outdated already.
That’s the difference in the cloud. It’s more collaborative. It’s more shared. You can imagine a marketplace and crowdsourcing, the sharing of metadata in a totally different way. And that ultimately cuts down implementation costs and makes skills much cheaper because people enjoy the simplicity and simply take the examples from other people instead of reading large manuals or buying a consultant.
Question: Does mulitenancy still matter? What are the reasons it’s important in a cloud integration platform?
Answer: Multitenancy definitely brings a significant cost cut. Technically you can achieve many of the things we’ve discussed today by spinning up a dedicated virtual machine on Amazon or elsewhere and you can technical achieve the same. But obviously if you’ve spun up a virtual machine in your own environment, you cannot do the things we just discussed on metadata sharing. But if you have one shared environment, the environment can define that we share metadata or that we pluck metadata into an Appstore – we collaborate on metadata, but we keep the data itself secret and private. That is the actual form that Forrester has started to call, “Collaborative Tenancy.” That means being private on those parts that need to be private, like your data flows, but being very collaborative on those parts that can be collaborative, like the metadata. These concepts obviously are significantly different than what you could achieve in a single tenant environment.
Finally, I mentioned the example already that you have much more scalability. In a multitenant environment, if a tenant is not needed it falls asleep. It doesn’t require any infrastructure anymore. That ends up both infrastructure and potentially also license pricing that are transaction based. In the old world, look at your ESBs, they’re all CPU-based pricing. If they’re lying around unused, they’re still expensive. This is all significantly different.
Question: We had debate recently about the heritage of an integration vendor. How do traditional vendors change? Can they change? What’s important under the hood?
Answer: You cannot change the basic architecture software. You cannot. If it’s based on a traditional Java environment and built with a traditional object model, you cannot turn it into a JSON representation. It’s simply not that easy. However, people try to map it. At the end you can obviously serve apps that are written in both paradigms in both ways, but you will not get the performance. That means if you have heavy traffic, the new environments in the cloud, so for example if you are a customer-facing application, an old GS for example or an app to deal with your customers that is also connected to Facebook and has unpredictable traffic volumes, I think the new middleware architectures like the one from SnapLogic definitely have some advantages. At the end, it gets down to cost. It gets down to the volume of physical infrastructure that you need to serve the traffic and if you’?re with a modern architecture you’re definitely built to deal with the traffic.
Check our events page for upcoming web and live programs. You may also find this post interesting – why SOA was DOA thanks to the ESB.
