Agile Platform 7.0 - Multi-tenancy Webinar



Nuno Antunes Nuno Antunes
Product Management
  Rodrigo Coutinho Rodrigo Coutinho
Head of Product Marketing



Rodrigo: Welcome, everybody to the Multi-Tenancy in the Enterprise webinar. In this webinar, we'll have Nuno Antunes from product management.

Nuno: Hi, guys.

Rodrigo: And myself, Rodrigo Coutinho, and I work with product marketing in OutSystems. Before we go into the hard-core demo that Nuno here will deliver, I would like to talk a little bit about the problem that we're trying to fix, and why did we add this feature to the Agile Platform. Essentially, the problem here is the problem of scaling your business. So, let's assume that you have your own sales team, and you build an application using the Agile Platform of course, that your sales team can use to register their deals, their accounts, opportunities and so on. And, of course, that application is connected to a database. And because no application lives on its own, it's actually going to be connected to external data, external systems, and all that stuff. The challenge comes when you want to scale this sales force either because you want to have a new office in a different territory or because you want to open this sales application to your partners, whatever the case may be, suddenly, you have a new team that also needs to use the application. But because there's privacy issues and data issues and so on, what you end up doing since they have a different location is installing the same code you had before, but only in a different infrastructure on site for the territory or the partner. And of course, this means that because you have problems segregating the data and so on, you replicate the database. Unfortunately, you cannot, usually you cannot replicate the integrated system, so you actually connect to the same systems as the first system. Now, this could be a bearable situation. The problem is when you want to actually grow again. And, of course, we could think about this problem ad infinitum and with hundreds of teams. Now, what is the problem here? Well, the problem starts at the integrational level, right? So suddenly, you had a system that's integrated with just another single system on the local network, and now you have to open up to be able to connect with your partners or the other territories. So you have your security issues. Of course you have the problem of total connections, especially if there's a lot of data moving back and forth between these pipes. And, let's face it, usually when you have a connection over the internet to an external system, it's going to fail exactly when you need it. So, this is just one of the problems. The other problem is regarding the code base, so the code of the actual application. Well, you have the code replicated, which means that if you want to do an upgrade, and you probably will as time goes by, you're going to have to upgrade the application in all the instances you have of the application. Of course, as soon they duplicate the code for territory or for partners, there's going to be rogue customizations. So, people are going to go there to the code, they're going to change it to their special situation. And suddenly, the upgrade, which was a problem because it was multiple locations, it's going to be a nightmare because you have customizations. And finally, you basically end up with three different places to configure your application, your security policies, and so on. So, it just multiplies the problem by the number of installations that you have. And of course, the big problem that you have is at the database level. Everything that's shared that you're going to replicate among all your installations, it's going to be really tough to manage the systems. And even worse, if you want to have a view of all your sales aggregated, regardless of if they're partners in different territories and so on, it's going to be almost impossible to aggregate the data from all these systems in a single report. And finally, of course, customizations of the database are only two steps away, right? As soon as it's customized code, the next step is customizing the database, and double the nightmares, of course. So, a better way. How can you do this? Obviously, the idea here is to have a single code base. So, basically, you have everybody accessing the same application, and thanks to the internet, that's very much possible nowadays. Now, of course, what that means is that you have a single database that's shared among the several businesses. Of course, you need to take care of things like security and so on, but by fixing this, you also fix the point of integration. And this is the notion of multi-tenancy. So, if you want an analogy, you can think of multi-tenancy, and actually the term comes from there, like if you have a building, right? You have this building where you have common infrastructures, like the elevator, the water pipes, the central heating, and so on, but then each person has his own apartment. Each person is a tenant of that building. That's basically the analogy. Share the common infrastructure, and then have private places for each person. There's a bunch of benefits for this. Of course, you have a single place to configure all your security, all your data, all your processes, so everything is consistent across tenants. Developing the application becomes simple in the sense that you're just developing for a single instance of the application, and it's much easier to maintain because you just have to put it into production once. In terms of infrastructure, instead of having an infrastructure per each territory or per partner or whatever, you have a common infrastructure. So again, the costs are much lower, and it gives you an economy of scale. It's much cheaper to create the new tenant than to create a new full installation. Multi-tenancy is good. It's a solution for our business problem, but that doesn't mean it's easy to do, because when you start thinking about multi-tenancy, you start coming into other problems. The first one is obviously at the database layer. You need to make sure that you handle the shared versus private data in a secure manner. Though, and this is especially important if there is like, if the people accepting the data are competitors, you need to make sure that they're not able to see each other's data. So, it brings kind of a challenge at the database level to make sure that things are kept segregated. In the same way, you need to ensure data consistency among all the tenants. So, be sure that everybody is using the same standards, that if it's common data, everybody's using the same common data. And, of course, another very important point, because usually the database is the bottleneck, you need to make sure that having multi- tenants does not impact the performance of your database. Now, the problems aren't just at the database level. They're also at the code level, because, let's face it, implementing all this security on the code is hard. You need to make sure that all database accesses only go and fetch the right data, so you don't have access to data on site. You need to make sure that your users cannot by accident jump from one tenant to another. And to be honest, it's just very error-prone. It's very easy to make a mistake on these type of scenarios, and suddenly an innocent move to production leaps with security breach on your product that can have very serious consequences. And it was with this in mind that we actually added this capability to the Agile Platform. So, what we thought is that there's got to be an easier way to do this. We've got to empower developers to do this in a much easier way. Now, I could talk about this, but I think it's much better if now I move control over to Nuno. And he's actually going to explain and do a demo of how you can build a multi-tenancy application using the Agile Platform. So, Nuno, I'm going to hand over control to you, you are now the presenter, and have a great demo.

