Episode 29: On Multi-Tenancy
Hello, and welcome to episode 29 of the VCD roundtable. Today, our topic is going to be multi tenancy, which should be logical with Cloud Director, but we thought it might make sense to have a quick discussion around what makes products, really multi tenant enabled, what are things you are looking for, and what are the advantages for service providers to use, VMware Cloud Director, and why certain other products are not fulfilling the same requirements. But before we get into the topic, quick round of introduction. My name is Yves Sandfort, and I'm throwing the ball over to Matthias.
Matthias Eisner:Yeah. Matthias here. Hello, Sasha.
Sascha Schwunk:Yeah. My name is Sascha. Welcome, Tubi.
Tobias Paschek:Yeah. Hello. My name is Tobias, and welcome to episode 29.
Yves Sandfort:Good. Yeah. So multitenancy. We have seen many products in the past where we constantly kept saying it's like it's a multi tenant enabled product and then, you looked at it and you saw it. It's like, yeah, but really not.
Yves Sandfort:So maybe let's start with the area is what makes a product a truly multitenant. So one of the requirements when you go through audit logs and stuff like that or auditors scenarios is always is that the tenant by itself is completely separated from anything else. So that typically means you have the ability to utilize the same naming schemes and many other areas, for the same customers. So for example, one of the topics is that, networks, for example, can be defined by the customer that it has something not necessarily to do with self, service. This is something which we cover as well, because there is a difference between multi tenancy and self-service by itself.
Yves Sandfort:But the ability that every tenant can basically be the same, so, and can utilize the same resources, the same naming conventions, and other things. And that is typically the first part where you see other products, then, getting into struggles. So that being said, so maybe throw it over to Toby. So what are things you you would say we need in a multitenant product, and what are nice to haves?
Tobias Paschek:Yeah. As as you already mentioned, the capability of separating, infrastructure from from, multiple tenants, on one hand. On the other hand, the possibility to get log, of log files out to get have the possibility to provide log files to a tenant, and also on the on what I always try to, or how I explain multitenances, let's compare it with Coke and Pepsi. On one hand, we have Coke as a customer. On the other hand, we have Pepsi as a customer, and we should absolutely aware be aware that those customers should not see, each other resources, on on one hand.
Tobias Paschek:Also, stuff like identity and access management maybe needs to be separated that each of the tenant has the possibility of utilizing his own identity or or access management, whatever he would like to utilize, a as your active directory or Android nowadays or stuff like this. So there's those are, from my perspective, one of the base requirements we have when it comes to multi tenancy.
Sascha Schwunk:Yeah. Let let me put some, interesting parts in that we have, figured out and, yeah, rethought about the last months is when we talked with hundreds of service providers about the new license model, and they mentioned, hey. We only use vSphere as a service provider. That's completely enough. So we have our ESX host.
Sascha Schwunk:We have a vCenter, and that's our environment. We don't use Cloud Director, NSX, or whatever. And so that's the starting point from my perspective on think about why we need multi tenancy because in a vSphere environment so in most of the environments, every administrator or service engineer of the, service providers have access to all all the complete environments to the from the customers. Not on dedicated parts, I'm not able to say, hey. You can control your own environment for a customer or have a part of service engineers only working with 1 customers to separate it really because we have the physical network where we need the network guys.
Sascha Schwunk:We have the, vSphere net networks. We have the vSphere complete environment, but we have no multitenancy. And though I think the starting point should be that we talk about, how can we support the service providers or how can VMF product support the service providers to become a multi tenant service provider like many other do it currently with Cloud Director. So that's one part, and then think about, yeah, Cloud Director, NSX, and the other products, ARIA, and so on, and how we can bring it all together for the service providers because that's the goal. And if we get this, features that we have now included in VCF, then we are also good with the pricing.
Sascha Schwunk:Because if I only use, vSphere for service providers and must pay for VCF that make no makes no sense. So I think it's important, to talk about or starting at a low level to say, hey. What's cloud director, and how can we use cloud director for multi tenancy?
Yves Sandfort:And and and Yeah. Go ahead. Valid valid point in there as well is, one of the scenarios could also be that a tenant actually brings their own admin staff from third party company, and they need to manage, parts of the infrastructure because, that is more when it comes down to to self-service scenarios. So I might go to service provider a to rent my infrastructure as a service component, but then I'm actually working with another, either reseller or solution provider or something else to install a specific application, manage the application, and things like that. So water part out of multi tenancy typically or ideally should also be that within my tenant, I can actually define permissions, for specific users.
Yves Sandfort:So for example, let's say I'm using an ERP and a CRM solution that they might come from different suppliers. So then I wanna only give one supplier access to all the ERP systems. To the other one, I wanna give them the CRM systems. My own admins can see everything, and then I might have users who only have individual machines and things like that. So all of that is a requirement for multi tenancy, and, ideally, at least, as long as we are talking about customers also utilizing self-service, that would then also require that the, self-service actually gives the ability to manage the permissions, ideally, in combination to what Toby said with Entra or something else so that they can import them from other platforms as well.
Tobias Paschek:As an as an final add on, but, most of the stuff has already been said. But to to extend what what Sasha already mentioned, one clear case should be that the vCenter itself is not multi tenancy capable. Dot. There is nothing more to add or that you can bring to the table to say, hey. Yeah.
Tobias Paschek:But there is maybe a possibility to have a vCenter, as in multi tenancy product. It was never the idea behind. And so, look, also, clearly, nowadays, vCenter is not multi tenancy capable.
Yves Sandfort:And VMware said multiple times, you should not expose your vCenter in such a scenario either to the web or anything else. And if we just take and and I did the, post the other day on, one of the one of the services is when we take a look at the Mitra attack, which which happened just a few weeks ago, that was the perfect example. I mean, they did not come in via a public publicly hosted web, vCenter, but they utilized the vCenter to get access to the infrastructure and actually replace the web components of the v center. How exactly that happened is is not fully disclosed. But, again, that's those are all scenarios.
Yves Sandfort:You need to have that. And when it comes down to that, also, another point is and, that has not necessarily anything directly to do with the fact that you wanna have multi tenancy, but something VMware again and again makes clear. It is expected that if you utilize something like Cloud Director, that you have a true web application firewall, ideally with IDS, IPS solutions, and stuff like that in front of it to protect those systems. So, that is that is clearly one part of it as well. But as said, it's like multi tenancy is is a true requirement for for service providers, and you should have really a complete separation of duties.
Yves Sandfort:Also coming back to the lock topics, which Toby said before, it should be clearly visible for the customer if it was something they did internally or if it was done by the service provider. All of that should be visible in the logs. It should not be in a scenario where you only see the tasks done by your own people, but you should also see what the service provider has done to your infrastructure. Matias, you are awfully quiet. That's unusual.
Matthias Eisner:Yeah. You you can't deal with it.
Tobias Paschek:I I think another interesting aspect is, and that's a combination of kind of multitenancy and and what Sasha said,
Matthias Eisner:who has access to which parts of the infrastructure. In a larger infrastructure with many customers, it's it's pretty complex to keep the big picture in mind. So it's easy to fat finger something like connecting a virtual machine to
Tobias Paschek:the wrong distributed port group. If you just think about a vCenter and you
Matthias Eisner:have an admin handling a few 100 customers, you just connect the virtual machine to the wrong network. It's that simple, and then you create a data breach or anything else. And I think, speaking of Cloud Director, just separating all those infrastructure also from a UI perspective makes it a lot easier to administer stuff. Because if I access a tenant portal of a single customer, I have only the virtual machines, networks, networking services of that customer in front of me on the screen. That makes life a lot easier.
Matthias Eisner:Speaking of. Right? Yeah. It's also kind of having the same subnets over and over and over. I think that's something, it's just not names of networks, virtual machines, whatever.
Matthias Eisner:So object naming. It's also like having identical objects in the same infrastructure. It's also key for multitenancy because many customers prefer the 1921680.zerop24 subnet. I have no idea how often
Tobias Paschek:that is used, but, it's the same. So it's an object, maybe the same name, but also the same configuration
Matthias Eisner:So that's also part of of the game.
Yves Sandfort:Another another important part when we talk about multi tenancy, in tools is that very often, and in this case, in the VMware space, it's Cloud Director which provides that functionality because the underlying products like vSphere, like NSX, or even things like ARIA operations do not necessarily internally provide these, separation of duties. So then it's important that you have a portal which can actually provide this, this clear separation because as we know, as Toby said, it's like vCenter by by itself is not knowledge and enabled. NSX has some pieces, and maybe we can cover that. But ARIA operations, I mean, there is this this this long, long ago, white paper which which, we wrote around the topic of how to, yeah, more or less misuse recent operations manager back in the days as a multi tenant solution to overcome some of these hurdles. Luckily, nowadays, we have better solutions for that, but that's another important part is when you look into multi tenant solutions is how good can it integrate other tools because the reality is, the majority of products are not multi tenant enabled.
Yves Sandfort:It has become better in the last couple of years because more and more software vendors built for cloud and SaaS and identify that they don't wanna have everything installed on a per tenant basis. But, you still see how often companies and software struggles with the fact of, having multi tenant features in the first place. And and and, I mean, maybe maybe we cover exactly the NSX part. I mean, there is always it's I I always have the feeling it's a it's a 4th and back because it's it's always pointing bubbling up on some of the n a 6 slides. It's like n a 6 is now finally multi tenant enabled.
Yves Sandfort:And then you look into it, it's like, yeah, maybe not.
Tobias Paschek:May maybe not. Let's let's quickly have a look because I think we had already a session about also, I know we had we had a session about NSX project. The idea behind NSX project is to get a sort of multi tenancy, but more or less as an from an enterprise customer perspective, to really have the possibility that inside an enterprise organization, you have different, departments, different, stuff. Yeah. They really should consume their own geographies, their own firewall rule sets, and you can limit it more or less on on the amount of how many networks, how many, tier 1 gateways, how many firewall rules, and stuff like this.
Tobias Paschek:So it is, as as you mentioned, Steve, it is a sort of multi tenancy, but never ever really going down to the whole infrastructure. So inside an n six project, for example, I cannot deploy my own edge cluster. This is always something the organization admin or the, full admin of the of the whole NSX environment needs to deploy a new edge cluster, needs to create the tier zero gateway, and then assign the tier zero gateway to my, to my NSX project. So I will never ever be capable of really utilizing the the full underlying, infrastructure or bringing additional host to stuff like this. So also from from an there from multi tenancy perspective, con from a consumption perspective, yes, but not what really is the, is the use case of having self-service, having, really multi tenancy capable, environments.
Tobias Paschek:And
Matthias Eisner:That's Cop Director's job. Right? Yeah. From from a service perspective. But I think with the with the networking, piece, it's it's always a bit difficult because we're still talking about networking.
Matthias Eisner:So a centralized network infrastructure. It's not so we could start a philosophical discussion. What is, true multi tenancy in the network? So some would come up with, like, yeah, physical separation. I so I can do whatever I want.
Matthias Eisner:That's true multi tenancy, or am I allowed to share the same physical gear and use just VLAN for separation and add some firewalls on top, like tenant a, tenant b, tenant c, so physical firewall separation. So I think it's
Tobias Paschek:a physical, philosophical, discussion, what's true multi terms.
Matthias Eisner:And I think it's the exact same thing for NSX. You're you're not kind of installing the same physical infrastructure over and over and over because there would be a vCenter, ESXi host, and so on and so forth, and additional NSX managers. So it's a per tenant installation. I think NSX projects, it's aiming for enabling, and as you told me, started with enabling different departments within a customer to manage their smaller network infrastructure, which is part of the whole, and, USA provider make sure they can't mess up with the, physical upstream network by implementing proper prefix filters and and routings and and stuff like this.
Tobias Paschek:Sasha, you would like to add something, or you started already? Yeah.
Sascha Schwunk:My question was with the with the NSX project. So that's new, only for new deployments, or can we deploy it in Brownfield? Uh-huh.
Tobias Paschek:Yeah. Tough one. You can, you can enable the the compute managers or at the end, the vCenter after you have, in instantiated it. You can say, hey. It is now, multi tenant.
Tobias Paschek:But, there are a huge there is a bunch of requirements which needs to be fulfilled to change it afterwards. So, technically, we can say yes, but the the truth will from from my perspective at the moment is, you know, if you have if you have started already, ramping up your whole environment with without multi tenancy, you a little bit messed up. From a pure NSX perspective, absolutely. So you can every time you can go into your NSX manager and say, hey. I would like to create a new project, bringing in all of the necessary information.
Tobias Paschek:The matching part the the most important part currently, regarding projects, is the vCenter because the vCenter, needs to be enabled as multi multi tenant capable or project capable. I don't know how the right name is currently, to be honest. But it is it is kind of brownfield capable. Yes.
Sascha Schwunk:Okay. That means, it's best practice normally if I create a new environment with a new presenter and bring it in. That's the easiest way
Tobias Paschek:for them. But then you need to have a look into the documentation, what is then not working currently. Because there are slightly differences between having, vSAN and, multi tenant enabled. Not all of the stuff currently is really working. But to be honest, most of the stuff is related to, the old tool balancing, not to the new one.
Tobias Paschek:But I I I have something in mind, not really 100% sure. Also with ALB, you no. ALB is currently not capable of projects. So ALB can be only integrated in the main, or in the in the in the master let's call it master tenant, but not in any kind of subproject. So this is also some something you we need to have in mind currently that ALB is not aware of, NSX projects.
Sascha Schwunk:Okay.
Tobias Paschek:But, hey, we are talking about 2 VM products, so why should we be company compatible to each other? Competibility is overrated. Abs Abs Abs absolutely. And it's it's all it it depends. So before using an executive project, you should do a proper design and and, discussing the pros and cons anyway, and and validate if it even makes sense for your infrastructure, introduce that new feature.
Tobias Paschek:But I think Brownfield is is pretty complex to introduce it, and it's even even worse if you have Cloud Director on top. So you should start with a separate infrastructure, new NSX manager projects, and then migrate customers over.
Matthias Eisner:Good old migration updating scenario.
Yves Sandfort:Maybe maybe let's also come to the difference between self service, multi tenancy, and, managed service or however you wanna call it. Because a lot of service providers out there are also providing just managed services, so the customer does not necessarily have access to it. And very often, we have the discussion then is, do we really need CloudDirect? Can't we do all of this directly with NSX and v, and vSphere and stuff like that? And while it's in theory you can do this, and you can create your permissions and roles for your internal teams to keep all of that separated and everything else, I would still argue that in many, many cases, it would be better off to directly start in a a VCD environment or at least start implementing it moving forward for new customers.
Yves Sandfort:Because we also hear more and more that, customers wanna have access, console access to machines. Customers wanna have the ability to, manage even only part of parts of the machines and stuff like that. And that is really getting difficult if you are not set up for it. The other advantage is, again, coming back to the locks, if there is ever an incident or anything on a specific customer, it's much easier if you can pull everything out of Cloud Director and just say it's like, hey. Everybody uses this tool.
Yves Sandfort:So we can actually say who accesses, who did have access to a console, who did make changes to the networks, to firewalls, and all of these different things because everything is managed directly within Cloud Director, rather than having tons of different products where you need to pull it and it's not separated by by tenant. Clearly, so far, even in BCD, not everything is perfect, from a from a logging perspective, but it's much easier in such a case than it is with a, with a stand alone system. Also, let alone if you keep your people and your management teams as managed service provider utilizing cloud director, the side effects if you ever have a security incident by yourself as a service provider is potentially lower because people don't have admin privileges on all the back end infrastructure. And in reality, most of the people don't need that. Whereas in the vSphere and NSX environments, we very often have seen when service providers did this, really with the, let's say, more bare metal tools that most of the people had more or less complete admin privileges.
Yves Sandfort:So if anything happens in your infrastructure, someone immediately has access to everything. Whereas in the say in the cloud director scenario, you can be far far more detailed from a permission and role perspective because, also, the default roles are set up for service provider environment. So you can actually easily adopt one of these roles, whereas when you look at the vCenter or in the 6 roles and permission sets, then very often they are meant for enterprise use. So they are not meant to separate clients from each other and stuff like that, which can also, when we talk about sovereign clouds in Europe, become a scenario where you wanna separate by countries or other things. So there are tons of different scenarios.
Matthias Eisner:Yeah. It's not just just about it's all about security, but it's still, even though if you have a really small team taking care of all the customers, using a multitenant platform makes it easier to administer even though I'm administrator everywhere. Even though if I just see one customer and virtual machines, networks, and services belonging to a single customer makes life a lot easier for everything, deploying new stuff, troubleshooting, and so on and so forth. Yeah. Now it slipped.
Matthias Eisner:Sometimes it happens. Right? It was a really nice thought and now it's gone.
Yves Sandfort:And another area which which which makes up, the whole budget or it's it does not necessarily belong to multi tenancy, but it is a feature set which is often requested. It's having the ability to have a generic shared catalog of either applications or media and stuff like that, and then individual ones per company. So as a service provider, I can then provide, like, basic Windows images and stuff like that, And then the customer can add their own images and scenarios like that as well. That requires a certain set of capabilities in the toolkit that you can do that, which is potentially more complex if you try to build something like that in an vSphere or in a 6 baseline scenario.
Matthias Eisner:Also, enabling, like, a a shared few or shared few environment in terms of. So I'm not talking about co manage because that's a
Tobias Paschek:a no go scenario for me.
Matthias Eisner:But even though if I consume managed services, I can enable the customer to with a read only role. So I implement something. The customer files a ticket. I built a service as the customer requested, and then the customer has read only access to only his configuration. And so it makes it a lot easier because if the customer kind of requires a reconfiguration, let's say, an additional firewall rule, whatever, the customer can review the actual current used firewall rule set and then file a ticket asking for, could you please do the following change?
Tobias Paschek:So I think that's that's also pretty neat with with a CMP, which is multitenant. Never do co manage.
Matthias Eisner:So just what what is comay comanaged is self-service and managed service at the same time. So customer and service provider have administrative or read write access to the same configurations, and both are allowed to implement changes.
Sascha Schwunk:That's kind
Matthias Eisner:of a nightmare scenario for everyone.
Sascha Schwunk:No. What we see in in many with many service providers, they have partners, small system integrators that brings their own customers to the service providers in an yeah. Let's call it double managed environment. That are that are normal use cases on many of our service providers. And then a good solution is they are partnering very good together and bringing value because, normally, a service provider are not managing the Windows servers or applications, whatever running in the environments.
Sascha Schwunk:That's not task of service providers in the most use cases.
Matthias Eisner:Mhmm.
Tobias Paschek:It really depends what I what I say could can can be if it is kind of of managed service approach with with additional cell self-service, but also what you mentioned right now, Sasha, that the service provider itself is only really hosting the environment. But he has also some, companies, saying, hey. Okay. I will not host a whole cloud director stack, but I will, utilize your data centers for providing my, end customers the the services like Active Directory and stuff like this. So it is always I think it is a mixture mixture of all.
Tobias Paschek:Yes.
Sascha Schwunk:So those especially on the on the bigger service providers, that's the same like on the hyper scaler. So the hyper scaler provides the infrastructure, and, the system integrators or smaller service providers, yeah, using this infrastructure like, Asia or Google infrastructures to provide sales services for their customers.
Yves Sandfort:Good. So anything we missed on the multitenant topic? I think we kind of covered most of the areas. If any any one of our audience has any questions, feel free to drop them in. But I think we we covered most of the of the most important topics so that we have, things like, clearly separated user management, which is something we covered.
Yves Sandfort:We've spoken about, having clear lock management, clear permission management. I think, one part which we didn't cover is, but that, comes more or less natural is, performance management. So the service provider can define, which performance settings can be managed by the end customer. There might be needs for branding. However, I don't necessarily always see that as a as a strict requirement in the first place.
Yves Sandfort:And Yep. But you're capable of doing
Tobias Paschek:that that you've
Yves Sandfort:Yes.
Tobias Paschek:The only one in the whole organization.
Yves Sandfort:Don't tell anyone. However, I have given up the secrets of the databases already to some. So maybe that's the next I have to give up.
Matthias Eisner:I can't remember. Mhmm. Better.
Yves Sandfort:But yeah. So I think that that more or less that covers it, and that is that is also for those service providers who are currently looking into potentially jumping ship from the from VM rep perspective as you're evaluating new tools, potentially take today's session as a list of requirements you should really be looking for. Again, I would I would still argue is it's it's not necessarily easy to find, all the replacements. We know some people are doing it, and that's perfectly fine. But I think it's it's also important to say is, like, multi tenancy is highly complex.
Yves Sandfort:I mean, VMWare wanted to get rid of, of Cloud Director for many, many years, and finally always figure out it's not that easy. It takes too much time or is too complex, and there is too much difference towards the enterprise tools. So, it's going to be interesting. I mean, we have seen also the road map and everything like that, for what the new plans are. Let's see.
Yves Sandfort:Let's cross that bridge when we get to it. I'm going to be it's going to be interesting to see how much effort it is to actually bring all the features and functionality into all the other, VMware products versus just keeping Cloud Director as it is and maintained. But I think that's more or less covering the multi tenancy topic. Do we have any idea already what's going to be there for episode 30? I mean, not that far out.
Tobias Paschek:Let let's see what the next product cycle is really shows up because I have heard some rumors that maybe some new versions are approaching. Let's
Matthias Eisner:see.
Yves Sandfort:So it could be a release nonsession then, or it could be something else. It seems like we have a lot of interesting security, topics coming up in the last few days weeks. Also, if you haven't seen the post, it's like, please, please, please make sure that you update your systems. The last, the VMSA, I think, 2024-0011 is not fun. Really make care take care of that one because, if your customers have the ability to, utilize a CD controller, you are in trouble.
Yves Sandfort:And not only that, there are a few other things where you might be in trouble. So better be, safe than sorry. So make sure that you, keep your systems updated. Also, if you haven't done so, try and make sure that you subscribe to the Broadcom, security, lists because the old VMware ones are not sending out anything anymore. So you need to be on the new lists, to get, all the latest and greatest.
Yves Sandfort:From that perspective, you can also subscribe to my channel, but I'm not guaranteeing that I'm always up to date to the day. So, when I go to the source as always. Okay. That being said, next recording is going to be approximately in 2 weeks. I think we haven't yet finally set the date and time for that because at least Sasha and I, I think, are not 100% sure where we are then.
Yves Sandfort:Or we know where we are, but we don't know where where we have the time for it. But, that being said, thank you all for watching. Also, to all of those who are watching us live every every few weeks, the number of people is constantly growing. We like that. We also like more interactivity.
Yves Sandfort:So come with questions, throw them in. You can actually influence topics we are going to talk about. So the more you actually, participate in the sessions, the more you will get out of it what you want. That being said, I'm already saying bye bye and handing over to, Toby for the final words.
Tobias Paschek:Yes. Thanks for joining. Maybe one one last add on or one one last comment on the on the whole discussion for the day because Sasha mentioned it already. But may just to to rephrase it a little bit, especially US service provider now with the new license model, VCD is there for more or less free. It is included in in the in the
Sascha Schwunk:base, license pricing, so just utilize it. So that's my last words for today. Sasha. Yeah. Zip together with architects, plan your environment, take a look what's possible with the features you pay for, and the features are available, and, then plan your infrastructure.
Sascha Schwunk:Matthias?
Tobias Paschek:I still don't vote for co managed.
Yves Sandfort:I'm more final words. No co management for Matthias. And that being said, thank you all for watching, and have a wonderful week. Bye bye.
Matthias Eisner:Thanks. Bye.
Creators and Guests
