Alpha Cloud - Alpha Anywhere Developer's Guide

Frequently Asked Questions


How does the choice of tenancy (Public, Subscription, Dedicated) affect upgrades to applications and the Alpha Anywhere Application Server for IIS builds?

What about cloud based database support?

What happens when a Windows instance needs to be restarted? Won't it shut down all the running application server instances?

Could one tenant shut down someone else's running application server?

Can you have multiple MySQL database servers (one install for each tenant) running within a single Windows instance?

I want to create a MySQL database on Amazon RDS. Is there anything I need to consider?

Does Alpha Cloud use redundant IIS servers?

Do you have a service level of responsiveness and throughput for sites?

Do you auto-scale as needed?



How does the choice of tenancy (Public, Subscription, Dedicated) affect upgrades to applications and the Alpha Anywhere Application Server for IIS builds?


The Alpha Cloud deployment environment is deliberately architected so a single Windows instance can host multiple applications under multiple web sites. Each application is configured independently for a specific Alpha Anywhere Application Server for IIS version and build.

Regardless of tenancy, you can have as many application deployments as IIS can support; with each deployment pairing a specific version of your application and a version and a specific build of the Alpha Anywhere Application Server for IIS mapped to a web site (such as http://www.mycompany.com) and web application path (such as http://www.mycompany.com/ or http://www.mycompany.com/application1/ ).

When you publish:

  • We make a uniquely sequenced version of your application and store it on Alpha Cloud.

When you deploy:

  • You can choose any build of Alpha Anywhere Application Server for IIS that we make available to the cloud as the build that you want your application to run under.
  • You can choose any version of your application and assign it to an IIS application path under your web site.
  • You can also choose to publish and deploy in one operation. In this case, your latest version is published and deployed.
  • Deployments are actually "scheduled", so you can schedule a change in a number of deployments to occur. For example you might schedule a deployment to occur around midnight.

You choose when you will switch the version of your application and when you will switch the build of Alpha Anywhere Application Server for IIS for a given deployment. Each deployment can only have one build of Alpha Anywhere Application Server for IIS and one version of your application at a time.

For example:

  • You might deploy a your accounting application (version 5) to production as: http://www.mycompany.com/Accounting and choose build number 2727 of Alpha Anywhere Application Server for IIS.
  • At the same time, you might deploy the upcoming version of your accounting application (version 6) to test as http://www.mycompany.com/QA/Accounting and choose build number 2790 of Alpha Anywhere Application Server for IIS.
  • Or if you prefer, you can create a separate DNS for test systems like http://test.mycompany.com/Accounting.
  • You could also use the unique URL we generate for each web site you deploy and not bother to assign the QA website or other development web sites to your public DNS name. The URL would look something like this: http://mycompany-QA.cloud.alphasoftware.com/Accounting.

Tenancy affects how your web sites are assigned to servers when one or more applications assigned to a web site are deployed. You can deploy any version of your web site to any build of Alpha Anywhere Application Server for IIS regardless of the tenancy choice. Once again, the options are:

  • Public - You share one or more Windows instances with other subscriber web sites; a more economical approach for light usage applications.
  • Subscription - You share one or more Windows instances among web sites defined by your subscription.
  • Dedicated - One of your web sites has one or more Windows instances all to itself.


What about cloud based database support?


Alpha Cloud does not provide database hosting at this time; though we may add it as a service in the future. You will need to create your own database and provide a connection string when you publish or deploy your application.

There are several options for database deployment, and we recommend that you choose a hosting provider for your database located near to the region where your application is deployed on Alpha Cloud.

  • You can create an Amazon account of your own and provision a database on Amazon. This is done by creating an Amazon Relational Database Services (RDS) instance. Amazon currently supports MySQL, SQL Server, PostgreSQL, Oracle, MariaDB and an Amazon service called Aurora (MySQL compatible).

    The video below walks you through creating an Amazon RDS MariaDB instance and database and connecting to it from your development machine and Alpha Cloud.


  • Alternatively, you can deploy your own Amazon instances and provide connection strings to them.
  • You always have the option of providing access to your in-house database. Watch out for latency issues and make sure your connection is secure.

Wherever you choose to host your database, make sure you review the Alpha Cloud documentation and restrict access from outside your firewall to only those addresses from which Alpha Cloud will attempt to connect to your database. A secure connection (TLS/SSL) is highly recommended!



What happens when a Windows instance needs to be restarted? Won't it shut down all the running application server instances?


While it is easier to think of a server as a Windows instance, it is really a collection of servers. You will see it referred to in the documentation as a "server group" - a collection of servers. That is actually more correct. The group of servers runs behind a load balancer. As a result, recycling a single instance will not stop your application from responding.

  • In order to increase availability and scale, we will be running at least 2 Windows instances for each server group, all behind a load balancer (Amazon calls this an auto-scaling group).
  • These instances will be running in separate data centers (called availability zones) in a tightly coupled geographic region.
  • If one instance should fail, another instance is automatically started to replace it.
  • If the overall server load increases for a period of time, an additional instance of the server is started automatically. Instances are spread across data centers to improve availability and robustness.
  • If load drops for an extended period of time, servers may be automatically stopped.
  • Technically, we don't restart servers. If a server is deemed unhealthy by the load balancer, the server is automatically terminated and another is started to replace it.
  • All of this behavior is implemented regardless of the tenancy option you choose.

Because we are using Alpha Anywhere Application Server for IIS, there are a number of features from IIS that we take advantage of.

  • One of the key features is the ability to run more than one process for a given web application.
  • Because of this, we default to up to five processes per application on web sites running under Public tenancy (Note that the actual setting may be changed in the future).
  • IIS automatically restarts processes periodically, and based on settings we provide.
  • This "restarting" is done in an overlapping fashion so that currently running requests are allowed to finish.
  • New processes are brought up while the old processes are finishing up and are ready to handle new requests.

If you are running a web site under Subscription or Dedicated tenancy, it will cost you more, but you will also be able to tune some of the behavior discussed above:

  • The number of instances in a server group.
  • The scaling behavior (thresholds and instances added/removed).
  • The number of IIS processes per application.


Could one tenant shut down someone else's running application server?


There are safeguards to prevent any application from interfering with another application or from taking control of the web server itself.

  • Alpha Cloud web applications each run in their own dedicated IIS application pool (group of processes) and have a user identity specific to that application pool.
  • The identity of the web application is restricted in terms of file access to those that belong to the application.
  • None of the web applications has administrator permission.
  • Session state and security are isolated by generating a unique machine-key for each security group. This is usually per application, but you can share security groups within your own subscription for a given region.


Can you have multiple MySQL database servers (one install for each tenant) running within a single Windows instance?


Alpha Cloud application servers do not run SQL databases on the same virtual machine. Because there will be multiple application servers running at all times and any of these servers might be terminated at any time, any data that will be accessed between requests must be stored outside the application server instances.

  • Appropriate places include session state, a SQL database or a storage container (such as S3 storage on Amazon) that persists and is shareable.
  • For Alpha Cloud applications, the session state is stored in a shared, highly available cluster (we are currently using a Redis cache cluster running under Amazon ElastiCache). This is necessary to scale requests across multiple application servers.
  • Amazon Relational Database Services (RDS) databases are collections of one or more server instances that Amazon automatically manages. For MySQL, you can set up replication and manage failover (promotion of a slave to master).

The connection string you provide for your application when you publish it can either be static, or can be evaluated at runtime, meaning that you can use multiple databases for your own users. Otherwise, the connection string is your own, just as if you deployed an application on your own server.

You can also set the connection string (and other variables) at deployment time so you don't have to include application logic to vary the connection string. For example a test database can be used with a test deployment by overriding the connection string for the deployment.



I want to create a MySQL database on Amazon RDS. Is there anything I need to consider?


There are some parameters you will probably need to set for your Amazon RDS MySQL instance:

Parameter NameValueExplanation
lower_case_table_names1Removes the case sensitivity of table names.
Warning: If a database exists when you change this, you can lose addressability to the database.
max_allowed_packet500000000If you use large binary objects in your tables, you will want to increase the size in this table.
log_bin_trust_function_creators1Set this parameter to allow you to create functions and stored procedures.

Note: MySQL and MariaDB are compatible databases and have similar settings.



Does Alpha Cloud use redundant IIS servers?


For Public Tenancy Alpha Cloud creates a minimum of two Windows server instances and each instance has as many as ten processes per application.

For Subscription and Dedicated tenancy you can set the minimum and maximum number of instances and processes yourself. You could run with an auto-scaling group with just one instance, but we do not recommend it.



Do you have a service level of responsiveness and throughput for sites?


For Public Tenancy Alpha Cloud sets the CPU utilization threshold and how long that threshold must be exceeded before an additional server is added. Amazon AWS Autoscaling does the work for us. We will monitor and tune this over time to maximize throughput and minimize cost.

For Subscription and Dedicated tenancy you can set the value yourself along with other auto-scaling parameters. Server instances are currently Amazon AWS t2.medium instances, but that may change.



Do you auto-scale as needed?


Alpha Cloud always uses auto-scaling for redundancy and horizontal scaling. Every deployed application is auto-scaled behind a load balancer. For Public Tenancy Alpha Cloud set the CPU utilization threshold and how long that threshold must be exceeded before an additional server is added. Amazon AWS Autoscaling does the work for us. We will monitor and tune this over time to maximize throughput and minimize cost.

For Subscription and Dedicated tenancy you can set the value yourself along with other auto-scaling parameters.