Nuno: Thanks. Let's begin. So, the scenario here, just like Rodrigo was describing, we have this application, and for this purpose, I bring the sales application. For those of you who aren't aware, let's just go off-topic here for a little bit. For those of you that aren't aware, we have these really nice open-source applications. They're available on the website. They're also available directly on the service studio. And you can install them, give them a look, give them a try. They provide really useful patterns for you to start building your own applications, and you can use them as well. So, they're all fully working applications. Also, the tutorials are very important when you are starting out. They're over here. Just give them a look, just in case you haven't done so already. So, getting back to the topic, I just installed this sales application as is, and it provides basic sales functionality. You have a dashboard. You have a list of contacts and a list of opportunities for your company. So, the scenario here would be to provide this exact same application to a new partner. So, we've got a new partner in the U.S., for instance, and we want to provide him this exact same application, but of course we don't want him to see our own data. So, the way to go here, as Rodrigo was discussing before, is to actually make this application a multi-tenant application. And usually if you were to do that by hand, and you can do that, I mean, you can come here and access every query, and make sure you filter per tenant, but that would be a huge effort, lots of risk involved. In the Agile Platform, we make it really easy. So, in terms of the application that's running, all you have to do here is you select the module, the sales module that is running here, and you have this advanced property here called 'is a multi-tenant'. And all you really have to do is say, yes, this is a multi- tenant application. You can notice that there are some icons here in the entities that have changed. Let me go back so you can see. I'll change them again. So, I'll explain these changes right away. Let me just publish. So, from the developer's point of view, that's it. You don't have to do anything else in terms of development. So, you now are publishing a multi-tenant, or a tenant-aware application, and that's all you had to do. In terms of changes, just to see what's going on underneath the covers, you noticed that some of these entities now have this darker column here, and this means that these entities are now tenant-aware entities. So, an opportunity account manager can now, all data, segregate it by tenant. Notice, for instance, that the menu item for an opportunity's page, these are static entities, so they just have a common set of records. So they are, by definition, single-tenant. So they're the same for all tenants. You can also extend this concept to standard entities. So, if you want to, for instance, make account managers, which are now tenant-aware, but for whatever reason, you want to make account managers available across all tenants so that you have borders and all your partners, they see the same subset of account managers. Then, you can always override the default configuration and say, is multi-tenant, no. And then, that gets things back to where they were previously. If you want account manager to be tenant-aware so you can have different account managers across your tenants, you just say yes, or don't say anything and just let the module d space default take care of things. And now the thing, this is important to note, when you use references to other external entities, for instance, we are reusing a bunch of entities from customers' application, so we have companies and contacts, and these were defined as single-tenant, so they are the same for all tenants. And that doesn't change when we reuse them here. So, if you want, for instance, to have contacts tenants-aware, you would have to change them in customer's application so that customer's application is itself tenant- aware so that when you reuse, you would be reusing a tenant- aware entity here. So, by default, everything, companies and contacts and whatever, will be used as single-tenant. What else can I say here? We can look - for instance, there are no more changes. If you look at the queries that you have in your code, you don't find any tenant id = current tenant or whatever that you would expect if you were doing this by hand and coding it. And debugging also works seamlessly with multi-tenant, so you can debug multi-tenant applications just like you debug your regular, or we should say, single-tenant applications now. One final note is that the same thing that applies to entities is also available for site properties. So, site properties can also be tenant-aware. You can say that application name, for instance, can be multi-tenant or not. And in some scenarios, it makes sense to be the same, because the application has the same name independent of the tenants who are accessing it. In other scenarios, it may make sense to customize for each tenant. So, for instance, if I wanted to have a site property with a company name, it could be different for each tenant. Is that true?

