Managing Software and Site Deployment on Alibaba Cloud

This tutorial explains some of the key considerations when deciding how to separate your development, test, and production infrastructure with Alibaba Cloud.

When deploying cloud-based services and websites it's important to separate your development, test, and production infrastructure. This tutorial explains some of the key considerations when deciding how best to achieve this with Alibaba Cloud.

Prerequisites

To try out the suggestions in this tutorial you'll need an Alibaba Cloud account. If you don't already have one, head to www.alibabacloud.com and sign up. To help you try out the facilities you'll find a range of free trials there, including the ability to create Windows and Linux servers.

Background

Deploying a cloud-based service such as a website, an internal system for your company, or an app's back end, is very simple with Alibaba Cloud. You can simply spin up one or more cloud servers and database instances, develop your application on them, and then release it to your users.

However, in order to ensure optimum reliability, security, resilience and customer satisfaction, it's essential that you maintain two or more separate deployment environments. In this tutorial we examine the best ways to achieve this, and how to implement these methods on Alibaba Cloud.

The Need for Separation

Software development typically involves a number of stages as the code works its way from an idea to a prototype to an evaluation platform to a fully launched system. Sometimes these stages are carried out by different teams, in which developers and testers rarely work on production systems or are involved in deploying code and data between stages. But the recent trend towards people who combine a role in both development and operations, so-called DevOps, is changing the landscape. With DevOps, developers are often also involved in deploying their code onto production servers.

Whether the software development takes place on local workstations or in the cloud, the full software deployment lifecycle typically involves up to four computing environments, known as development, test, staging and production. Their purposes are as follows.

Development

Dev machines are the computers and servers on which developers do their day-to-day work. Because of the extensive collection of software tools that developers require for coding and debugging, development machines never mirror those that will hold the final product. Security restrictions are often turned down, for example, and there may be multiple versions of key libraries and other components installed. Development machines should therefore not be used for testing.

Test

Testing machines are where code can be tested in an environment other than one that is used by developers. Test machines are often used for testing or evaluating specific situations or items, rather than the entire product suite. For example, trying out a third-party library you're considering purchasing, against a small sample of the main dataset.

Unlike dev, staging and production machines, it's common for test machines to be frequently destroyed and rebuilt. Sometimes this could happen multiple times in one day, depending on what is being tested and on the results of the test.

Test machines are also sometimes used by those involved in producing documentation and guiding user experience to research the effects of certain actions and conditions. They may need to repeatedly perform a test, destroying and recreating the server each time, in order to establish the precise set of steps that a reader of the documentation will need to complete.

Staging

Also known as pre-production or pilot. Staging servers are (or should be) an exact or near-exact mirror of the production servers. They provide a place to perform acceptance and load testing before a service is released to end users or paying customers. No development should take place on staging servers, except minor configuration changes, which should then be carefully documented.

If performance is not critical, you can save on costs by using smaller and less-powerful instances for your staging servers, compared to production ones.

Your staging servers are the place for testing your deployment and build processes and automated or manual data migration. Always deploy from development to staging servers before deploying to production ones. As part of your procedures, you should have rules in place (both documented processes and access control lists) which specify who is allowed to deploy code to staging and production servers.

If you work for an agency, a staging server is useful for allowing clients to test a product that you are in the process of developing. In a corporate environment, the staging servers allow product managers, documentation specialists, industry journalists and other key stakeholders to have advance access to a service.

A staging environment is rarely just a single server. It's a way of testing all the key components together, such as web server, database instance, firewall rules, authentication, storage, auditing and more.

Because staging servers are identical to the production environment, it's a good place for tech support staff to try to reproduce a mission-critical reported bug without affecting the stability of the live servers.

Staging environments can also be used for testing your backup and disaster recovery procedures. If you can delete and then rebuild the staging environment, either via your automation scripts or by restoring from backups, then you should be able to do the same with the production environment if the need ever arises.

It's common for staging environments to occasionally require a complete rebuild, if the staging environment becomes significantly different from the production one. For example, if a new functionality had been deployed to the staging environment but it was subsequently decided not to include that in the production version of the system.

Production

Production servers are where the final, released product or service resides. They're also known as the live servers. No development, and ideally no testing, should be performed on the live system. Minor changes such as configuration adjustments should always be tested in the staging environment first.

Theory vs. Reality

The ideal scenario is to maintain four server environments, as described above. Code is then developed on dev servers and flows through the test and staging systems on its eventual journey into production.

However, not every organization has the human and financial resources to sustain four deployment environments. The number you require also depends on the nature of your industry, any regulatory requirements, the size of your development team, and the geographical spread of developers and testers.

As a minimum, we highly recommend that you maintain two server environments: one for production, and one for everything else. This will at least provide some degree of separation between customer-facing systems and those which should not be exposed to such a wide audience.

Recommendations and Techniques

In the remainder of this tutorial we will examine some useful ways to manage software deployments on Alibaba Cloud and to handle your multiple environments. Depending on your particular circumstances you may wish to implement all of these suggestions, or just a selection.

Separate Accounts?

When creating a cloud-hosted service or product, the ultimate means of separating deployment environments is to use separate Alibaba Cloud accounts. Perhaps keep one account for production, and one for everything else. Or if there's a need for it, maintain four separate accounts for dev, test, staging and production. This is the ultimate way to ensure that any communication between components in different deployment stage environments can't be done accidentally. It's also a great way to manage budgets and expenditure by keeping them isolated from each other.

To create a new Alibaba Cloud account simply head to www.alibabacloud.com and click on the Free Account button. You'll need to set up a payment method for the new account, which can be a credit card, PayPal, or both.

