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.