Rodrigo: Yeah. That's it.

Nuno: Awesome. So, just like entities, you have that option here. So, that's it. I published the changes that I did, and let's go back to the application. So now, I have a multi-tenant application, but it's actually running as single-tenant because I only have one tenant running. But what's great about this is that everything that was available in the application is still available after I published the tenant-aware application. And that's because we have this notion of the default tenant that gets raised to a proper tenant when we have a tenant-aware application. So, all the data that we had previously is still available here. So now, the next step would be of course to create the new tenant. So, I have this tenant management application here that allows me to create tenants and add users to specific tenants. So, I could say it's a partner U.S. that I'm going to create, so it's a tenant where my U.S. partner will live in. And now we'll create a user here, and I'll call it Steve, and just some basic data that I need to put here. So, I have a U.S. partner, and Steve is a user in that tenant. And for the role, since I want him to be able to access the sales application, I have to provide the proper role, which in this case would be sales manager. Okay, configuration is done. Pretty easy, right? So now, just to test if everything's working fine, and let's hope it is, I'll log in as Steve, and voila. You have - now Steve is running on a different tenant, so you see no data here. No opportunities, yet. But for all single-tenant or shared data, that data is still available. So contacts, which are available across all tenants, are here. Opportunities, there's no opportunities. Let's just create a - it's good to run the demos previously, right - this amazing U.S. lead here, and just place an amount of $30,000, that's a good starting point. Okay, so now I have this opportunity, which is really running and isolated into partner U.S. tenant, and it's not available otherwise. So if you were now to create a, I don't know, a sales Netherlands tenant, there would be no way that they could see this opportunity that Steve just put in. Is that it?

Rodrigo: Yeah.

