ARCast.net - SaaS @ Work - Flatburger Architecture Overview

[Music begins]

Ron Jacobs: Hey this is Ron Jacobs and I'm coming back to you with another episode of ARCast TV and let's just say that tonight I'm a little jet-lagged or maybe it's the opposite of jet-lagged. I'm having some trouble sleeping when I ought to be. So, nothing like a little warm milk [sounds of sipping] but I thought I might as well get some work done while I'm up so, tonight I'm going to share with you the story of Josh McWilliam, the CEO of FlatBurger. We had a nice little chat in Las Vegas about how FlatBurger has implemented this very interesting kind of middleware support for module developers. A lot of cool stuff there for people who are interested in DotNetNuke and many other modular software platforms. So, let's welcome Josh McWilliam.


[music ends]


Hey this is Ron Jacobs back at the ModSoftCon 2006 in Las Vegas and I'm joined now by Josh McWilliams of FlatBurger. Hey Josh, now what's your role at FlatBurger?

Josh McWilliam: Well I'm the CTO and co-founder along with Bill.


Ron: Wow. So you're kind of, it sounds like a big shot.

Josh: No, we've been working together for quite a while now. We started this several months ago and we've been working hard to get it together. It's finally nice to see it actually happening.


Ron: So let's talk a little bit about some of the technical underpinnings about how this stuff all works. Now the way you were talking to me about this earlier, that you offer a number of services to the module developer.

Josh: That's right.


Ron: Probably the first one that people care a lot about maybe is that IP protection. Yeah I can run obfuscator tools on my code and give people assemblies and what not but that's not 100% secure. I mean what are you guys doing to provide the IP protection?

Josh: Well, we provide a developer portal which is essentially just a website where developers can go and upload their software. Once that happens, we take their software, analyze their code and their assemblies, and present to them a list of all of the different objects and methods inside their code. They can then select, right down to the method level, what parts of their code they want to protect.


When they hit the protect button, it will go in and, unlike obfuscation which does a limited amount of renaming of methods and renaming of the inputs to those methods, it uses a proprietary technology to rename, well beyond every object and piece of that code, as well as all of the actual code inside the method is transferred and transformed, as we call it, into our own proprietary sort of format that's encrypted and stored in a new protected assembly.


Ron: So, that sounds a little bit scary like you know, is it going to mess up my code, is it going to make it run slow, anything like that?

Josh: No, absolutely not. The protected method that can be installed just like any sort of module and our, sort of, is our secure LM virtual machine technology that gets packaged with that module, does the transformation process and it runs on a very base level that is pretty much linear to CPU speed.


Ron: So I guess the idea then is -- OK I give you my code, you protect it. Now, you know, so then you actually do the builds so that you end up with the DLLs and what not that get distributed. Now what I care about is that this web host who is running my code on their server is paying for it. You're going to make sure that happens?

Josh: Absolutely. Because the next step to the service that we offer is the licensing. A big important piece is that the code protection really is, the licensing is, enforced by the cutting-edge code protection. What a developer can then do is select the different pieces of their code that they protected and assign licensing and billing features to it supporting anything from a fixed price perpetual license all the way to a software-as-a-service type monthly or recurring billing as well as usage-based licensing.


Ron: So do I have to write something special in my code to manage, say if I wanted to build this monthly, do I have to write something in my code to manage monthly billing or do you guys take care of that?

Josh: Nope, nope, that's actually one of the unique things about our technology is that all a developer has to do is upload their applications. We then analyze using the MSIO the different aspects of the code, they select what they want to protect, and it's transformed, recompiled, done.


Ron: So the host who is running this module, they have to install some of your bits for this thing to execute in their environment, right?

Josh: Yes, but unlike a lot of other license management technologies that might have to get installed like at the web server level, our technology is packaged and bundled in with the module.


Ron: Oh, OK.

Josh: So it's installed via the standard installation process of DotNetNuke.


Ron: So to the host it just looks like another module for DotNetNuke.

Josh: No change whatsoever.


Ron: Oh, OK. So then it's not like I have to go beg hosts please, please put this thing on there. It's not a big deal.

Josh: That's right. It's very easy.


Ron: So now somehow your stuff is going to have to call back from the host, call back to you guys, so that, you know, my module is being used by this customer and for the billing and what not.

Josh: That's right. What happens when a module gets installed as soon as it is added to a page and used for the first time, the user will get prompted for an activation key. If they have that activation key whether the module developer emailed it to them or they obtained it any other way, they enter that, click activate, it's done. That actually stores the activation key locally, as well as transmits the activation information back to the central FlatBurger system.


