In mid-June I had a conversation with Jan Aleman, CEO of Servoy, about his IDE. For background, Servoy is a Java-based IDE that can produce desktop and Web interfaces from a single code base; it also provides extensive support for common platforms, all the major SQL databases, and quite a bit of common application functionality. Servoy's customers are primarily ISVs building applications for sale or for SaaS licensing, although there are also some corporate users of Servoy.
Our discussion was framed primarily as a response to my discussion with Iron Speed Chairman Alan Fisher, in which Fisher said that his Designer tool aims to generate 90 percent of the code for an ASP.Net database application. Iron Speed is aimed primarily at people building custom in-house Web applications, although Iron Speed does have a few ISVs.
IW: Why don't you like code generation, Jan?
JA: The simple answer is that 90 percent is not enough for us. Our experience is that code generation gets you into trouble long-term, so we keep all the design information inside our engine. At the same time, we give you a way to add code in any language.
Our background was at Baan Research. We built the frameworks that other groups at Baan used to build high-end, scalable, mission-critical ERP and manufacturing systems. That gives us a different perspective than people who only have built Web sites.
IW: You've been going after Microsoft .Net recently. How is Servoy better?
JA: There are a number of reasons. For one thing, Microsoft has recently realized that it has deployment problems, and problems with the development of big projects, and scalability issues. So Microsoft has been bringing some of the Enterprise capabilities developed for Java into .Net. An example is Hibernate, a powerful, high-performance object/relational persistence and query service, which is now available for .Net as NHibernate. All of that stuff has been in Servoy from Day 1.
Think about SaaS: If you have a live service with multiple tenants, you can't afford to bring the server down for an upgrade, but that's exactly what Microsoft makes you do, and it can be for hours if it's a complex upgrade. Servoy does automatic live upgrades without ever taking the server down.
IW: How do people use Servoy? Why do they like it?
JA: Most of our customers are ISVs. One of the things they like is that they can generate a SaaS Web application and an on-premises native client application from the same code base.
Another issue is multitenant applications. Most environments require you to know what you're doing with multitenant, and there's a lot you need to do yourself with cross-tenant security. Servoy has all of that built in.
SaaS applications usually use a browser. If you think back to the days of client-server applications, we had the right ideas, but there were problems with two-tier deployment when we moved the applications to the Internet because you had the client talking directly to the database, which was hard because of blocked firewall ports and proxies set up to maintain security. Servoy does N-tier correctly, which eases the deployment problems. We even have an HTTP tunnel we can use that completely eliminates proxy and firewall issues, and recently we have optimized the tunnel performance. We used to be about as fast as Terminal Services or Citrix; now we've decreased the roundtrip time and added compression, so we're faster on the same hardware. ISVs appreciate this.
IW: You've been getting some FileMaker developers to upscale to Servoy. What makes them give up their easy-to-use tools?
JA: FileMaker has some good ideas, but the Web implementation is not scalable. They've got a single-threaded engine, which damages scalability, and some of the desktop functions don't work on the Web. What I tell FileMaker developers is "When FileMaker switches its Web site to run on FileMaker, then it'll be a good product." At Servoy, we dog-food our product on all of our own Web sites.
We're also different from PHP and ASP.Net. Out of the box, we have stateful Web applications, where PHP and ASP.Net are stateless. We only use the browser for display and the user interface; you can think of it as heavy AJAX, with everything going through the server and optimized incremental UI changes coming back to the browser. That makes the application lightweight, secure, and debuggable. We think that in the longer term, most players will go to that model.
In the same vein, we optimize what's going to the database. Think about a screen with 40 data entry fields that update multiple tables and possibly multiple databases. Most systems would have to update all of the fields in all of the tables; Servoy can pick out just the changed fields and send the smallest possible updates. That results in a much lower load on the database.
IW: Thank you.