Nuno: And, in fact, we'll get to that later on. That's a great question. Just a quick detour to show you that although we provide all these capabilities out of the box so you just configure an application to be multi-tenant and you have this tenant configuration back office, there are many scenarios where you probably need specific requirements in terms of tenant provisioning, user validation, and different user scenarios. So for that purpose, we also provide a set of APIs that you can use to build your own custom tenant provisioning scenarios. As an example to that, I have this self-register e-space here that you can get - oh, by the way, maybe I can share with you, if you go to the Agile network, we have a tech note there, it's called 'How to Build a Multi-Tenant Application', and this tech note actually goes, more or less, through the steps that I've shown you here. So in case you have any doubts, just download the tech note and go through it. And there's this - you have these companion resources which are available where you can grab these open-source samples so you can explore further. And one of the samples that you can download from here is actually this self-register e-space, which basically is a screen, a very ugly screen, I have to agree to that, that allows you to create tenants. And this is a requirement that we had from ISV's that want to build software as a service applications. Typically in software as a service, you want your user to be able to register by himself, but then once he registers, you want to create the tenant for him, et cetera. So what we did here is a very basic functionality to handle that. Let me just publish this, and while this publishes, just take a quick look at what's happening here in terms of the API that we're using. So, as we log in, we have a couple of validations going on up there to check that the data is properly set up, and then we have the usage for tenant create, which, of course, creates a new tenant. And then you have this magic action, which is a tenant switch, and what it does is it changes the context where the application is running. So it's sort of like, in the apartment analogy that Rodrigo was talking about, it's like you're moving out of your apartment and walking into the next door apartment. So you're switching from one tenant to the other, and from then on, everything that happens happens in the context of this tenant that you switch to. So inside this tenant, we create the user, we do the log in, and we grant the roles that the user will need to run his applications. So, let's open up this self register. So, let's do the partner Netherlands you suggested. And I'll create it. So, what happened now, and I can log in now, what happened now is that actually using the API that you saw up there, I just created a new tenant called partner Netherlands, and a new user, and I added the roles that he needed to run his configuration. In the end, I also have the link to send him over immediately to the sales application. That's why you moved on to the log in page. So, this is just an example of what you can achieve by using this API actually to configure your own scenarios, your own tenant management scenarios. So, I'm sort of done for here. Let's go back to the slides. Rodrigo?

Rodrigo: No, no. It's over to you.

Nuno: It's over to me?

Rodrigo: Yes. Just stop showing the desktop. There you go. It's magic.

