• English
  • Chinese
  • French
  • German
  • Italian
  • Japanese
  • Korean
  • Spanish

Hi, everyone. Good afternoon, this is Dale Hopkinson, Sales Engineer at SafeNet. At the top of the hour, it looks like a good time for us to get started. So first of all, I'd like to thank everyone for attending today. I see a few people still joining-- I'm looking at names, and I can see quite some names I recognize, and I see some who have attended most of the other sessions. So this is our fourth and final Ask the Expert session of 2013. So in this session we're going to be talking about virtualization-- what is virtualization, for those who may not be too familiar. I will talk about virtualization and the effect it has with software licensing, and some pitfalls that you may have to overcome. And then ultimately looking at how you can possibly build a successful strategy for licensing in a virtual environment. But just before we get under way, a few housekeeping items-- everyone is on mute, just so the clarity of the call can be much nicer. If you do have any questions, feel free at any time to write that in the chat or the question area, and I have the full visibility into that. We do have a dedicated Q&A session toward the end, so we'll get the questions in. If by chance the time elapses before I get to all the questions, this would be a good avenue for us to follow up with you. Just for a sanity check-- if you're hearing me, can a few people type into the chat box, you are hearing me correctly? Just want to make sure audio is good before we continue on. I don't see anyone typing, that means-- [INAUDIBLE] just respond also in the. Chat if I can be heard, can someone just give a quick sound check before the time elapses-- if one could make sure I'm heard correctly? All right. OK, perfect. Thank you all for that. So let's get started. On today's agenda, as I mentioned, we'll sort of look at virtualization today. We'll look at the evolution of virtualization-- where it's come from, and where the analysts say that the market is headed with virtualization. We'll take a look at also helping you to understand your users, your customers' mindsets on why they are going virtual. A lot of times we hear from our customers, the software vendors, they want to run our software on a virtual machine. We wanted to take a step into that and help you to understand their mindset for going virtual. And it's probably going to align also with the reasons many of you are beginning to use virtual environments and virtual technologies. As I mentioned, we'll look into exactly what virtualization and licensing means. Maybe some pitfalls that we've seen, how people have developed strategies and ultimately ending up with strategies that you can begin to use or ask us more about, and how to leverage these sorts of technologies and know that you're probably licensing your software. We'll look at the key takeaways for you from this particular session, and then as I mentioned, I'll open it up for any Q&A. Again, for those of you who are just joining, everyone is on mute. And at any point in time, if you do have a question, you can feel free to type that into the chat area, and I will get a chance to look at that and answer your question during next session. So without further ado, let's get started. So essentially, virtualization 101. What exactly is virtualization? Essentially virtualization is the practice of creating a virtual version of what you buy, a machine or any resource, and then really operating that virtual version on the physical host machine. It makes it easier to change business conditions, strategies, it makes it much easier to do a lot of things. Let's take a look into exactly where that has evolved from. So virtualization, the whole virtual technology, kind of really came out in a more commercialized way in 2005, if you look at where the mouse is. Virtualization 1.0 really was just about server consolidation. It really was just more using test and development, a lot of internal type of technologies, testing being done there. And it really was about CAPEX savings. Then we looked at 2008, and what this coined is Virtualization 2.0. We really begin to see a lot more production systems and production workloads occurring with virtualization. One thing that came of it was VM mobility, being able to move a virtual image within the same environment. Then we also began to see-- this is just market wise, not really pertaining to licensing-- a number of extended hypervisor use cases, number of different use cases warranting now the use of virtualization technology. Now we look at 2013 and beyond, is what is coined by IDC in 2011 as Virtualization 3.0. It's really about fully virtualized data centers, has the moniker of both internal and external cloud-- really the adaptive intelligent infrastructure. We're seeing a lot of really service oriented-- being able to offer IT as a service. And now it's moving now to really OPEX savings. Just wanted to share a quote-- from IDC. They mention Virtualization Solutions market is really expected to grow. What this is saying to you is, if you're not already having to answer questions or find ways to license in a virtual environment, this is definitely one area, you're going to have to think about how you're going to develop a good strategy to enable your customers. So I want to talk about just quickly the dimensions of virtualization. There, virtualization again, as I mentioned, is the practice of creating a virtual version of a device, machine, or resource. It can take on many, many different forms. That can be from server, to network, to even broader domain, hardware and desktop virtualization, what you see-- sort of the main categories of virtualization there. And then there's some additional data around that. As new dimensions of virtualization arises, the challenges IT management face increase-- the complexities they have. They make decisions based on a wide range of issues about storage, architecture design, and performance. That's some of what begins to drive them to virtualize environments. So when we're looking at, as I mentioned, the dimensions of that-- one of the top dimensions that we see now being virtualized-- is the data center. Traditional data centers, rather, can no longer manage today's demands. And really it's being seen as software designed data centers are considered by many to be the next step in evolution of virtualization and even cloud computing. I really provide solutions to support both legacy enterprise solution, and also new cloud computing services moving forward. Let me think about those core components-- they include things like server, and network, and storage virtualization. Probably storage is going to have the biggest impact, as I mentioned before in the previous slide, with all that data that's going to be moved. So in a nutshell-- again didn't want to go too crazy just talking about virtualization. I want to group a few things in a few buckets to help you to understand your customer's mindset. Again, when you get that call, that question, does your software-- you as the ISV, the software publishers-- does your software support virtual machine? Here's the mindset of some of your customers, why they're moving to virtual type environment. Of course, cost and time, right? It's cheaper than buying physical machines-- reduces the IT operational workload. The quickest thing with virtual machines is provisioning. If you were to provision a traditional desktop, it may take some time. You can do that in a few minutes now with virtual technology. You have a base image, and you load that for a new user, a new employee can think of. Another reason that sort of drives-- again, I'm going back to your customer's mindset-- going to virtualization now. Think about compliance. The IT, they really have some say, the benefit or the burden of compliance, making sure they have the right laptops, or the right devices, in the right location, the right [? counts ?] and so on. They will turn to some of these virtual technologies-- they are compliant. They help you with the compliance modules, there's an easier way to do check reports for compliance. So it's a tremendous help for IT. Another reason is reliability. When you think about that in the terms of disaster recovery and failover recovery, that's much more faster now and seamless with virtual technologies. Being able to bring up a server that crashed or that fails. You no longer have to have the hot swaps where you have to reinstall something. Again, rolling back to an image-- really improves that time. Much more reliable there. So those are some of the things-- again, moving on, when we look at increased flexibility, being able to configure certain departments. And you have a particular instance or environment up-- if you're doing testing, you can spin up and spin things down, much more flexible than you can with physical devices. Going green is one initiative, or going virtual, of course, with virtual environments, being able to consolidate physical components, you reduce power-- less equipment. And actually one interesting stat that was by Lawrence Berkeley-- he mentioned sometime earlier this year. He kind of predicted and said, if all the companies in LA went-- actually to save enough power, of all the LA companies, if they got rid of all the independent email and productivity services and moved them to the cloud. I don't know how true it is, but it was pretty interesting that he was able to come up with that. A real stat, saying how really critical this could be. And how critical it is now, one of the big things a lot of companies going green-- to research and decide then how virtualization can play a part in that also. And then ultimately, I mentioned the scalability. Really being able to automate and reduce the time of the infrastructure and complexity of infrastructure. Between those six initial points, those are really some of the mindset-- when your customers again ask that question, when your prospects ask that question-- do you support virtual machine or virtual environments? Probably one of those buckets they're going to fall into-- well, not fall into-- but one of those reasons driving them to use virtual machines. Likewise for yourself and certainly for those who begin to adopt and adapt to virtual technologies. So now that we've discussed in a sense, what is virtualization, why people are moving to it, why is it so popular-- let's take a look at something that sort of hits more to home from our aspect, virtualization and software licensing. So for those of you who-- probably selling software in the past two years you may have heard or you may have dealt with some of these type questions. So typically when we're asked about-- from our customers about supporting virtual machines, the questions, they fall into one of these two things. How do I as a software publisher, a software vendor, make sure that my revenue is protected in virtualization, meaning someone cannot just buy one copy of my software and clone it on a million different virtual machine instances. How can I be assured of that? And also, how can I enforce the compliance? Again, without constraining the end-user. If they do clone it, how do I prevent that clone from running or staying compliant if I allow them to maybe clone, or have about ten instances in the environment. How do I support that? How do I enable the users to do those processes they need to with virtual machines, but then still continue to support that? When we look at being able to license-- or developing a licensing strategy from virtual environments-- here's really the four types of things you can do from a strategy approach. So starting from the left end of the arrow, deny and detect. That's one possible way, and we'll go a bit in depth on these four points on the next few slides. Deny and detect, that's one. Another one is also by using a physical dongle for those who use and license with USB today. Another one, of course, is fingerprinting with the software licensing. So it's possible to use that type of mechanism. And then also we will explore now cloud connected, sort of innovative and flexible type licensing. Let's take a look at exactly what this all means. So as I mentioned, one of the early-- if you think back on the slide, around 2005 or so when virtual environments really began to come up-- one of the first reactive things as software publishers was really to deny and to detect, or detect and deny, rather. Here was a strategy when you just simply wanted to detect the environment that your software was running in. If it was running inside of a virtual image, or a virtual environment, you wanted to deny the use of that. From the implementation standpoint, that was really quick and easy to implement. Our technologies, for those who are using our technologies, offered you the ability to do that. That was really a fairly common approach at the time. A lot of software vendors reacted to virtualization-- at that time, early 2005 or so, virtualization was more of a fad. And then everyone said, Oh, this is going to go away. And then the big thing was, I really want to stop users from running in virtual machines. Because I don't want someone to clone my application and to game the system. The problem there, you know, VM became more widespread, and even today, it's really not an accepted method to be able to-- not an accepted strategy. Another type of strategy was by using the actual physical dongle. Or a dongle type technology. Again, peace of mind there-- most secure. You're able to have a variant of either local or network type license models. You did have the cost of the hardware dongle, and again that's something we supported. One of the pitfalls there is virtual machine environment-- really VMware is the only provider that allows USB pass through, so VMware is the only one that natively allows the USB to work in the environment. We've had some issues and then you have also run into them too. If someone is using, like, Xen or QEMU or Microsoft Hyper-V, or any other provider, there was no USB. They didn't support it. There was really some ad-hoc solutions by using AnywhereUSB, USB Anywhere. And I see some people typing into the chat, saying, yeah, we ran into those problems. We used AnywhereUSB for us. While that did work-- the customer experienced-- they had to go through a period of maybe downtime, or a period of trying to work through and understand how to get it to work in that particular environment. Again, that's something that works today, but maybe it's not the right strategy for you. Another potential way to sort of build your VM strategy is really not by using a software licensing. So the fingerprint sort of licensing, one benefit you have there, is you can do a lot of things electronically, the delivery of the license, the activation of the license. You're able to reduce the cost of the hardware dongle. And we really saw a lot of ISVs or software publishers began to use the software license, binding to the virtual image itself. While that's possible, there are some opportunities for spoofing that, if someone was to go to a certain extent-- it is possible maybe to spoof that or clone the virtual image, and have the license still working. To prevent that, you would need to do some additional work. It is preventable, but not bulletproof. One of the big things, though, in the process of live migration-- live migration, for those who are not too familiar-- is if you have an environment, let's say, and ten virtual images. You want to move one virtual image from one machine to another, but in the same environment. That's something that license managers don't really support, because of course if you move it from one device to another, you're going to have a new fingerprint, so the license is going to break there. In regard to that VM live migration, that's something we're beginning to support, and now our next major release supports that. Again, that's just in the instance where your users, they want to be able to move one VM from one physical device to another physical device, from host one to host two, in the same physical environment. And if you're interested in that, feel free to ask for some questions. We can talk further. Now what I've covered already really focuses on traditional solutions, where there's hardware base, clone detection, VM detection, network license mode. Don't really ensure for security in a virtual license environment, but they give a way to work, and to develop a sufficient strategy. I'd like to actually introduce a solution, and the first solution in the industry to solve these virtualization licensing issues. Let's take a look at something here. What we call cloud license. What I mean there is really sentinel cloud. It's sort of a connected license, as you can see from the picture there. What you essentially do is you place the license and the license manager outside of the end-user network, and the license can be duplicated or used without your knowledge. So by moving the license outside of the network-- you can see here the mini architechture diagram-- it doesn't matter what they're using. You can decide to license the individual VM, you can decide to license the actual VM server or the actual hard machine or even in a data center, right? And that can represent the site. A number of things you can do that we'll explore in the next few slides. But of course, with this way, you gain benefit of two things, or a few things. The license is hosted in the cloud, this is the first in the industry. From your customer's point of view, they don't have to worry about node locking, which was, of course, the software license I just mentioned in the previous slide. It would be locked to a particular node-- whether that node is again in the diagram that can be the individual VM has a node, the VM server, or even that hard machine. There's no locking. So they'd be able to move the instance, or the node or whatever you like-- able to move that without any additional burden or additional steps from the customer's point of view to maintain that. In a sense you're doing something like a concurrent license, [? on ?] a distinct [? team ?], I mentioned before, where you may be allowed 10 virtual machines. That concurrent is actually controlled and handled up on a sort of cloud-based server. I know some of you may be talking about if you always have to require a connection, all of that, I see some of those questions coming in, we'll definitely get a chance to answer that Just want to take a sort of step into what that cloud-based licensing would look like. First, this whole moniker of cloud-connected, exactly what is cloud-connected? So, I guess one of the questions that came in I can answer now. This does not mean that where your software is, is always connected to our cloud-based license manager. It does not have to be always connected. And we can talk more about that as we move on in the presentation today. So it's actually a few things about cloud-connected license. First, a license is locked to a user, or anything you identify, and not necessarily a physical node. It can be tied to a user, it can be tied to a particular environment or site. This really allows you to-- the user to be able to use that license without having to be concerned with, am I always going to act as if I'm this physical machine? Am I locking to a user? You really begin now to provide or ensure that you have legitimate use of the license. But not only use of the license. You as the software publisher-- you actually have the full control of how many licenses are running, the license terms, the license models, and you can even get some sort of usage information-- I'm going to talk further about that. But in a nutshell-- we'll take a look at first the client side. That architecturally and sort of implementation-wise is very similar to what we have today. So you have your application, the API, and we have a small, lightweight runtime. This of course would be-- this could depend if this client machine is something you offer as a service or if this is actually on the premise of the user. In this case, it's on the premise of the user, which is perfectly fine. So on the user side, of course, you have installation, and they register the license. So as far as the license registration, there would be a connection, minimally at least one time to our cloud-based license manager. And then there's a verification that happens. And the user essentially registers their right to use that machine. And the runtime of the local license manager essentially pulls down the license, the limit of the [INAUDIBLE] license configuration. And from that point in time, the license is being used. It's being kept track of on the cloud, meaning that the cloud always confirms the limits, and if there's any upping to the license, you can actually remote control the license. You can update a user's license, and now the next time they connect to the server-- which again, that connection point in time is something you can configure-- they would actually get the new update of the license. One of the benefits there, you can think about traditional today, If you have a license update, the user has to do some type of reactivation, or they have to install another license key or another license file or something like that. We actually have moved that piece of it. It actually does-- a [INAUDIBLE] essentially is asked, is there an update for this particular license? If yes, it [? sends ?] up an update oh behalf of the user. Another thing that's also possible, just showing up on another model. There really is a commuter license. So in a sense of virtualization-- you can think of, we have these two physical machines, let's say these two physical machines are in a zone that's always connected, which is fine. So they can access the license server in the cloud automatically, all the time. But this laptop here, is really a virtual instance. That virtual instance can actually connect to the cloud server one time, and it can actually commute a license, or check out a license from the cloud. And once it's sort of checked out, as I mentioned before, we can see a graphical look at it. [? Based ?] only for that, that VM environment or VM instance to always contain the license. And again, that concurrency is being controlled by another cloud. So these two physical machines, again they can access it. There's only two in the pool, essentially. And we control that there and the concurrency is decremented by x number of licenses used. Now of course, should the virtual environment need to return that license, that license can be returned. So in a sense, one strategy that we've seen a lot of temporary enabling or temporary portability of the license from the cloud. By doing that, now I'm free to spin up and spin down different instances of my virtual environment. I don't need to be always connected, I don't have to transfer licenses from one VM environment to another. I can control that all externally. In the traditional sense-- if this was a virtual environment, I would have to go and activate, and that license would be bound to this machine and that machine only. I wouldn't have the ability, as I just showed, really have a clean user experience. So yeah, there's one thing I didn't mention. Again, that reclaiming of the license can do a number of things, and typically what we get asked here in that type of scenario is, If I check the license out from the cloud, which is OK, I connected and checked it out. But what if my virtual machine environment, before I was able to check it back into the cloud, my virtual machine environment went away-- for whatever reason, it went away. That's fine, the reclaim of the license back on the cloud server can happen a number of ways. It can be offline. So you can actually say that this license can only be checked out for 30 days, 50 days, a year, two years-- you can define that. Or you can even define that, or have that license reclaim automatically. Or even from the cloud side, you can end that session and replenish the pool from the cloud-based service side. A number of ways to meet that type of situation, of course the best way would be dependent on what works best for you and your use case. We're sort of looking at now-- we spoke just mainly in the context of virtualization, but I did just want to share a few other instances or a few other benefits, rather, of cloud-connected license. We're speaking in the context today of just virtualization-- how you can sort of meet those needs by moving the licensing outside of the virtual environment, and not having to be concerned with fingerprint and cloning, and those type of things. But here are some other benefits of why some of our customers leverage our solutions. I'll work from left to right-- animation was really busy, marketing and animation, they had fun. I'll work from left to right. One of the things with cloud-connected license-- and again, the license is cloud-connected, it's not saying that your application must be cloud-connected. In the previous example I showed that your application was on the premise of the end-user, typical install-- but we just simply moved the infrastructure of licensing. I just wanted to clarify that point. So one of the benefits, again with the cloud-connected licensing, is you can actually have usage information. So today, when you have your licensing, whether it's hardware or software, you're only able to know if someone activated license, or the quantity that they immediately received, or you sold. You don't have the real ability or the real benefit of knowing how the application is being used. Is a particular function or method being used, more so than others? So from a product management standpoint, understanding that usually you can do a number of things and you can decide, oh, that print functionality that I thought was so great, no one's using it. You can make decisions based on that. From the customer's point of view, you can enable them to-- pay as you go licensing, pay as you go or grow. Think of your utility bill. You can use as much as you want, they love it, the more you use, they bill you according to what you use. This is exactly what the license is doing. So we think back on the previous slide where the on-premise application connects to the cloud license server. When it connects to the license server, if you decide to track usage, you can pass that usage. And again, you just can be used for monetization reasons, or just customer insight, which is the next bullet point. If you just simply want to understand more how your customers are using the application, a lot of insight you can gain there. Of course, allocating of investment resources-- or development resources. Another key thing is understanding from the product management. Maybe there's certain packages and bundles that we can begin to deploy at different price points, et cetera. You pretty much understand the inside of how the customers use your application. Another point we are moving up-- sort of user-centric licensing. Sort of follow-me licensing. So as I mentioned before, in the cloud-based license, it's not locked to a node or a device like it would be today with traditional licensing. You're able, from a user's point of view, of course, depending on the type of solution you have, they can access that solution from a desktop, a mobile device, a tablet, smartphone, laptop. It doesn't matter where they access it from. The license, again, lives in the cloud, and as long as they can access that license at least minimum of one time. Of course, architecture of the application supports it being able to move from one device to another. That's fine also. And in the context of the virtual that we're speaking about today, being able to move the license from virtual machine environment to virtual machine instances. A lot of our customers, they have testing software. A lot of their software deployed in test environments that gets spun up and spun down relatively quickly. Being able to support that type of environment would really-- you really need to have some type of portable mechanism. You don't want to lock to environment A, and they need to blow away environment A and set up environment B in about four or five hours. So being able to have the license follow the VM in a manner that you know that cloning can't occur, and it doesn't require a fingerprint. Again, that's another benefit of cloud-connected license. Another benefit, moving down, didn't really speak too much on the back end, but a common-- the same deployment strategy. Whether that license is always connected, so if you deliver something as a cloud service, where of course you require the internet, or you deliver something on premise, it's the same back end. It doesn't matter where you're deploying to, how you're deploying-- you use the same method, the same process, the same tools. And of course we can spend a day just on those benefits alone. One of the great benefits that some of our customers really enjoy is what we call remote control licensing. I kind of alluded to it a bit earlier. But what that essentially means is from the ISVs, from your point of view-- of course, you have the proper right and authorization to go into the back end-- you can actually alter or increase, decrease, even freeze the limit on a license. So for example, if you had some type of software that went into virtual environment-- let's say that you enabled three different virtual instances to run at the same time. Customer calls up and says, hey, we need to have a fourth environment or instance, for some point in time. After you come to some agreement, there's no need to send a new product key or to do activation, or another dongle, or anything like that. You can simply update their rights within the system and have them just reconnect to pull that right. So you can actually remote control that license. And that's just one way of doing it, of course you can go the other way. If you're doing pay as you go and someone has not been paying, you can actually freeze the licensing. So the next time they check their license, they're not allowed to run, or not valid. And one of the last additional benefit is really the licensing platform itself. If you ever have a service, you can think about today the infrastructure that you would need to have carved out for the licensing. Whether it's a software activation type model, you would have to have some server internally, have that server exposed to the internet, proper security rules, put in firewalls, [INAUDIBLE]. The platform itself is delivered as a service. You can think of your ERP, CRM, same kind of concept. It's [INAUDIBLE] service, removes the IT burden from you managing that, helps you get to market much quicker, and less burden on internal infrastructure. So it's a bit more-- specifically on the pay-as-you-grow type licensing. Some things we see here-- so pay-as-you-grow that's usage-based-- it can be done on a number of things. Usage can be simply how many number of times a feature was used, how many times someone clicked that button. It can be the amount of data stored, or the amount of transacted data, or the amount of processing times. We see a lot of questions, and a lot of unique strategies now on what usage is-- really a custom metric that makes sense of the business that you can monetize on. We have one of our customers-- they have a solution that moves a lot of data, high-speed transfer, they have an algorithm. Some of their customers are Netflix, and Comcast, and Hollywood movie studios. So they move tons of data out with that algorithm really fast. They offer their solution as a cloud service. And from their point of view, you can spin off as many instances as you want. They don't care. They want to bill you on the actual data that [? you push ?] [? through the byte. ?] So if you have 10 instances and you move a terabyte, they bill you on a terabyte. If you have one instance, then you move a gig, they bill you on that gig. Many different ways you can do usage-- you have to understand what sort of makes sense, which really gives you as a publisher now a lot of flexibility and charging more or less, depending on how your customer uses software. And that maybe could give you a competitive edge. We've had a number of customers saying, hey, they were able to enter a different market. Less barriers-- really easier they really become more competitive. And you can benefit. It really eliminates shelfware-- so any unused software. They essentially pay for exactly what they use. There's no restrictions over instances of VM in that case. The virtual machine, if you allow them to use unlimited, you have the ability to track that and to decide how you want to build and monetize based on that. Again, going a bit deeper as I mentioned into customer insight-- really helps just to understand what to do in the future. How to improve relationships with customers, how to better upsell and cross-sell, really knowing where to invest. For your customer, you can also expose that usage, and you can share with them what's been purchased, what's been deployed, where the actual license-- and where they are. And that's one of the big things IT admins struggle with, not knowing exactly where the actual license software is. Depending on how granular you want to get, ensure that usage you can see who is using our user software when, how long, et cetera. Even begin to differentiate what environments a particular software and solution being used. As I mentioned, the "follow me" type licensing, going a bit in depth. Being able to have the license-- license mobility. Use it from any device, in one sense, or from any VM environment and metacontext of today's presentation. Not just necessarily locking it to what machine, but locking it to who. I sold to a particular company, they can use-- as long as they're not using more than a particular limit, that's fine. Or again, giving them the unlimited type limit, but being able to track that usage. So I mention again, common back-end really is key here. You don't want to have to gain the benefit of cloud-based, cloud-center, and cloud-based licensing. You probably don't want to have to use the different systems to deploy on premise and cloud-based. There's different back-end process, different business process, deployment process, and from the development point of view, different API. Probably don't want to do that. So again, there's a benefit that we offer. Being able to do that from the same API, same development efforts, same back office type process. As I mentioned with the remote control licensing, I only spoke about really updating the license, but you have instant licensing provision. Once that likelihood provision, there's no time-- you don't have to send the code to the user, the user activates the code. They're sent already to get that license from the cloud-connected fashion, as I mentioned. Some of the things, again with remote control, you can call the subscription, renew the subscription, update the subscription-- all of that can happen from the same licensing object. There's no need to create a different licensing object or entitlement to do that. Hence, not having to give out a different subset of keys for customers to activate. And as I mentioned, the licensing, the platform itself as a service. You being able to leverage less infrastructure, not having to worry about internal machine labor in your own virtual environments [? getting ?] to spin up to have that working. So as we come to sort of an end, before we get to some of the questions I see flashing at me there-- some key takeaways that I wanted to share. Again for those of you who are on, it's very, very difficult to go really granular, and we have only an hour. This is a topic we sometimes have four-hour meetings with our prospects and customers about. But of course, if you do want more information that you have before, feel free to reach out to us and your sales rep. But key information from today is, just about everyone today wants to leverage the benefits of going virtual, and we spoke about a few of the common benefits. So the cloud itself now, really software driven data centers is really becoming a strong enabler for cloud and cloud computing. If it hasn't already, this is really going to directly affect how your software is possibly prices, definitely licensed, that deploy on VMs, because they're going to become hard to control, essentially A lot of the VM processes-- live, for example, live migration, lot of VM mobility-- it's going to become a bit harder to control the license inside of a VM container itself. You really have to have a solution these days that you allow to run on virtualized machines. This can really be a competitive track-- not competitive, but if your competitor offers it and you don't, it's going to be a tough sale for you. But there's very few softwares today that, again, unlike the 2005 type of strategy, deny and detect, it's really not common today to deny and detect, and it's really not feasible today. Many of your users are going to have virtual environments. And lastly Sentinel Cloud really changes-- is disrupting licensing and virtual environment. Being able to move the licensing outside of that virtual environment, and not forcing activation or buying into a particular node, or with fingerprints. It's very difficult to get them to use a unique fingerprint in the VM [? instance. ?] Not impossible, but difficult. By moving a license outside of that again, you remove the whole burden of fingerprinting, VM mobility, live migration, being able to swap licensing from one VM to another. You make those processes much easier, and not just the process, but really the end-user experience behind it. Again, tons of ways that you can decide to do things differently on that. One possible thing is usage-- usage-based licensing. So again, as opposed to saying up-front, we're only going to sell the capabilities to use five VM instances. You sell as use however you like, and we'll get the usage, and we'll send you some sort of a bill, at a particular period. So those are really the key things that we've seen resonate, and we wanted to present on this webinar today. I think now would be a good time for me to look at this icon that's flashing at me crazily with all these questions, and get to some of them. Again, seems like we have about 14 minutes to go. And as always, the questions that I'm unable to get to, I will be able to follow up with you. One second here, getting down to some of the questions. So, great question. So someone asked, how can you stop a commuted client from being cloned. Of course, there are some technologies in the commuted client itself. So one, the license that gets shared on the-- well, there are even a number of strategies with that. One, you can set a period to say, check the cloud-connected server every hour, every-- some sort of time-frame. One is this thing we don't care about, cloning. You can do them wherever, and we're going to track that usage. So one, you have the insight on where it's being used, that's one. Another strategy, if you were not going that way, and you want to sort of prevent that license from being cloned-- there are some underlying technology-- so when the license is commuted, there is some encryption going on, and it's being tied to something-- not fingerprint, but a unique identifier of that particular machine. That information is encrypted with AES, so that is prevented essentially with encryption of fingerprint, in that type of format. So another question is we essentially have the dongles today, how do we help our customers migrate to other solutions, especially this new type of cloud-connected solution? OK, excellent question. There's actually a very nice forward moving path on the solution itself. The ability to continue with this-- well, depending if you have-- so one particular question was we have NetHASP. Depending on the API version you're using, there may be minimal changes on the API, or depending on the version, there may be no change to the API. So one, it depends on the version that you have, but we have a number of things you can do. There are migration guys, there are services that we offer to help move our customers. I would say follow up with us. I could answer probably more specifically in terms of what you have-- would be able to say a bit more specifically depending on your version. So one other question was, we use the encryption decryption capabilities of the HLSL keys. This gives us significant additional protection and security. Is there an equivalent capability with cloud licensing? Yep, so you can also have the ability. So the only difference is the license has moved location. Set the [INAUDIBLE] so you can still continue to use those Encrypt, Decrypt function. If you have custom strings or different points in your application you wanted to encrypt and decrypt, that's totally fine. Much of the API type of flow is not going to change. So you still have the ability to do that. So we have one question, we recently rewrote all of our CRM, ERP software plugins to eliminate the use of EMS in favor of the license generated API. This saved us a significant amount of code customizations, and these systems, I expect will have maintenance in the future. Is there a license generation API for the cloud, I really don't want to be forced to use the back-end system. Yep, that's fine also. You will have the ability to-- so what I showed I saw the license generation, there was one slide. There's two ways to do it, there's a utility that we offer, and there's also sufficient web services if you want to use that and automate without using our tool, that's fine also. So yes, you do have the ability to not use our piece, there, the license generation, if you did not want to. So another question, someone says, so without fingerprint, how does Sentinel Cloud ensure that every user is licensed to do so? Excellent question. So in one of the slides I mentioned we are not in fact locked to a fingerprint, you're locking to a user. So there's an authorization that happens between a quote, unquote, user. If this user is a physical person, or in any site, or anything you decide as the thing you want the license. It can be a site, it can be a user, it can be a company, et cetera. It's just simply a unique identifier that you use-- that sort of map against Sentinel Cloud. So you can think of, for example, if you have a credential-- your username, password-- some of that username, password information would be verified against Sentinel Cloud. If it matches, what was previously used when you created that user's entity? The license is a little hard to be used. As part of the using of licensing, you can also see who used it, where the use occurred, again if it looks like those credentials that you once gave out-- they're being used in a way you didn't intend them to be used-- again with remote control type functionality, you have the ability to turn the license off, or forward the license. But again, the authorization is based not on fingerprint, but is based on some unique identifier that you define, associated to the user. So another question here is, let me find it, how does cloud-based licensing work when a customer's environment is a combination of VM and non-VM machine? Excellent. Great question, and the answer is simple with this one. It works the same. A cloud-based license doesn't care if the license is going to be used from a VM or a physical machine. The only thing the cloud-based license needs to know is, do you have access, meaning access to use the license? Are you a valid user? And do I have licensing to give? Whether that license is going to be consumed on a VM or a non-VM machine, is initially irrelevant. If you did want to define-- you have a pool of licenses, these five licenses can be used on VM, the other five are non VM, you can also limit them. But by default, there is no need to specify between VM and non-VM. One way to do it is limiting how much of the license itself can be used, total. Or you can say, use any combination that you like to and being able to get the usage information, you can get the usage and you can sort of bill and monetize correctly. One question I see a few times-- Is the webinar available to view at a later time? Yes, this webinar is being recorded and you should receive a link sometime this week. It will be archived so you can share that with any of your colleagues. So someone's asked, we have time-based envelope keys on premises today. Can we replicate a security of the program on premise and track usage in the cloud? Yes, exactly. You could use the same type of protection methods you want to, that you do today with the envelope. And you can actually take that envelope on premise application, and use cloud-based licensing. That's very common, and that's perfectly fine. Of course, you don't want to degrade the security of your application just to gain the benefit of maybe usage-based tracking and licensing. So for sure, you can do that. Another question, if you acquire a cloud license and then disconnect from the cloud, how long can you continue to use the license while disconnected, before you are required to connect to the cloud for server verification? Is the time flexible? Yes, this time is flexible, it's something you can define. It can be up to five years. So you can say, connect every five years, connect every one hour, connect every one day. That's totally flexible, and you have the ability to control that. Someone asked, what happens if a customer's simply not allowed to connect to the cloud? That's fine. In that case, again you would develop your strategy. But the solution we are talking about here would really enable you to still do the traditional base type activation. You can have a license that just goes in. You can have something Sneakernet, a number of technologies to support that [? from the ?] solution. You, of course, will map that to your policy. For those customers who are not connected, do you give them licensing? Do you do paper licensing? If not, you want to get a license in, so the machine that-- your solution runs on, does not have to connect to the internet, you can also Sneakernet something in from another machine in that environment. So that's fine-- a number of strategies that you can make of it. But the technology would support that. Another question with VM cloning. So many of our clients get disabled due to cloning, because they're working in a VM environment. How can we avoid this? If I understand the question correctly, it sounds like the license that you're using today is sort of a detect and deny type. They get disabled due to cloning, because they work in a VM environment. So in this type of situation, you would be able to just continue using the license in a VM. There's no restriction based on if it's a virtual environment or not, that's OK. Another question, is API the same for on-premise as well as cloud? Yes, correct. So the only difference is if you have on-premise, the only difference is just the deployment type. That's something you can determine after implementation of the API. It's not dependent on one another. And there's another question came in, may I get a copy of this presentation? I believe the presentation should be available-- we can confirm that point after the call. I believe in times past we've given a link to the recording as well as the presentation. If I'm misspeaking I'll follow up and let you know. I see a few questions that pertain uniquely to custom implementation today. I'm not ignoring those, just don't want to get too nitty-gritty for your unique case. For those who have those questions that I did not address, please feel free to email me, and I will follow up accordingly with those questions. So everyone, this brings us to the hour time, the top of yet another hour. Time flies when you're talking about licensing and virtualization. I want to thank everyone for joining us today, and again the last Ask the Experts of 2014. I thank you so much for spending an hour with us today. I hope it was beneficial for you. If you have any additional questions or comments, please feel free to email me-- email us. Again, directly due to some of the comments we've received, we've had particular sessions based on the requests that we had. So continue to share those requests. Thank you for joining again-- everyone have a good week, great weekend, and an excellent holidays. Bye now.

While network virtualization helps enterprises to reduce costs, it also poses a challenge for software producers, who have traditionally relied on the ability to bind licenses to something physical in order to control access to their software. Software producers are in need of new tools to track, control and manage the use of their applications when deployed in highly advanced virtual networks. Presented by Dale Hopkinson, Sales Engineer, SafeNet

View this webcast to:

- Learn about the risks associated with software deployment in virtual environments
- Find out about industry best practices for licensing in virtual environments - Past, Present and Future
- Discover how SafeNet’s cloud-based solution will eliminate all dependency on node locking when licensing in virtual networks.

Post a Comment

  • We reserve the right to delete any comments that we feel are disruptive.