Friday, February 4, 2011

We're making Web Edition application deployment painless

When we began work on REAL Studio Web Edition, one of our early problems was deployment. The Stand Alone deployment option was an obvious choice, but isn’t acceptable to most hosting companies, and generally requires somebody with IT skills to properly maintain it. We decided that FastCGI would be easy enough to deploy on an acceptable number of hosting companies.

Unfortunately, although we weren’t wrong about FastCGI, we weren’t right either - it isn’t good enough. Once your server has been configured, deployment is quite simple, but that initial configuration is more difficult than we want to put our developers through. The number of hosts supporting FastCGI WE apps isn’t bad, but isn’t acceptable either.

Beginning with REAL Studio 2011 Release 1, we will be introducing a new deployment option with two important goals: easier to deploy, and acceptable on a broader range of servers. This option will be called “CGI” deployment.

This new option will use a standard CGI script - CGI stands for Common Gateway Interface, and has been available from nearly every hosting company for a very, very long time. This script will work as a sort of middle man or gateway between the web server, and your app. If your app is not running, the script will launch it. Deployment requires nothing more than an FTP client, and maintenance is handled entirely by the script. And because CGI scripting is nearly universally supported, nearly every web server will support this model.

We will be dropping the FastCGI deployment option. However, if you currently have FastCGI working on your server and you would like to continue using FastCGI, the new CGI script can be run as a FastCGI with no code changes. Using FastCGI will help improve performance, but will be completely optional.

For those of you that have been working through the issues with configuring FastCGI to deploy your app, we know it hasn’t been easy and appreciate your efforts. This new CGI gateway will make deployment painless. Your patience while we have been developing this solution is appreciated.

23 comments:

Travis said...

What form will the script that is CGI/FastCGI compatible take? Executable, perl script, etc?

I just wanted to be clear that the standalone option is here for the long haul. I've got a deployment working quite well in standalone with an SSL proxy in front of it- and I'd hate to see that option go away.

Thom McGrath said...

We have no intention of removing the stand alone option. It works quite well and is easy to maintain.

During the beta phase, the CGI will be a Perl script. Before release, however, it will be ported to a C executable to improve performance.

xdr said...

This is excellent news.

P.S. Can anyone see the verification word on an iPad?

xdr said...

This is excellent news.

P.S. Can anyone see the verification word on an iPad?

madmonk said...

Thanks ! I was about to send an email to RS about this. I reread your post of 22nd Dec and it seemed non trivial to me. RB supposed to be easy this wasn't. Good choice.

Rich said...

This is great news... will this new setup also work with IIS?

Geoff Perlman said...

@ Rich - In theory, it should work with any web server that supports CGI (and is running Mac, Windows or Linux on x86 of course). However, we have only tested so far with Apache.

charonn0 said...

I'd be a cool feature if we could optionally choose to forego porting the app to a C executable and just output a Perl script :D

Thom McGrath said...

There's no real benefit in leaving the app as Perl over C.

waveuponwave said...
This comment has been removed by the author.
waveuponwave said...

Thanks but no thanks, I'm perfectly happy with FastCGI and Tomcat.

Roberto De Ioris said...
This comment has been removed by the author.
Geoff Perlman said...

As Thom stated, the script generated with your app will also run as a FastCGI so you do get the best of both worlds. We have found the extra overhead of using the script as a gateway to be minimal. The script runs like any other CGI so I don't see hosting companies as having any problems with this.

Roberto De Ioris said...
This comment has been removed by the author.
Jack said...

"There's no real benefit in leaving the app as Perl over C."

Some hosting providers only allow CGI as scripts, like Perl. They don't allow binary CGI. For example, here's the restriction from ReadyHosting, used by one of my customers (and I don't recommend ReadyHosting at all, BTW):

CGI Languages supported: Perl and Python
Required Server Side Includes filename extensions: .shtml
Required CGI extensions: .pl or .cgi for Perl scripts and .py for Python scripts. Your files must have these extensions or they will not work.

Now, I don't know if you put the binary in as .cgi if it will work or not, but it certainly isn't supported, and if there's a problem, you'd be out of luck. So having the option of still using Perl might not be a bad thing.

Travis said...

Jack- your app itself will always be native code. Hosts that don't support native code won't ever work, but allowing for a dual CGI/FastCGI controller script/app will widen the support from where it is today.

John said...

I'm not sure CGI is the way to go...

Looking into something like lighty may be a better option...

The following is off the site http://www.lighttpd.net/

Security, speed, compliance, and flexibility -- all of these describe lighttpd (pron. lighty) which is rapidly redefining efficiency of a webserver; as it is designed and optimized for high performance environments. With a small memory footprint compared to other web-servers, effective management of the cpu-load, and advanced feature set (FastCGI, SCGI, Auth, Output-Compression, URL-Rewriting and many more) lighttpd is the perfect solution for every server that is suffering load problems. And best of all it's Open Source licensed under the revised BSD license.

CGI may still have security issues, it's been a long time since I looked into using CGI but Security and the process protection kept me from using it.
Just something to think about before you get too deep into it.

Thom McGrath said...

LigHTTPD and CGI aren't competing technologies. The former is a server, the latter is a method of inter-process communication.

It's like saying "don't drive a Ford, use highways instead." LigHTTPD is a good option, but you would use it in conjunction with the CGI, not instead of.

Jack said...

Travis,

I think you missed my point. If the script is in Perl, then I have at least a chance that the ISP will run it (and have it kick off my app). But if it's a binary, there's probably no chance.

Red Eagle said...

Problem is, if you go with perl, you pretty much guarantee none of your console plugins will work. That also guarantees that plugin writers will now have a new version of the plugin sdk to switch to, and developers will need to now fork out more money for a whole new set of plugins for perl now.... Not to mention, last, but way far from least. In perl your code is not compiled and everyone can easily modify your code. O.k. for your own web server, but if you planned on selling your app.... I don't see how your going to do that in perl....

Thom McGrath said...

No, your app is not Perl, only the gateway between the server and your app.

Fisheye said...

To clear the air, as said "Beginning with REAL Studio 2011 Release 1" this option will be present. Does this mean that users who just bought WE 2010 will not have this option, but have to buy the Studio 2011 release also? No update for WE 2010 v 5.1?

Alyssa said...

@Fisheye All new WE licenses came with 6 months of updates. Check your expiration date, you have access to the new updates. Feel free to write Customer Service to clear up any details about your license key.