[Info-vax] Using VMS for a web server

[Stephen Hoffman]

On 2015-06-03 23:28:39 +0000, Dirk Munk said:

> I'm aware of all these things, but if WASD can be the web server of 
> choice for VMS, then it would be possible to drop Apache. After alle, 
> WASD is a pure VMS product, it may be easier to implement on VMS than 
> Apache.

As good as WASD is, Apache is the web server that folks expect and are 
familiar with.  Increasing the delta between familiar platforms and 
tools isn't usually the best approach.  Do not ever underestimate the 
advantages of being compatible with expectations, training and tools.


> 
>> 
>> Then there's the question of pricing.  VSI is also competing with a
>> zero-cost entry-price for Linux and BSD distros; for those folks
>> experimenting with and just getting started.  If hosting services are in
>> play, then you're competing with Amazon and folks like
>> https://www.digitalocean.com/ or http://www.rackspace.com/ or
>> http://azure.microsoft.com/ here.  Spooling up a guest is seriously fast
>> on most boxes, too.  A few clicks and you're off and running, whether
>> hosted services or with an end-user-targeted server OS configuration.
>> 
> 
> I'm referring to the type of web server that is a front end to your 
> business, not some box at a hosting organization.

Seems you're following the one-box one-architecture model, and that was 
something familiar, comfortable and common back in the 1990s and 2000s, 
but most places are now dealing with heterogeneous server 
installations, or with their own existing and installed web front-ends. 
 OpenVMS isn't at the center of nearly as many business configurations. 
  While there are some web-facing OpenVMS boxes at businesses — running 
Apache, BTW — there are more than a few folks that are running tools 
and content management and the rest that are predicated on other 
platforms.  Until and unless those front-ends and tools are available 
on OpenVMS, moving OpenVMS into the roll of a web host is going to be a 
tough sell.  Then there's the question of whether you want to have your 
production OpenVMS boxes in your DMZ.

It's possible to be your own hosting organization, BTW.  Makes for a 
handy way to quickly increase the scale of your hosting by either 
rolling in a rack or two of servers — something OpenVMS is not very 
good at — and/or by temporarily adding outside hosting for some tasks.

Individually managing specific servers is also becoming rare — servers 
are resources, and having to individually configure and manage and name 
and address them and load applications and modify startup files is 
inefficient at best.


> I suppose it all depends on what you want to do with your web server. 
> I'm not suggesting that a VMS web server could or should do anything 
> any other web server can do. It's like with buying a car, you can buy a 
> very amall one, a big one, a sports car, a saloon, a station wagon, a 
> pickup, it all depends on your needs and wishes.
> 
> And if a VMS webserver can do the things we need it for, then that is 
> good enough.

Trying other server platforms and tools means you'll know much more 
about both the sorts of things that OpenVMS does better, and the things 
that OpenVMS does worse.   OpenVMS still solves the same sorts of 
problems that were common back in the 1980s and 1990s, but those sorts 
of problems aren't necessarily the sorts of problems and limitations 
and environments that many folks are working with now, and interested 
in acquiring servers for now.   OpenVMS also solves many of those 
problems in ways different from other approaches; not necessarily for 
the better.  Those 1980 and 1990 data centers and configurations 
basically don't exist anymore, outside of a few parts of the installed 
base.

If you're not looking around and learning about other approaches and 
other tools and other platforms, then your ability to even try to 
discuss and to promote OpenVMS — if that's your goal here — will be 
poor.   Beyond the basic marketing and comparisons, you'll also have 
the sorts of technical issues around just managing and supporting 
OpenVMS servers, as there'll be requests to integrate with various 
newer tools — everybody's managing more and more servers, or deploying 
more and more, or reconfiguring, etc.

You might learn that if you're going to be different, then you usually 
need to bring specific advantages over the other approaches.  Being 
different because you're better integrated with OpenVMS might not be 
something folks evaluating OpenVMS care all that much about, for 
instance.  The folks might prefer a better-integrated Apache, for 
instance, because that means they can use their Apache skills and 
tools.  Existing OpenVMS Apache users will probably want to see that 
continue, which means that Apache will either continue and that adds to 
the work, or it gets deprecated and that might be a problem for some in 
the installed base.

To repeat some of my comments from a boot camp a whole back, OpenVMS is 
far too piecemeal in its installation and configuration and management 
— there are other platforms around which are *massively* better at this 
— and I'd really like to have what are now core features — web services 
among those — in the base distro.  Apache would be the local 
preference, just because that's familiar to many, already present, 
already in use, and very common in the industry.   But whether that 
integrated web server becomes WASD or Apache or nginx or something else?



-- 
Pure Personal Opinion | HoffmanLabs LLC