Over the last few weeks we’ve been busy make improvements to the WEAVE@cloud service backend. Most of the improvements have been targeted at making the service more reliable and scalable.
You may be aware that WEAVE@cloud has a clear separation between “Designing” and “Running” of integrations.
This clear separation has allowed us to provide WEAVE@cloud customers with multiple runtime options, giving a choice when it comes to “where” integrations run and the types of services and apps integrations can connect to. You can:
- Run integrations in a fully hosted container in the cloud (like other Cloud Integration services).
- Run integrations in self-managed containers (on-premise), allowing you to sync data into and out of an application/database that’s inside your firewall.
One of the improvements we made in the last few weeks was to create better support for option #1 above i.e. a more robust, secure and scalable cloud hosted container for running WEAVE@cloud integration apps. For this, we created a new dedicated/isolated multi-tenant integration application container built on top of the CloudBees tried and trusted RUN@cloud Platform as a Service (PaaS).
This new “CloudBees (RUN@cloud multi-tenant)” container is a replacement for the old “CloudBees (shared)” container. It provides the following benefits:
- More Secure: Each WEAVE@cloud customer gets their own dedicated container for running only their integration apps (running on their RUN@cloud account). This means that, unlike other Cloud Integration services, their data never flows through shared infrastructure “alongside” data owned by other WEAVE@cloud customers. A container instance can run multiple integrations (is multi-tenant), but only runs integrations for a single customer account.
- More Reliable: Integration reliability is now “scoped” at the account level Vs being scoped more globally at the service level. Your integrations are not subject to side-effect-failures caused by integrations owned by other WEAVE@cloud customers. While this has never been a problem in practice, it was a theoretical threat that we wanted to avoid before it ever did happen.
- More Scalable: Closely related to reliability, but worth noting separately; the new container inherits its scalability from the fact that it’s built on top of the RUN@cloud service (WEAVE@cloud’s big brother). As with reliability, scalability concerns are now scoped at the account level Vs a more global service level, which is obviously much more manageable.
We made a number of other improvements too e.g. “Message Replay”, which is the ability to modify/fix and replay messages that were filtered or failed. If you haven’t already, please give the service a try and let us know what you think.