Nuno: Okay. So, just a quick recap of what we have seen. So we had this sales application, your typical single-tenant standard application where we have a couple of users and some data. Then we made it tenant-aware. Then we created a new tenant so that things were properly segregated. So, what are the key points here? It's very easy to set up this. You have the built-in capabilities. You have the API so you can customize at your will. Just a few notes: users are bound to a single tenant, so a user that is in corporate cannot access data from the other tenants, which is desirable here. Also, we have support for shared-data scenarios, so account managers and opportunities were segregated, but, for instance, we have the customer information which was shared. Okay, another demo. Let's say I want to, like Rodrigo mentioned before, I want to have consolidated reporting over my multiple tenants. And that's kind of hard. Well, maybe not when you have two or three tenants that you can just replicate some data and run some back shops, but once you start having many tenants, that becomes an issue because you have all this data moving back and forth so it's really easy to break and complex to set up and maintain. So, these scenarios with the platform, we consider them while designing multi-tenancy. So let's say that for instance, I, as corporate, I want to have a report where I can check all opportunities across all tenants so I want to see how my company is doing in terms of leads worldwide, so I'd like to check opportunities across tenants. How would I address that in the Agile Platform? So, to do that, if I go to sales application, and sales application by default comes with two modules, let's say I want to build a new e-space module for the sales application, and what I'll be using this for. So, just making it really easy, you would have to probably invest more here, so this is just for demo purposes. Let me just move opportunities from sales into this reporting module. So, we move things here, so we now have opportunities available on this new module. By the way, let's just call it 'Back Office Report'. And you have the opportunity entity which is using as a reference from sales. So what I want to do now, I want to use the opportunities that I have, but across all tenants. So I don't want to use them as tenant-aware, but as an overview of all the data that's available. So for that, we provide this advanced scenario, so it's probably placed in an advanced tab, right, where you have this capability to click here, show tenant identifier. And you'll notice that the color here is changing from blue to red, that's really to alert you that now you're using that not as a typical multi- tenant, although the entity's tenant-aware, you are going to use it as a regular single-tenant entity. So, let's just move the opportunities. Okay, it's doing its thing, and that's it. So, I guess I can just publish, and let's see how it goes. Okay, I leave it anonymous. You have to be registered. Everything should work okay. So the important thing to note here is that this is functionality that really makes sense when you're doing back- office reporting, when you want to do data management, data processing, or validation processes across all your tenants. So now we get to see the data, here, hopefully, and soon. There you go. So, you have all the opportunities here, and notice we also have the amazing U.S. lead that we created in the other tenant. So, they're all here. And this, I guess, this ends the demo. So, let's get back to slides. So, recap on the benefits of what I've just shown. In terms of operations and management, having just a single source code and a single infrastructure to manage, this provides a very cost- effective solution. You don't have to have multiple servers or multiple databases to manage different tenants that would be at a lot of cost and a lot of management effort once you go down that path. So, highly cost-effective in terms of management and maintainability. Also, in development, it's curious because I said it starts smaller... Yeah, but it's huge, in fact, so it should be the other, right? Don't know what happened here. Things change. But what's great about this in terms of development, the savings, it's really easy, as you've seen, to make an application multi-tenant. You don't have to encode all your queries, making sure that you're making the right filters in the right place. You don't have to go and make sure everything's - just leave it to the platform. Let the platform handle the plumbing, the multi-tenant plumbing, and just develop applications just as you would develop a single- tenant, your usual single-tenant applications. Also, in terms of quality assurance, you have huge savings, because testing multi-tenant applications is a nightmare scenario where you always have to log in as this, then log out, then log in as that, just to make sure that data is properly isolated and the use cases are well-supported. Well, you can bypass that here. So just, develop, keep focus on the business features, develop applications just like you do today, and multi-tenancy just comes out of the box. Also, in terms of security, and this has always been a big issue when we were designing, because most requests from ISV's for instance, that wanted to build this software as a service application, they had this notion that I'm going to release this application. I'm betting my business on this software, so I really want to make sure that I don't have security issues or data breaches. I don't want customer A to be able to see customer B's data, whatever the scenario. So security is really key to me. And adding that enforced by the platform, instead of relying on the developers, which are probably pretty awesome, but they're known to make mistakes every once in a while. So, leaving that to the platform really adds to trust that the security is enforced at the right level, at the platform level. And you can ensure this consistent data isolation, and you don't have really to worry about it on your day-to-day job. Also, beyond data isolation we have as we've mentioned the open- source samples, the APIs that you can use to build your own custom scenarios, And also the support that we've just seen for these cross-tenant scenarios where you have to access data and process and access data from multiple tenants at the same time. Last but not least, as we've seen in the first demo, this is like a side-effect, but it's really a nice benefit, that you don't have to make any upfront decisions. So if you want to develop a multi-tenant application, sure, you should do that from day one, but you don't need to have that in mind when you start developing. So you can start with your own applications and then make them tenant-aware. So it's - overall, it's pretty simple. That is key, a key concept that we had when we launched this new version 7. It was all-around simplicity, and also here in the multi-tenant, I'm pretty sure that we were able to achieve these goals. So, I'm done here. Rodrigo, I don't know if you want to add anything else?

Rodrigo: Nuno, thank you very much. That was an awesome demo. I do have a couple of questions here. And, by the way, if you have additional questions, just post them on the chat window, and we'll try to cover as much as we can. So, the first one I will answer myself, because it's very easy. And it was, will the recording of this webinar be available, and yes, we are going to make the recording available, and we'll send you an email as soon as it's ready so you can share it. And the second question is, how is multi-tenancy licensed? Are there limits to the number of tenants I can have? How does that work?

Nuno: No. Actually, the good news is that multi-tenancy is a feature that is provided with an enterprise edition subscription. So as long as you have an enterprise edition subscription for 7, multi- tenancy is already there. You can use it or not, but it's there, available. Also, there are no limits in terms of the number of tenants you create, so you can have one tenant or one million tenants. That wouldn't be a problem. And also, there's a nice thing here is that there isn't a direct impact on performance by having more tenants, so we - of course, as you add more tenants, you add more users, so the load on the system increases. That's a fact of life that you can't bypass, but regarding multi- tenancy itself, you can have one, 10, 100, 1,000 tenants, and that really doesn't matter. So, in terms of licensing, it's available, all users are named users, so that's basically pretty much what we had before.

