Service-Based PaaS Architecture

Our AnyCloud announcement pulls together some important variables in the PaaS equation that enterprises are trying to solve. First, it's clear that you don't need to sacrifice the benefits of a fully serviced PaaS to get low-latency, secure access to your local resources and investments. Sacha covered this in detail, and how AnyCloud means you don't have to choose between public and private PaaS. Second, it further opens up the PaaS marketplace to European developers, who have privacy and regulatory concerns that are much different than their US-based counterparts. François covered these issues. Finally, AnyCloud also brings a unified means to access and interact with deployments regardless of whether you're deploying to a specific region, to a specific hosting provider, or to your local data center. CloudBees can offer this kind of flexibility and unified experience because of our service-based architecture, and I want to cover that in a bit more depth in this post.

When you look at AnyCloud under the covers, you can see that we're following a proven SOA-style, scalable architectural approach. Here, for example, is the way AnyCloud looks in a hybrid, or "tethered" style deployment to your data center or a hosting provider's data center:

Our underlying shared services that we use for Identify/Account Management, Provisioning, and so on, are independent, and all interaction goes through an AMQP-based message bus. Agents are co-located with the services they touch. This approach gives us scale, resilience across lossy networks if needed, and lets us secure interactions properly. It also gives us the flexibility to host services on "any cloud".

The CloudBees PaaS goes a level deeper, though, when we talk about it being service-based, and it's a key distinction compared to a more application-centric approach, such as Heroku, would take. In an app-centric approach, everything starts with creating the application. All resources and management commands are attached to the application itself. This has the advantage of simplicity, and there is little chance of one application affecting another. In an app-centric world, the database can be instantly provisioned for the application and bound to a well-known location. But, if you want to share a database or other resources between applications, it may become difficult. You likely have to invest in an application architecture that makes sharing possible within each app (via REST interfaces, etc), and it becomes difficult for an application to deal with more than one type of the same resource. Furthermore, service partners are not app-centric themselves. Partner accounts must be provisioned for each application that wants to use a service, because each application has its own namespace of resources that it owns and manages.

In a service-centric architecture like CloudBees, no single service is the "primary" service. Instead each service is attached to a CloudBees account, and is able to expose account-level functionality (like its admin UI) and can provision resources that are part of the account that can be referenced by other services or resources in the CloudBees PaaS. Since each service manages its own set of resources, CloudBees exposes binding facilities that allow resources on one service to be bound to resources of another service. So, on CloudBees:

• If you are subscribed to use our Jenkins, Forge, Application, or Database services independently, you can use them together to piece together workflows that make sense for your team. When your application intersects with lots of moving parts internally and externally, and you're pushing toward a more agile continuous delivery approach, you need this flexibility.
• If you want to create an application that uses a database, you create the application and the database separately, and then bind them together to make the database available as a resource inside your application. If you later want to create another database for test, and want to to switch the application to use the test database, you just rebind. In an app-centric architecture, where the application can only connect to the database that was created for it, you would have to tear down the database data and build it all back up, versus just swapping which database your application is using.

These are just two examples where CloudBees' service-based PaaS architecture make hard things simple. They're also classic real-world, important cases in the enterprise. And they're part of the reason that you can expect CloudBees to be a big part of accelerating PaaS adoption in the enterprise this year.

For more information about AnyCloud, download our AnyCloud white paper.

Steven Harris, Senior Vice President of Products

CloudBees
www.cloudbees.com
 

Follow CloudBees: