You can listen to the podcast and read the show notes here
Michael: Welcome back to the show. I'm here with David Tattersall and he's speaking to us from his home office in Germany, near the world headquarters of Intergral, who made FusionReactor, amazing server monitor. And we're going to be looking at what exactly FusionReactor is and how it's different from all the other tools that you can use to monitor your server. And what's exciting in new version seven that's coming out real soon now, though I can't quite get to a date from David. You know how it is with-
Michael: Yes. We're going to also look at how FusionReactor works in the cloud and what versions of ColdFusion and Lucee does it work with. And we'll also look at the roadmap for FusionReactor coming up. So lots of exciting stuff. So welcome, David.
David : Thank you, Thank you, Michael. Thank you for having me on the show.
Michael: You are so welcome. So what exactly is FusionReactor? I'm sure there's at least three people listening who haven't got a clue what FusionReactor is. You want to enlighten them?
David : Yeah, so FusionReactor is the global market leader for performance monitoring on the ColdFusion platform. FusionReactor is a low-overhead Java monitor. It gives developers DevOps and operations folks a really deep insight into exactly how their applications are performing and how they execute a production runtime. FusionReactor's a hybrid monitor so it's always on premise. And we've also got a cloud version, so FusionReactor CLOUD, so you can extend it into the cloud.
Michael: How long has it been around, David?
David : It's been around since we first launched FusionReactor in 2005. So-
Michael: So 12 years? It's nearly a teenager.
David : Coming onto 12 years, yes. We've got around 5,000 customers that's taken FusionReactor. We've got at least 25-plus thousand servers running FusionReactor in production right now.
Michael: Wow. And what kind of organizations are using it?
David : Oh, it's really all kinds of organizations. So we've really got very much across the board and from … there's a lot of government agencies that are using FusionReactor. We've got a lot of universities, hospitals, and there's a lot of Fortune 500 companies, so really large companies that are using the products with hundreds of installations and then right down to small developer shops just with a few developers and that very simple application. They're all using FusionReactor. So it's very, very much really across the board. The majority of the customers that we've got are in North America. So we've got about 80% of our business in the States and the last probably about 10% in the UK, and the rest dotted around all over the world.
Michael: Cool. So is it mostly people running ColdFusion servers or you also have people who are using it to monitor Java apps?
David : Yes. So I'd say the majority are ColdFusion servers, although as you're probably aware, FusionReactor is a Java monitor. And certainly since the launch of FusionReactor 6.0, which was November 2015, we've been pushing more into the Java space. So we've got support now for a number of different frameworks like Spring or Struts. And we've definitely seen quite a pick up of non-ColdFusion customers.
We've also been sponsoring a number of the Java-focused events. Last week we sponsored JAX in Mainz in Germany, which is the largest Java conference in Germany.
Michael: Cool. Well, I always appreciate how much you support the different communities and I know you've sponsored a lot of ColdFusion conferences. We'll talk more about that later.
So how is FusionReactor different from any other Java performance monitoring tool you might use?
David : Okay. So basically if you think why do you need a performance monitor … so I've got a few facts about monitoring. The most time consuming thing that engineers are gonna be faced with is basically finding an issue using root cause analysis. That's number one. And number two is actually reproducing it. If you take a look at modern applications today, everything's distributed, everything's service based. And when something goes wrong in production, trying to reproduce that is an absolute nightmare. So I'm sure you've heard developers say, “Oh, we cannot reproduce it. It only ever happens in production.” And most application … the most problems actually occur in application code and in the database. Those are the two main areas.
And it's interesting when you very often ask developers what is the most used tool that developers use for finding problems in production. And I'll just ask you, Michael, what would you say? What's the most used tool for finding production problems? What would you say that is?
Michael: Well, the tool I'd like to use the most is the debugger, but it's hard to use in production.
David : Okay, yeah, that's a good answer. But it's the actual most used tool and it's a bit of a trick question.
Michael: Yeah.
David : The most used tool is actually log files.
Michael: Oh.
David : When I'm asking developers what do you use in order to find problems in production, almost always it's log files. And actually DZone did a recent survey and I think that they asked 1,000 developers and over 90% of them gave log files as the number-one tool for finding problems in production. And that's closely followed by profilers, debuggers, and memory analyzers. So those are from the tool perspective is profilers, debuggers, and memory analyzers. And the main tool is actually log files.
And if you think if you've ever used a log file, and I'm sure you have, to isolate issues, log files are a pain to use. They're difficult. You've got to trial through them. You may not have the log files that you expect. The log files may not come saying the correct information that you need. Log files may be out of sync, etc, etc. So there are a lot of problems with log files.
And basically with monitoring, you're trying to do two things. You're trying to identify either some sort of logic or quality issue in your code or you're trying to identify performance issues. So those are the two main areas. And with FusionReactor, all monitors basically do the same two things. They all measure and they all [inaudible 00:08:22]. And for me, this is what I call … this is sort of core monitoring capability. And FusionReactor has got all this core capability as well, so it's a very real-time product. So you can see really down to the second exactly what's running on your application. So it's like when you're looking into FusionReactor, it's sort of like watching application DB because you can see what's coming in, you can see them being processed. If something is running slowly, you can actually see it in real time running slowly, so you can perform a stack trace on that. So you can actually analyze it as requests are being processed.
So FusionReactor measures and records all kinds of different metrics. So you've got things like Web requests, Web transactions. Within a Web request, you can see transactional information, where it was called from, how much memory you use, how long it ran, which IP address called, what the URL was. And then you can see things like JDBC activity. So you can see the actual SQL statements that are being executed. You can see how long those ran, how many rows were returned, how much time was actually spent on the database. You can see things like hibernate calls. We've got support from MongoDB. You can also see a fairly common feature in monitoring is something called UAM which is user experience monitoring. And with user experience monitoring, we're actually measuring the end-to-end performance of a request.
So if you're a user and you I don't know, order some item online, we would measure the time taken for that request to be sent across the wire, to be processed at the server. We're breaking down any database-related time spent. We're measuring the request coming back to the client and then all the client rendering time. So that gives you a really great overview from an end-to-end perspective how much time you're actually spending. And this cuts … if you imagine sometimes you may have sat in some sort of war room meeting where customers called in and said, “Oh, you know, your application is performing slowly.” And then there's finger pointing going off. The database guy says, “It's not me.” The network guy saying, “Oh, it's definitely not the network. Blah, blah blah.” But with UAM you can really see, it really graphs it up really nice. Look, you can see exactly where you're spending your time. So that's also included.
We can also do things like session management, so we can see how many sessions were created. We've also got very detailed JVM metrics, so we can see heap, memory utilization, CPU obviously, and super different memory spaces that you've got so PermGen or Eden and we can look and see how the garbage collector's workings. A lot of people were interested to see how GC is running. We can actually launch GC garbage collection clean-up from the within FusionReactor.
As we've sort of focused on ColdFusion over the years we've got about I think it's over 40 specific ColdFusion metrics that we're exposing so things like active session counts, application scope size, ITCans , DV pool sites, things like that. If you've got the enterprise or ultimate edition then you've got an enterprise dashboard so you can see the overall health of all your servers within one window. That's very useful. Plus we've also got a system monitor so FusionReactor's pretty much focused within a server instance. What with the server monitor you can actually get a view of the whole machine so here you can see things like a network disk IO, you can see a normal view of all the processes running on your actual server and you can check for disk capacities of FusionReactor.
One when you [inaudible 00:13:15] diskspace and we also got a bunch of reports so we do a daily, a weekly, and a monthly reports and these can be used to send in requests that've been processed, what the HTTP codes are, what the average CPU, average database response time was. So you could really use those reports for doing service level agreement checking. That's the idea and you can sort of add daily feedback of how your application's doing and then that can be used for checking service level agreements.
So that's all that I see as the core functionality. So how do we differentiate ourselves? How does FusionReactor differentiates itself from other monitors> It's basically in two areas and the first area is we've got something called Crash Protection. Crash Protection can be used when FusionReactor determines that something isn't running as it should. FusionReactor will actually take charge and try and proactively do something to keep the server alive. This is a unique feature. I don't believe there's any other monitor that does this. An example would be, let's say you set your memory threshold at 96%. So you can say, when my memory goes over 96% utilization then I want FusionReactor to block any new requests which is coming into the server. It will do that until the memory basically catches all of itself and then drops down or below that threshold.
Another example would be, let's say on your application you determine that all your requests should run within two and a half seconds. So mainly you do not get any requests that runs for longer than two and a half seconds or maybe you've got a couple of reports that run longer and those can be excluded from this check, but if any other request runs longer than 10 seconds then you could instruct FusionReactior to actually kill that request. So it will attempt to kill it and if it does kill it then it's gone.
That's the first way that we differentiate. The other thing that we do is … the way that we think about a monitor is, a monitor basically should be used to find out why something is going wrong. Very often I'll ask people, “Why do you need a monitor?” And quite often I get the answer or I want to see what's running on my server. What is my server … what's my application doing? And that's okay, but really you're trying to find out why something is broken. Why is it performing slowly? Why is this request aborting? What's the problem and why is it occurring?
The other way that we differentiate ourselves is we look at which developer tools developers will use to try and isolate issues. Like I said before, those tools are debuggers like Eclipse or Fusion Debug in the ColdFusion world. And we've got cold profilers like JProfiler and memory analysis tools like JVisual and JVisual VM, or MAT and will be a very common memory analysis tool.
What we've done is we've taken the best components from those tools and we filled them directly into FusionReactor and we've made these features safe, secure, and very low-overhead so that you can use them in a production environment. And nobody else has done this, but with the-
Michael: Isn't that really hard to do with a debugger though, David? When you turn on a breakpoint it's gonna stop your whole app from running, for everyone in the server. How do you get around that?
David : Okay so, yes it is very very difficult to do. So why wouldn't you see a debugger in production normally? But there's two main reasons. The first reason is performance hits. And the performance hit comes from if you were attaching a debugger remotely, let's say using Eclipse there's debug protocol gets passed between Eclipse and between the remote server and it's that debug protocol that really makes the performance slow and really degrade your production environment. And we could around that because we're actually inside the JVM so there's a debugger which is built into a java virtual machine and we're going straight [inaudible 00:18:48] debugger through the NTI, through the tools interface so we've coded directly at it so we don't have this protocol.
So when the debugger is not running the overhead's actually zero. And even when the debugger does run it's really really minimal. So we've gotten over that problem there. And to answer your other question, what's another problem, and you brought that one up. If you set a breakpoints in some methods or some initialization class and that breakpoint fired or that class was [inaudible 00:19:28] from everywhere, let's say it's some initialization thing and that breakpoint would fire. What we've done to overcome that problem is we've actually come up with sets of controlled mechanisms to enable you to control how often and how a breakpoint should actually be fired in production and we didn't put … we've applied for patents on that capability. So for example we could fire a breakpoints just one side. So let's say you've got some part of your application is throwing an exception, we can say okay if this exception gets thrown then I want to capture that exception, but I only want to do it one time. So for person who was using your application on that thread they would lose that session, but this was an exception causing an issue. So you would've crashed anyway, but the cool thing is that we would capture that and we can hold that session for any amount of time.
So you can control, you can say okay if a breakpoint fires, then I want to hold that breakpoint for 60 seconds. Or I want to hold my breakpoint for five minutes or I want to hold that breakpoint indefinitely and this is a really neat feature that's built into the debugger and once a breakpoint fires, FusionReactor will actually send out an email and in that email you can configure it so you've got a link in the email. When you just click on the link, it sends you straight into the debugger and that email also contains full stack trace as well as all the variables at the point that that breakpoint was fired. So all the scope variables, which as I'm sure you'd know. Even having the variables at that point could easily enable you to isolate the issue. It will actually set a breakpoint, capture it, send it out in email, and we will hold that thread indefinitely until you go and intercept that email.
So it's a really cool feature. What it means is that let's say something breaks at two o'clock in the morning and we'll take care of it and when you go into work you just basically go into your email, there's an email, you click on the link, and you're inside that breakpoint exactly as it was happening. It's sort of like having a time machine. It's pretty amazing stuff.
Michael: Wow. That does sound like genius.
David : It is pretty much genius and the other stuff's surely cool too. The profiler, that enables you to actually do a live performance analysis of your code as it's running in production. So a profiler will enable you to isolate hotspots or you use it for performance shooting. And with the memory profiler, the memory analyzer that's very similar to JVisual VM, if you've seen the memory analyzer in that tool, so if you use that you can see for example all the classes which are running, how many objects they've got open, what the real time heap utilization is. You can also do GC roots analysis so it's got the garbage collection roots so basically you can analyze how the memory's actually being maintained and stored. And through that it makes it very easy to do memory leak detection. You can actually see the memory leaks appearing across time directly in the FusionReactor. Which is … it's really an amazing feature and to have that available in the production environment and running with very, very low overhead and very safely and securely, we believe is a major differentiator and a major breakthrough.
Michael: Wow. Well I know memory leaks being a bad bearer of ColdFusion server crashes for a long time so being able to detect those like that is really cool. When you say the overhead's low, how low is the overhead? ‘Cause you've mentioned so many features. It sounds like it must take up 10% of the server CPU or whatever.
David : No, it doesn't. So FusionReactor less than 1% overhead and we've really, really right from the onset of building FusionReactor it's really been our goal to keep the overhead absolutely as low as possible. When you compare FusionReactor to some of the other monitors on the market, very often the other monitors they can gain anywhere between 25% overhead. Obviously, as you can remember from O Level Physics, back in the day you measure something then that has an effect on that thing. So you can't measure at no cost, but we really try and keep the low 1% with FusionReactor. And I believe that for the return on investment that you get for the benefit of that monitoring capability it;s really really worth it. You do get a lot back for this. The cost in performance impact, you really get a lot of data back. It's incredible.
Michael: Let's just talk about costs 'cause you can rent this for $39 a month, right?
David : Right, one of the versions. [inaudible 00:25:51]
Michael: That's less than the cost of a cheap cup of coffee. A very bad cup of coffee [inaudible 00:25:58] for a $1.30.
David : Yeah so it starts at $39 a month and we've got two ways that you can purchase a license. We've either got subscription which is either monthly or annually, or you can purchase a license outright. So we like to give people choice. That's really what we've always been about right from the start. You know, different customers some of them like to do monthly, some just want to buy the software and we really believe we want to give people choice.
So the monthly it starts at $39 a month, that's for FusionReactor Standard and if you take a year's worth of license then basically you get two months free so it will be $390 for the annual license. If you wanted to purchase FusionReaction Standard that would cost you $999. So basically if you're look at say from a sort of a return in investment perspective then you could pretty much say, so if you're going to use the product for let's say, three and a half years or over three years then it's better to buy it and just keep doing the annual maintenance. Maintenance is about 20% of the price of the software and if you do the maintenance then you get all the updates and all the upgrades.
So we've got three editions. FusionReactor Standard, FusionReactor Enterprise, and FusionReactor Ultimate and the developer tools that I mentioned, which are the key differentiators, those are included in Ultimate. In FusionReactor Standard, you've got all the core monitoring capability so you can see all the things that I mentioned earlier which are part of the core functionality and it's pretty much in the Standard edition and with the Enterprise you've got the system monitor, you've got the enterprise dashboard, so if you're using multiple servers then usually you could be the Enterprise or the Ultimate edition.
Michael: Cool. So I know you're working on FusionReactor version 7.0 that's gonna come out some point in, I guess this year. Safe to say this year, but we don't know exactly when.
David : Safe to say this year.
Michael: And it's currently in QA, is that where it is or …?
David : Yup. It's in QA and so some of the main features which are coming up in FusionReactor 7.0, we've got some really cool new stuff. One thing that we've done is we've now added full support for java management expansions, otherwise known as JMX and this gives you the capability to monitor all kinds of applications, system objects, and the system objects are represented by something called the embings and this has really extended the metric monitoring capability vastly. When I see all the metrics that are now available for JMX it is phenomenal. You can also write your own embings. What that means is you can basically extend FusionReactor essentially to monitor whatever you want. It's really a great capability.
Another thing everyone's heard of AWS's web services. It's probably the most popular platform for hosting applications in the cloud and AWS also has a monitoring service and that monitoring service is called AWS Cloudwatch. Cloudwatch enables you to capture metrics and visualize them into graphs, you can also build dashboards, you can also do a [inaudible 00:30:27] and with the apps then FusionReactor 7.0 we've included the capability to link FusionReactor standard metrics. So all the metrics that we analyze plus all the embings of the JMX metrics and we've enabled the ability to push those metrics up to AWS Cloudwatch.
I don't believe there's any other product which is doing this, especially for JMX. I know you can … I found some software on [inaudible 00:31:06] where you could sort of take it and do a bit of do-it-yourself push up to Cloudwatch, but this capability enables FusionReactor to basically become sort of a broker to glue together JMX metric processing and AWS Cloudwatch. It's just so simple, it's literally click click click, click click add to Cloudwatch and then when you go into your Cloudwatch you can use instantly get all these metrics available.
So you're not really doing very much. All you need is FusionReactor in the middle and all that capability is included. We've also done some enhancements with the debugger so we've got a great feature now. I call it the one-click breakpoint. One feature I think I should mention we the debug capability FusionReactor can decompile your [inaudible 00:32:13] on the fly which is pretty amazing. And it's so quick at doing it so if you run into something and you forgot to plug the source code you can just go into FusionReactor and set a breakpoint or like an exception let's say, HTTP 500. You can [inaudible 00:32:37]into that, click decompile, on the code is decompiled, and you can literally just go into see your code on the screen. You can just go and click next to the point in your code where you want to set that breakpoint and FusionReactor will set you a breakpoint. Just like we could do in Eclipse or in Fusion Feedback and once you've got that the next time that code runs it will automatically break at that point. Like I said before, you've got this capability it will by default it will only halt it one time so it's just going to halt on one thread, but it is amazing. When you see it and you see how fast it is to go straight into your production code, set a breakpoint and just go on and debug it on the fly, in production with minimal overhead it's pretty amazing.
We've also got that I mentioned before the memory profiler. So to check out the heap utilization that is also [inaudible 00:33:46] feautre. I'm talking about it 'cause I'm already using it and I like it a lot. It is just amazing. It was interesting, I tried to bring up a my test environment. I tried to bring up Jvisual VM just to see what the difference was in the views between Jvisual VM and between FusionReactor running in the same environment and it just wouldn't work. I just couldn't get Jvisual BM to launch on my production system. In the meantime I got a couple of applications running in the background and just with our memory analyzer there was not a problem at all. So it was running very very happily. As fast as really as fast as ever. I didn't notice any performance degradation. It just runs. And that's it's hats off to the development team. They've done an amazing job which was a very very very difficult thing to do also the debugger and the profiler and these are very very very difficult problems to break. Those guys have done a really excellent job.
Michael: That is great and I know 'cause I've been involved in this stuff for a long time and getting the debugger to work on production is pretty amazing. I'm excited about all these new memory things 'cause often servers crash 'cause memory is leaking or your heat just got messed up.
David : Yes it does. Yup. Memory is very very often a culprit so yeah, that's gonna be good.
Michael: So I was looking through the FusionReactor website before we got on this interview for the podcast and I noticed that you're now in the cloud. Why did you do that?
David : Right. So why did we move up into the cloud. Well, we've been … so just a little bit of background. So the cloud's been running. We started as a closed feature at the end of 2015 and then we started moving to run that feature as basically as paying customers right about summer 2016. Since then we've been gradually moving customers onto the cloud and why did we do it? There was a number of reasons. As I mentioned to you before we've all strived to keep FusionReactor going low overhead and to keep the information … so basically we did want to store information onto the local disk. We do store local files onto the disk with a rotation system which will move them off and back them up, but we did want to start storing a little bit of information locally. So one of the reasons for being in the cloud is so that we can capture data and push that data up to the cloud and have that data stored, maintained, so that we can analyze it, aggregate it and then make it available to our customers through the cloud interface.
So FusionReactor as it's running normally, the graphs that you can see basically you can see line view, you can see the last hour or you can see up to a week's worth of data. And that data is actually stored in memory. It's very optimally stored, but it isstored in memory. Again we try to keep the amounts of data as small as possible, but we then work to compile it and we can look at data across a longer period of time.
Another reason is FusionReactor basically is us. It's focus on a servre instance and if you've got, let's say you've got a [inaudible 00:38:05] service on it, it would be great to be able to see … and let's say you just got one application running on that cluster. It'd be great to see how is my application performing? And again with the advents of the cloud, you can do that so you can [inaudible 00:38:25] I've got FusionReactor on these six instances, but I'm going to group these instances together and I'm gonna give myself an application view. That's also a really great thing when you're trying to look at the performance of applications to see how the application is performing as a whole and not just as an individual instance.
Yeah, so that's one of the reasons.
Michael: So does also tie in with fusion analytics or …?
David : Well Fusion Analytics, fusion analytics is still there and that's not going away. Fusion analytics gives you some additional features. Fusion analytics, it's actually performing much more analysis on the data. So the idea with Fusion analytics was also to be able to store data across a longer period of time. You can actually store much more data with Fusion Analytics. You're not bound to the amount of data we're putting in the cloud. You can actually … this place and a big enough database and I'm supposed to be clear, the database that we ship with for Fusion Analytics stores 10 GB. So it's a Microsoft … it's the Microsoft, I don't remember what it's called, it's basically it's the free engine that's delivered with Microsoft Sequel Server which can store up to 10 GB. If you want it to store more data then you'd need a full access Sequel Server license. Then it's up to you. You could store a week, or a month, or six months, or a year. However much data you'd like and Fusion Analytics will consume that data, it analyzes it and think there must be about at least 150 different reports and graphs and tables, which are analyzing all your data.
Some of the ways that some customers have looked at that is that Fusion Analytics is sort of like the cloud. It's giving you more information actually in many respects, at least in terms of analysis of the actual data, but they don't need to use the cloud. So it's an unpremised solution. Some of are customers aren't able to use the cloud or they don't want to use the cloud. For those guys Fusion Analytics is still a really great option. On the cloud side, I was just gonna wrap up, one of the other key differentiator it has which Fusion Analytics doesn't have is … and FusionReactor CLOUD has got a really amazing alerting engine and that alerting engine enables you to take all the different metrics that FusionReactor is analyzing and you can create alerts out of those metrics.
We've got four integrations with a number of different loading services. For example, we've pager GMC, we've got Slack, we've got Hit Charts, we've got VictorOps, we've got Trillium. You can do integration with regular email of course, you've got HTTP hooks that you can link to some some sort of URL to generate an alert. There's really a lot of capability in the alerting engine. As we move forward with that we're gonna be pushing much more data as we're analyzing what's going on in your server, we're going to be pushing that data up to the cloud.
So FusionReactor and cloud also show you a lot of the same information that you've already got on FusionReactor on premise. Obviously not everything, but for example you can see stack traces, slow running requests, you can see new resources, memory, and CPU, all that stuff as well. There's also … it's actually in comparison to other cloud services, which don't … they're all one-way FusionReactor is actually two-way. So we've got a secure bidirectional link between FusionReactor Cloud and your local FusionReactor service and we can actually from the cloud generate stack trace or run a garbage collection directly from the cloud. And the performance is phenomenal. It really is. It's amazing to watch it. It really is instantaneous and response time. So yeah, that's really exciting for us.
Michael: Wow. That's cool. I'm kind of curious. What versions of Adobe ColdFusion and Lucee does FusionReactor work with these days?
David : FusionReactor 6 works with ColdFusion 8, 9, 10, 11, 2016, and we've also … if you've got ColdFusion 6.1 or 7 MX you can still get copies of FusionReactor 4.5 and those will work very happily with those older versions of ColdFusion if you've still got them. And we support Railo 3X everything and 4X everything and then we've got support for Lucee 4.5 and Lucee 5 and we need to be a little bit careful as Lucee has evolved and is bringing out new versions. We actually just got a [inaudible 00:44:41] from an issue where the compatibility issue between FusionReactor a very new version of Lucee, but what I can say is that we're working very closely with the Lucee Foundation and we're working very closely with Adobe ColdFusion team and our goal is always to make sure that we always support the latest versions of both Adobe ColdFusion and Lucee.
Michael: Great. So what's your development roadmap for the next year?
David : Like I said, we're basically working on FusionReactor 7 now and actually launching so open the launching [inaudible 00:45:30] you can buy it today, you can [inaudible 00:45:34] you can purchase a cloud license or you can also do … you can try that so you can I'd happily give you a trial of FusionReactor Cloud, but if you go to the website you can't actually buy it because we've not got the official launch yet. We're going to be doing that this year and launching FusionReactor 7 which is the next major release.
Then for the coming year I will focus … it's gonna be on more intelligent analysis of data. We're trying to analyze the data that we're collecting and interpreting and coming up with the answers once something is broken. We always … when we started with FusionReactor there was imagine a big green button we called [inaudible 00:46:25]
Michael: (laugh)
David : But you push the green button and it tells you exactly what the problem is. I think the future is going in that direction. We're trying to interpret the data and really assist you to isolate and locate your problems as fast as possible. So you're really trying to speed up issue identification. In the cloud we're gonna be working on improved collaboration and a lot more alerting is planned. Also log analysis, so capturing, sending that log information from FusionReactor up into the cloud so we can analyze it there.
If people are interested in that we're also working on having monitoring support for ModeJS so then we've already got a working prototype of ModeJS so that's something that's going on in the background.
Michael: Wow. Lots of exiting stuff coming up. As well as a mountain of exciting things it already does.
David : Yeah. Yup
Michael: (laugh) So I know you support a lot of conferences in ColdFusion Java around the world. Why do you do that?
David : Well, you know we've been sponsoring ColdFusion event I think since 2005 or 2006 and I think in the ColdFusion world I think most people have heard of us. It just happens that somebody comes up at an event and says, “I've never heard of FusionReactor,” but I think ColdFusion events is what I'm talking about here. But I think that … you know we see sponsorship as a chance to support and give something back to the ColdFusion community. There's not hundreds of companies who are really doing ColdFusion stuff and I think if those companies didn't support then it would be … it'd make things worse for ColdFusion and we really see it as a chance to give back and make sure that those events and conferences keep on happening and keep on serving the community. So that's basically why we do it and like I said, we're doing more Java focused events so we will have mixers in Atlanta in February and we're going to be sponsoring Velocity in San Jose in June and also Velocity in London in October I think. So Velocity is sort of a conference in and around sort of DevOps and monitoring … it's very much sort of a monitoring event, but also there's a lot of guys that go there and gals who are doing Java.
Michael: Cool. Well appreciate you supporting all of these conferences and the ColdFusion Java communities.
David : There's also a great … it's for me personally, it's a great opportunity to meet up with customers so a lot of times it's familiar places that come up where it's best to see people again. Maybe we just see each other once a year, but also to get feedback about the products and we're always very very open to feedback and what people think about it and how we can improve it. We also see that conferences is a great way to interact with customers and to get that feedback. That's very [inaudible 00:50:28] for me personally and for the job that I do for the company.
Michael: So why are you proud to use ColdFusion in your company? You've used it for years.
David : Why are we proud? I think I've got to go back to 1997.
Michael: Wow.
David : And were actually developing what at the time was the largest web application development in the world. For you to get [inaudible 00:51:02] it was a big document management system which they wanted to roll out to all the service reps and distributors globally and we were building it. We'd actually selected the different technology. It was called Lustra and it doesn't exit anymore, but at the time it was part of [inaudible 00:51:26] language somewhat similar to ColdFusion based on the informings database and we just got problems with it. We put this software on … it was a mid-size server from HP and it it was performing terribly. It was just really bad. And it sort of looking like we weren't going to be able to complete this project. We made a decision then. We weren't really getting anywhere with Lustra and Darren [inaudible 00:52:08] my partner, he said one day he said, “Dave you know, we've got to look for something else if we carry on with Lustra we're in trouble,” and he went away and came back he was gone over the weekend and came back on Monday. He said, “Dave I found this software. It could save us.” And that software was ColdFusion.
Michael: Wow.
David : This was version two. I said, “Okay.” And he said, “The most amazing thing is it's gonna have to run on an NT box.” So in this case and time, you can imagine that HP nobody was running enterprise applications on NT boxes. It's unheard of. Everybody was was like there had to be some whatever k class server or something. Some big HP Xbox and we came along with ColdFusion until I remember telling HP management, “Oh this is going to run on NT,” and they sort of looked at me like I'm crazy. Anyway, we ported it we task ported it. It wasn't too difficult. We actually did it over Christmas only 3 months away and I was included as well. I'd not developed for a while. I was managing the project, but I got … I had to do all the admin screens so I was the admin conversion guy. I remember coding on Christmas day between eating my turkey on Christmas day and we just coded and we came back after Christmas and put all this code together and it just worked. It was pretty amazing really. And that made me very very proud to use ColdFusion. We've been friends every since and we've built a ton of stuff on CF it was really great.
So what brought us to developing FusionReactor because as you know you run back into late 1999 or even when we started with FusionReactor back in 2005 ColdFusion was very much a black box you could see inside it and that's why we developed FusionReactor to enable you to get inside the code, see what it's doing, and yeah to integrate stuff that we're doing with it.
That's why I'm proud to support ColdFusion and it gets a bad rep, and of course it's a legacy technology but it's really still a great language.
Michael: Wow. Great answer. I can tell how really excited you are using ColdFusion there. So what would it take for ColdFusion to be even more alive this year?
David : I think the community is definitely key. I think by the way that you're doing the CF Alive talks so that's something which hopefully generates interest. Obviously the events are important. I've been a member of ColdFusion events this year so there was into the box which was also solutions and there's gonna be cf.Objective() which was actually DevObjective, but they came back to cf.Objective() this year which is going to be in Washington in July. Then we've got CF Summit coming up in November so the Adobe CF Summit which is in Vegas. There's also going to be CF Camp which is in Germany and we have [inaudible 00:56:13] that we always sponsor.
So community's important. The events are important. I think it's also Adobe that's also going to put the word out and try and spread some of the ColdFusion message potentially at more at universities so where more people at work studying computer science. Maybe get some exposure to ColdFusion and that they see that actually it is a great language. I'm sure that would help. So yeah, that's what I think can be done to keep ColdFusion alive. Obviously we're very strongly behind ColdFusion. We're supporting Adobe CF and for a public perspective as well obviously works, supporting Rilo and Lucee. Also Blue Dragon I don't know anybody who uses Blue Dragon.
Michael: I think a few percent of people are using it at least on ColdFusion survey we did a few months ago.
David : So FusionReactor also runs on Blue Dragon, so.
Michael: Great. Well, thanks for your support of ColdFusion, David and keep doing the amazing new features at FusionReactor, which helps keep ColdFusion servers running reliably and fast.
David : Okay we'll try. Keep on going.
Michael: Great! Well and thanks for being on the podcast.
David : Okay no problem so nice talking to you Michael. Thank you.