Ron: So it's just like a web service call or something like that?

Josh: Exactly.


Ron: So there's no big deal about open special ports on the firewall for the host or anything like that?

Josh: The entire licensing system operates over standard HTTP.


Ron: Wow, very cool; yeah, interesting. Now have you had any resistance from hosts about any of this kind of stuff?

Josh: Well, not yet. This sort of really represents the launch of the product. There were several hosts here. Over the last four months, I mean we've been working very closely with hosts, getting their feedback, testing in different hosting environments that are common to DotNetNuke and so.


Ron: So when it comes to, OK, as a developer, right, if I'm thinking about using your system, I'm going to give up a little bit of the process that I would normally do like the build, distribution of the bit. You're going to handle that now. So let's say I fix a bug in my system. I go, "Oops there was a bug. I got to fix it." So how does that work? I upload my code. You do the build and you push out the patch and that sort of thing as well?

Josh: Well the developer has, we're really trying not to change the process or force the change of process on the developer. The developer still has the ability to take and download the new protected application, the new protected package, and distribute it the same way they do currently. Just now it's protected. We are, in addition to that, offering additional distribution channels to give them more sales but we are not forcing them to fundamentally change.


Ron: Oh, OK, so I can post the bits on my website?

Josh: Absolutely and allow people to download it because the nice thing -- all the protection and licensing is built into that package. So we're really enabling the developer to bring the control of the billing and the licensing back to them versus say force it to be downloaded from an exterior marketplace. By just allowing any random person, really, to download that protected package from their site, because the licensing is built directly into that, they can then install it and that is not a concern, because as soon as they try to use it, they will be prompted for an activation key. If they don't have one, they can click to get one at which point they will be presented with all of the different licensing options -- do they want to pay $50 for the module, do they want to pay $2 per month, however the developer chose to license their module. They select it, enter their billing information, and get the activation key, done.


Ron: Do you even support things like a trial like you can try this free for 30 days?

Josh: Absolutely. In fact, that's a thing we're promoting with a lot of the developers because I think it can help to improve the trust.


Ron: Well, you know, when it comes to stuff like this, I just refuse to buy anything unless I can try it first because there's so many pieces of really cruddy software out there that unless you can try and see that it works, you don't want to buy it.

Josh: Right and implementing that type of thing right now for a lot of these guys is a challenge because there are a lot of licensing systems out there. There's obfuscation that people use. But as we said, the protection of other methods are limited and the licensing options available are sometimes expensive, hard to implement, hard to manage, which is a challenge for a lot of these guys.


Ron: I wrote my own thing like this 20 years ago.

Josh: And some do.


Ron: Of course, the thing I did wouldn't work now because, anyway, the way I did it, Windows wouldn't go for that but that was in the old DOS days. We got away with it then. [laughs] So it sounds like then that it's a pretty painless process for a developer just to take this step and go like, "You know technically there's not a lot for me to learn about working with you guys other than this portal and marking my pieces of my code for what I want to charge for."

Josh: Right that's how we've tried to make it and to allow them a lot of the abilities to say, some do have an alternate license mechanism, but many of them are limited in the different type of billing and licensing options they enable. We offer software-as-a-service; usage based pricing, as we said, the single perpetual license, billing. Really all of that; we allow the license to be locked to the machine level, to the website level, and we're even going down to the domain and virtual directory level.


Ron: Oh, interesting. So that would be an important one for people who are doing multi-tenancy, a lot of websites on one server and things like that.

Josh: Right and that's all of those flexible options, those powerful options, that are really hard to replicate.


Ron: So it sounds like, just based on what you have describe to me so far, that it would be easy to take and apply this technology to something else like SharePoint or CommunityServer or something like that. You didn't have to have some customized version of DotNetNuke to make this work right?

Josh: This requires absolutely no change to DotNetNuke whatsoever. We didn't want to go into that whole forking bit at all and the fundamental technology is built currently around any.NET assembly, version 1.1 or 2.0. The current developer portal that we offer does have some custom kind of wrapper around it to deal with the unique characteristics of the DotNetNuke from the packaging and things from that standpoint but it's easily added. We can easily add to the technology to incorporate SharePoint or any other sort of modular type piece of software.