Rodrigo: Okay. And I think you already answered the other question we have here that was regarding performance. So, adding additional tenants doesn't affect performance? Right? That's what...

Nuno: Yes. Yes. So, even if you already have many tenants and you now want to change your application, deploying a new version of your application is also independent of how many tenants are created at the time.

Rodrigo: Okay. So, I'm trying to gather the questions, and one here is that apparently, one of our attendees has a custom application to create users instead of using the default users application. Can they use it to manage multi-tenancy users? Is that something that is possible to do?

Nuno: Well, you're talking about the end-users? Those users should be registered at the tenant level, so they should be registered with a platform and as part of the user's e-space. So, they should really be creative with a standard platform. Although, I'm not sure if that is the scenario, you can import users from active directory, or other old apps, so I'm not sure if that is the case here, into the platform, so they're properly registered. And you can have them arranged in terms of tenants once they're configured in the platform. Other than that, we should probably take a look at the implementation. I would suggest that you get in touch with me and Rodrigo. You can send an email to product management with your scenario, and we'll take a look at it gladly.

Rodrigo: Okay. I have a tough one. This is a tough one. So, we have a question which is, what changes do you have to make to convert a current application to multi-tenancy when the application was already built to be multi-tenant?

Nuno: Oh, that's a tough one, indeed.

Rodrigo: I'm guessing it depends a bit on how multi-tenancy was implemented, right?

Nuno: Yeah, it depends on how it's implemented, so I would say that you would really benefit from reverting the tenant-specific implementation that you already did, and rely on the platform's capability to do that. But we definitely would need to look into the details and see what that means, because depending on how it's implemented, that could be a huge project on its own.

Rodrigo: I can imagine a couple of auxiliary e-spaces just to move data around, right?

Nuno: Right.

Rodrigo: That's probably going to happen.

Nuno: Right.

Rodrigo: Which leads me to another interesting question I have here, which is, is there a master switch to make an entire application multi-tenant? We talked about multi-tenancy spaces. How does that work at the application level?

Nuno: Yeah. Here, what you have to do, the master switch is just the switch for all modules or all e-spaces in this event. So, if you have three or four modules that compose your applications, you have to go through to all of them and say whether they are tenants or whether they're not. So, there is not an accelerator at the application level, but you have to do that. And also, many times it also depends on the architecture on how the application is designed. For instance, if you have an architecture where you have UI layers in one module business, the rules in another module, and your data in a third module, then the change would actually be to change the third module, which is the data. So, it wouldn't be that hard. So, if things are more mixed up, so you probably have to have, but it's just change the property and publish again. So, that should be really simple.

Rodrigo: Okay. Another cool question we have here is, so the e-space is on the report, right? You showed data from all the tenants?

Nuno: Right.

Rodrigo: Is it possible to select only a few tenants, because, let's say, I have partners...

Nuno: Oh yeah, sure.

Rodrigo: from the Netherlands.

Nuno: Sure, sure.

Rodrigo: How would you do it?

Nuno: Sure. You have access to the tenants through the API, so you can just filter the data accordingly. In fact, that is why the advance property that we've shown is called 'show tenant ID'. So, that's not the greatest of names we've got, but that's actually what it does. It exposes the tenant ID, so you can filter for whatever. So, you just access the tenants table, system table. You can check which IDs are valid, and you have the description, and then you can just do your thing and filter by whatever criteria you want.

Rodrigo: Excellent. So, I think we're done with the Q&A session. So, everybody, once again, thank you very much for joining this webinar. It was a pleasure giving it. Thank you very much, Nuno, for a great demo and great demonstration.

Nuno: My pleasure.

Rodrigo: I hope we will meet again soon. And we're going to have a recording, like I mentioned, and we'll send it to everybody as soon as it's done. So, thanks again. See you.

Nuno: All right.

Rodrigo: Bye.

Nuno: Thank you, guys.

contact pricing