Apprenda’s Capabilities; We’ll Work the Gears- You Steer the Car: Multitenancy Options
This is another part of my blog series, Capabilities of the Platform, which describes what the Apprenda platform is capable of doing within an enterprise, honing in on specifics within its abilities as well as addressing how our platform goes far beyond what other PaaSes are able to do. My last blog was about going beyond deploy & scale. In this post I’ll drill into a unique capability – Apprenda’s ability to instrument multi-tenancy into otherwise standard web & SOA apps. That’s right – instrument: as in dynamically!
Building multi-tenant apps is hard work (just ask Salesforce), and its popularity as a cloud architecture pattern has gone up as the preferred architecture for cloud B2B apps. Rather than architecting an app to be multi-tenant, Apprenda allows developers to write Plain Old Web Apps (POWAs) as 3-tier architectures, deploy them to the platform and also provides the developer with configuration options on multi-tenancy needs. First, these options influence deploy time transformations that crawl through your application binaries and DB schemas and modify them to weave multi-tenancy into them as an orthogonal concern. Second, the options influence runtime execution of the app.
This is all possible because Apprenda is architecturally organized as an application server that participates in the execution of your app, just like other app servers have done in history. Other PaaS’ act more like management tools that sit outside of your application to control discrete events, which is why they can’t do this stuff we do at Apprenda. Let’s explore more deeply.
Let’s take a look at a traditional web app, composed of three different tiers:
- Presentation Layer: for presenting the user interface
- Services Layer: to handle the business logic
- Persistence layer: which handles the DB and storage
Each of these layers can employ different levels and styles of tenant isolation models (which determine the type of multi-tenancy). Apprenda, when it accepts an app for hosting, allows you to configure what level of multitenancy you want applied to the different layers of your application. These vary, depending on the needs of the customer, and sit on a spectrum from Isolated (physically isolated with low density) or a Commingled (logically isolated and tenant dense). When you’re deploying an app, the click of a button can set your configuration to state whether the DB should be isolated or commingled.
Multitenant Options?! You mean there’s more than one?
Regarding an Isolated DB– this means that the platform will deploy a separate DB for each customer. Ultimately, this implies a much reduced level of density when compared with a multi-tenant commingled DB (multiple customers in a single DB). In order to achieve a commingled outcome, Apprenda transforms the DB schema in such a way that it will store the data of multiple customers within the same single DB and create a transformation layer that, when the app requests a specific customer’s data, will filter it out automatically based upon the customer making the request. This is done so that the app doesn’t have to worry about who the data is supposed to be for, and will automatically transform your app to be single-instance multitenant without your app having to worry about it. This is at the DB layer. The other layers also have a selection of multitenant options.
On the Presentation Layer (the UI’s), you can choose whether you want to deploy it as an isolated UI, or a commingled UI. In the commingled UI, all of your customers are accessing the same physical UI instance. When you deploy the UI to a website in IIS or Tomcat, when Customer A or Customer B requests the app they’re both encountering the same instance of the presentation layer. If you go to scale that, you can partition load for every customer among all those different instances of your presentation layer; scale it even more and you’re distributing it to all the different customers within all of those different tiers. In an isolated deployment model, every customer is receiving their own unique website, harsh on efficiency. There’s different reasons why you’d want to go with one option or the other, and that’s why the platform allows you to choose different models at different levels of the app.
Different Reasons? Like what?
There may be regulatory reasons, as an example, to why you’d choose to deploy one model or another. Additionally, there might be technical constraints within your application, where you’re storing state in-memory for your app, and you want all the customer requests to travel to the same instance, rather than round-robining to the different instances of the UI. The platform allows you to configure how you’d want to deploy that automatically, and the platform
will help you to choose different isolation and multitenancy strategies for all the different components of you application, based on how you want to deploy it.
Rigid isolation vs. more relaxed isolation; obviously the closer and denser the customers are packed, the more efficient the app can be run. This obviously enables the app to run at a much larger scale- and this is just one more example of how our PaaS takes care of working the gears, but lets you steer the car.
Stay tuned for the next segment of my series, which begin a sub-series of this blog, meant to explain problems we encountered in our dealings with large enterprises and provide specifics you may not have thought of when considering a PaaS migration. Specifically, the topic will concern On-boarding and provisioning.