Ron: Very interesting. Now a lot of people probably imagine this being used in public facing websites but I'm thinking well maybe inside an intranet organization, you know, people are using SharePoint on the intranet, they find some cool little module they want to use, pay their five bucks a month or whatever. The only requirement would be that that server is able to make an outbound call to you guys to notify about usage.

Josh: Really that is a requirement if a developer wants to take advantage of some of the management tools that we offer.


Ron: OK.

Josh: One of the advantages of having all the licensing information back in one place is that we can enable the developer to run reports, too see licenses, to activate, to deactivate. Really it's a full management console. In addition to that we're planning on adding advanced analytical and reporting options to that to really allow them to optimize. Track here are where the license activations are. I made this offer for $5 a month for this module. Did it work well? Or did it not work well? Or did it work well in hosting companies versus independent solution providers. And really manage and optimize around that.


Ron: Could you use your services to get like, I don't know, error reporting back like maybe I catch an exception to my module and I'm like, "Oh this is something that we want to know about, " so we are going to send it back through you guys?

Josh: Right. There are actually two additional optional products that we offer as well. One is the FlatBurger Updater and one is the FlatBurger Error Reporting Tool. The FlatBurger Updater is a DotNetNuke module that a user can install in their system; the same as any other module. But what it allows them to do is to see a list of all the current modules that they have. They can, similar to Windows update, check for an update. If one is available, an upgrade is out there in the system, they click install upgrade -- it's done.


The error reporting tool is a similar process. It's a module that sits on their site that will track all of the errors that happen for any module in the system and report them back to the system. This is useful for the module developer to see what is really happening in the real world; and use that information to fix these errors and better, you know, analyze them, as well as the fact that it enables us, during our certification process, to, if a module developer is not adhering to things, then remove their certification to really enforce the trust.


Ron: Oh, OK. So, all right; you've got a number of these services you keep coming out with. Are there some others that you haven't told me about yet?

Josh: I think one we haven't talked about is the FlatBurger Labs and the certification process set that we offer. Actually the first step in the process prior to protecting and licensing and distributing the module, there is the ability for the module developer to submit their module to our certification labs.


In those labs we can test for, do code analysis, general functional analysis, security analysis, as well as performance analysis. And then make a judgment based on certain criteria whether that module should get certification in each of those areas as well as take the details of that report and make it available for anything from hosts, to end consumers, to other developers who want to also use that module to package into their own solution, etc.


Ron: So there's no hiding it. If I have lousy code, you guys are going to find out?

Josh: That's right because ultimately each different consumer has different expectations and they demand different things. Enterprise class costumer or host might be very strict on what they require in security or in performance versus a mom and pop shop, if it's a little slow, they don't care. So enabling them, the consumer, to make an informed decision is what the goal really is there.


Ron: So do I have to provide you guys with some help building the test harness for the performance test or how does that work?

Josh: Yes. We're exploring ways to improve the testing process. Constantly we are improving it. One of the things we incorporate is we require, for some of the testing, for a module developer to submit a kind of sample data script. Just sort of pre-fill their module with data. What that does is it allows us, as soon as in our testing system we install the module instantly pre-filled with data, real data, so it's an accurate representation as to how a module may be used and test against that real data.


Ron: Interesting stuff. Wow, so that's... These are useful things when you think about, these are small shops, they don't have gobs of servers sitting around to do load testing on, and all that kind of stuff, so it's a very useful service for them.

Josh: Yeah, absolutely, because a lot of these guys maybe test it in one environment or two environments, maybe, if they test it at all.


Ron: They test it on their dev box.


[laughter]

Josh: Exactly so being able to sort of consolidate that into our performance lab to really test extensively, really put it through the testing process against all sorts of different environments, is definitely valuable.


Ron: Excellent. Wow, well, congratulations! You guys are building a great business. Thanks for joining me today.

Josh: Thanks for having me.


Ron: We'll be back with more from the SoftModCon 2006. Stay tuned.


[Music begins]


[Sound of sipping]


Josh McWilliam. Wasn't that great? I love hearing how people are coming up with innovative solutions to problems like the problems of the small guy, the small modular developer, who needs to build some confidence in their customer base, who needs to handle things like a patching and deployment and updates. Well, it's just a whole new world isn't it? It's not just for the big guys anymore.


Well, nevertheless, let's talk about what's on ARCast.net this week - the audio show. We have a two-partner on programming Outlook 2007 which is just a very interesting possibilities there. And then on December 14th, we have the Windows Workflow team answering your questions or at least the questions of our architect MVP's that they submitted. People we are on to something here, I think and we will see you next time on ARCast TV.