Visions of multi-tenant MiServer

[woody]

Greetings, MiServer gurus.

We have been making good progress at APLcloud.com as we strive to master MiServer and provide a friendly and effective Web-Based Dyalog APL hosting environment.

Our dedicated Windows 2012 servers with Dyalog APL and MiServer have been selling like hotcakes for only $40 per month (USD).

However, we have discovered that there is a large back-end support effort required to help our customers keep their Windows Servers, Dyalog APL, and MiServer systems up-to-date! It is difficult to support our APL users when they are spread across different versions of software.

So, we have been working on a new concept. Well... I should say.. a rebirth of an old 1970 Time Sharing concept.. that, today, we call "Multi-Tenant Cloud Computing" (aka "time sharing").

The idea is driven by the fact that our infrastructure provider (Amazon AWS) offers an excellent service. And, we can quickly add more CPU, RAM or DISK space to any of our APLcloud virtual servers on demand and anywhere in the world.

Then, it follows that it may make sense for us to offer services that share ONE BIG APLcloud Server that runs multiple on-demand instances of MiServer.

If we can go this way, we can greatly reduce our cost, and can pass that on to our APL customers. In addition to cost savings, this model can provide scalability and reliability and make it much easier for APLers to develop and support their applications on the Internet.

Attached is a conceptual diagram of the new proposed multi-tenant MiServer system. Our plan is to deploy a centralized multi-tenant MiServer computer at each of the 7 regional Amazon computer centers.

Feedback and comments are greatly appreciated.

All the best,

//W

(Click to enlarge image)

[MikeBa]

Woody,

I probably misunderstand your proposal, so forgive me for a cautionary note relating to centralized software updates. Is there a danger of swapping gentle, albeit expensive, ripples of demand on your customer support team, for a tsunami of problems followed by long periods of very low demand.

Perhaps you would need a strategy that includes:-

1. Impending update warning system
2. Pre-update testing by tenants

Given that Sod's law dictates that some tenants will still have issues, you may need to:-
3. Revert to the previous version, either (a)automatically and imperceptibly in the event of a tenant software crash, or (b)immediately when requested by a tenant experiencing subtler issues.

Any tenant who has reverted to the previous version would need to be coerced to change their software quickly, otherwise you will end up supporting multiple versions anyway.

You will probably come under pressure from some tenants who want the latest 'must-have' feature and demand the latest versions of Windows, Dyalog and MiServer.

Alternatively, APLcloud's contract small print could include "we accept no responsibility for problems following a software update". ;-)

Jeremiah Mike

[woody]

Good thoughts. And thanks for the feedback!

Yes.. we should include a Sandbox environment for each APLer to use for their applications.

I think we can install multiple versions of Dyalog APL and MiServer on the same central APLcloud server.

And, will provide a central web-based control console page that APLers can use to manage their instances of Dyalog (versions) and MiServer (versions).
1. Monitor, stop, start MiServer (including PRODUCTION and SANDBOX environments).
2. Select available versions of Dyalog APL to use with their MiServer version.
3. Select available versions of MiServer to use with their choice of Dyalog APL version.
4. Set public HOST names, PORT#s, and share status (password or open access)
5. Enable application logging

In addition, we will offer a set of MiServer developer and debugging tools (APLscript).

For example, the ability for an authorized APLer to "monitor and query" their live MiServer session in real-time and in parallel to running their MiServer application. This makes it easy to inspect current state including headers (req.Headers), MiServer system variables, functions, session variables, namespaces, DCF components as well as other libraries and files used by their application. (APLscript is currently in BETA testing)

APLscript tools also offer commercial features for each APLers applications such as user enrollment, email relay, Web Services, credit card processing (we are partnered with Braintree for global payment processing).

As new versions of Dyalog APL and MiServer are rolled out, we can offer these as options to the APLers. First in Sandbox mode. Then, as an optional configuration in production mode.

Users can select Dyalog APL 14.0 and MiServer 3.0. Switch to Dyalog APL 14.1 with MiServer 3.0. And, can easily revert back to the configuration they want.

More detailed thought needed ... but, Yes, we need to support the SDLC (change) process.

Thanks!

//W

(Click to enlarge)

[Brian|Dyalog]

Hi Woodley,

This looks like an interesting idea. Obviously there are a lot of design details to iron out. Please keep me in the loop and/or call upon me if you want to kick some ideas around.

/Brian

[woody]

(Click to see larger image)

Greetings!

We have made excellent progress toward the goal of offering MiServer on a multi-tenant hosting platform.

Our new multi-tenant Windows front-end application server works very well.

The big performance improvement is that IIS works as the front-end web server, and takes the "load" OFF of Dyalog APL MiServer.

Both IIS and Dyalog MiServer SHARE the same Windows folders ...

This allows any HTTP request to a *.Dyalog (or any *.Mipage) to be routed directly to MiServer running on LOCALHOST:80xx (an assigned local PORT# e.g. 8001 or 8002 .. etc.). This can be a good business model that keeps APL and MiServer "behind the corporate firewall".

APL MiServer executes the requested page and sends back the rendered HTML PAGE to the user's browser ... THROUGH the IIS Reverse Proxy. The same is true with Web Services and sending back JSON or XML.

When the requested HTML page is received by the user's browser, all subsequent HTTP GETS for graphic images, JS files, or CSS files (anything other than *.dyalog or *.mipage) are instantly processed DIRECTLY by IIS (MiServer is not bothered with these subsequent file requests)

The result is MUCH faster performance .. as MiServer ONLY runs APL code, and generates HTML PAGES (or JSON/XML DATA) ... and does not get BOGGED DOWN sending back dozens of IMG files to hundreds (thousands) of browsers.

Further, the back-end MiServer CAN RUN ANYWHERE. It can run as LOCALHOST:80xx on the primary APLcloud IIS server ... OR at another external location anywhere on the internet or behind AWS firewall on private internal IP address. (The missing piece is to establish an iSCSI shared drive that allows sharing of MiServer FOLDERS and FILES with the front-end server .. we are working on this last step).

We are building this to make it much easier for "users" (APLers) to quickly "sign-up" at APLcloud and quickly write APL-based web applications. Users can choose to let APLcloud manage their instance of MiServer ... or they can choose to be full Admins over their own MiServers. (This also provides support for both Windows and LINUX versions of APL and MiServer)

This new architecture allows a hybrid of web languages for the same web domain .. .ASPX, .PHP, .DYALOG (or .MIPAGE), etc.

Our overall strategy is to provide a robust and "friendly" platform where EXISTING Web Page Templates, and Applications can be INTEGRATED into the World of APL. This allows a user to start with a solid HTML template or PHP application, and then augment with APL where needed.

Of course.. the full capability of MiServer is also available. We can simply change the PROXY rule to allow *.* (all HTTP requests) to route to the target MiServer.

Best of all worlds!

Visit our prototypes at
http://central.aplcloud.com
http://APLWS.com
http://APLscript.com


Here's the diagram... (more to come!)

(Click to see larger image)