Separate VPCs or Regions

If you prefer to maintain just one Alibaba Cloud account, there are other ways to separate your groups of servers and related infrastructure such as databases instances, virtual switches and routers, subnets and so on. You can create multiple VPCs (virtual private clouds) and use one for each deployment group.

By default, servers can't communicate across VPCs, but you can enable this via the use of the Express Connect product. Find out more at https://www.alibabacloud.com/product/express-connect

Express Connect can be used to allow communications between servers on different VPCs and even across different user accounts.

Another option is to use different zones or hosting regions to separate production servers from non-production ones. Each of Alibaba Cloud's 19 hosting regions has at least two zones, and some have up to seven. By default, servers can't communicate across zones, so this helps to enforce separation. In addition, it's not possible for someone to inadvertently attach a server to the wrong VPC because a server and its VPC need to be in the same region and zone.

Naming Conventions

Use a formal naming convention for your instances so that everyone is clear about their purpose. For example, when naming new servers or ApsaraDB RDS instances, or any other item such as a VPC or security group, add a prefix such as:

dev_

test_

staging_

prod_

If you're using Windows servers, or Linux servers that include a GUI, consider setting the desktop background color or wallpaper to provide an instant indication as to the nature of the server. For example, set the desktop color to solid dark red on all production servers, and green on staging servers.

Building Test Servers

Sometimes you just need a test server for a short time, to try out a new function or idea. On Alibaba Cloud, creating ECS servers via the web-based console is quick and easy. In addition, you can automate the process by using Terraform, an open source product which supports Alibaba Cloud in all recent versions.

You can download it from www.terraform.io

Automating your server builds ensures consistency, which is important if you need to be certain that your staging architecture is the same as your production setup, or if you frequently need to build new staging environments for short one-off tests that will then be released. Terraform scripts are JSON-based and human-readable, so it's easy to adapt or edit them.

For short-term tests, choose the pay-as-you-go billing method for your cloud instances rather than a monthly subscription. If you only need it for 10 minutes, that's all you'll pay for. If you need the test server to remain in place for longer but you don't need continuous access to it, stop it when it's not needed and it won't accrue any charges.

Set an expiry date and time when you create a test instance, in case you forget later. This will help to keep costs down. Additionally, if the precise hosting region isn't important to you, check the prices in each region as some are cheaper than others.

Separation of Data

ApsaraDB RDS instances on Alibaba Cloud let you create databases without the need to maintain the underlying server OS too. Choose larger instance sizes (more processors and RAM) for production databases and save on costs by using lower-specification instances during test and development.

When your software project includes one or more databases it's obviously important to ensure that production, development, test and staging databases remain separate so that no one can inadvertently make changes to live data during testing and development. Without proper separation, it's all too easy for incorrectly configured code in, say, your staging environment to inadvertently connect to the production database instance. By the time you discover the mistake, testers on the staging server have made changes to live data. Clearly this is a situation that you need to avoid. By creating separate VPCs, and placing database instances in the correct ones, you can ensure that staging servers, for example, can't communicate with the production database by default. This means that the errant code simply wouldn't work.

You may not need to work with the full production datasets during testing and development, so choose smaller cloud disks and less powerful ApsaraDB RDS instances to keep costs down in environments other than production.

As with conventional ECS server instances, ApsaraDB RDS databases instances are billable either by monthly subscription or pay-as-you-go, with the latter starting from just $0.05 per hour. For short tests, always choose pay-as-you-go.

The Hybrid Option

If your main data center is still in-house and you have yet to fully move to the cloud, you can still use Alibaba Cloud as part of your hybrid setup. Buying hardware specifically to use as test or staging servers can be uneconomical, especially if it's not used 24/7. Instead, create pay-as-you-go instances on Alibaba Cloud when required and delete or stop them when they're not in use. Reserved instances allow you to pay up front for vouchers that can then be used to create pay-as-you-go servers. If you pay the full amount up-front for three years' usage, you save an amazing 45 percent compared to the standard pay-as-you-go rates. If you subsequently decide that you don't need the vouchers you've purchased, you can apply for a refund.

If you need to run specific tasks (such as large-scale data conversions) but you don't mind when they run, consider using preemptible instances. Here, you bid for the per-hour price you're willing to pay for your server, in a market that changes according to supply and demand. When the market price becomes lower than your bid, your server automatically starts running. It is then guaranteed to run for at least an hour. It will stop when you have specified that it should, or when the market price becomes higher than your bid, whichever comes first.

Summary

A wise IT consultant once said that, if you only have production servers and no test servers, the harsh reality is that you actually only have test servers and no development servers. In the interests of security, compliance, resilience and best practice, it's very important not to use production machines for development and testing, and not to expose dev/test machines to the entire world.

As we have seen, staging servers are incredibly useful for a wide range of reasons. They can be used for almost anything, except for running the actual production or live environment. Therefore, even if you don't need development or test servers because it all happens in-house or on developers' workstations, it's really important to create a staging environment that mirrors production, but can be used for general quality assurance and disaster recovery testing.

Alibaba Cloud makes it very easy and cost-effective to maintain separate IT infrastructure for development, testing, staging and production, and to deploy code between them only when required. In this tutorial we've explained the benefits of maintaining separate systems and shown some examples of how to achieve it when using Alibaba Cloud.

To try all this for yourself, just head to www.alibabacloud.com If you don't already have an account it's free to sign up, and there are lots of trial offers available that allow you to evaluate most of the services for free, including creating Windows and Linux servers, without incurring any costs.

If you already have one Alibaba Cloud account but you're considering using multiple accounts to maintain separation between deployment environments, you can easily set up an additional account by following the same procedure.

Community