![Development and Test as a Service [DTaaS]](/_next/image?url=https%3A%2F%2Fapp.trilogix.cloud%2Fwp-content%2Fuploads%2F2021%2F06%2FDev-test-arch.jpg&w=3840&q=75)
A Development and Test as a Service (also called Dev/Test) offering technically fits within the definition of PaaS with several unique features that facilitate application development, testing, and automated release management efforts.
Customers benefit from a Dev/Test by being able to quickly launch new VMs within minutes, perform testing of an application, and turn off the Dev/Test service when it is no longer needed. Because all the servers are hosted with VMs in the cloud, the consuming organization does not need to pre-purchase and deploy a dedicated server farm, sitting idly when an application development team has finished their work, or between application releases.
Dev/Test teams often utilize numerous VMs residing in on-premises private cloud facilities or in a public cloud. Then, there are multiple work streams, multiple development teams, testing and quality assurance teams, and multiple versions of each application being developed simultaneously—all of this benefiting from the elasticity and pay-as- you-go features of a private or public cloud.
A good example scenario is when the application development team needs a new 10-computer environment deployed. With one purchase via the cloud management portal, 10 new VMs are provisioned with two clustered SQL servers, two frontend web servers, two middleware application servers, and four QA workstations (to be used by the development team for testing).
Upon launch, the application team can load its custom application code and begin further programming or testing. It can add or remove additional VMs as needed or take a “snapshot” of the environment, test the system, and roll back the entire 10-system environment to the snapshot state, retrying its test each time based on the snapshot image.
——
Specific features of a Dev/Test environment are detailed in the list that follows (the basic offering and systems architecture is the same as IaaS, which means there is a pool of physical servers, each running a hypervisor system providing capacity for hundreds of thousands of VMs on-demand):
Many organizations have strict policies and procedures that must be followed whenever a new VM or application is installed in the production net- work. In a Dev/Test environment, the application developers need to have the ability to quickly bring VMs up, reconfigure them, install application code, test the code, and then shut the systems down. All of this is performed regularly during the time a development team is creating its application for production release, and can last for months. For the developers to have this freedom without being restrained by paperwork, isolating the Dev/Test network from the production network using a firewall is a common technique.
Even if both the production and Dev/Test networks are hosted by a cloud provider, organizations want to protect their production network from untested or new application code. Some Dev/Test systems provide a separate subnetwork for each application project, so that one application development team cannot interfere with others. This protects other development teams from such possibilities as an untested, “run-away” application clogging the network with traffic.
The ability of the application development team to make a backup or snap- shot of a VM—or the entire environment. This snapshot saves a copy to disk and makes it possible for the development team to run numerous copies of its system. It can perform testing against a copy of its environment rather than on a single instance, and avoid potentially messing it up.
If testing is successful, a rollback of the environment is not necessary, and this set of VMs would become the new baseline release. This feature is a very significant benefit of using VM/ hypervisor technology, and by paying only for the usage of VMs and storage, the consuming organization truly benefits from on-demand just-in- time provisioning and shutdown in developing its application projects. Creating numerous copies of VMs with many different versions can consume a great deal of storage space; thus a great deal of storage space can be required by the system. To keep costs low, delete older copies that are no longer needed.
Many application development teams use ALM tools to help coordinate and facilitate the development process. You can install these tools on one or more VMs within the cloud, alongside the application VMs and database systems. The application development team uses the ALM tools to track its project milestones, maintain a code repository, perform QA checks, perform load testing, and promote application revisions from Dev/Test into production.
Popular ALM suites in the industry include offerings from Microsoft, IBM, and Hewlett-Packard. There are also smaller tools, and even open source tools, that an application team can use. Additionally, some cloud service providers that offer Dev/Test will offer the ALM suites as an option—this is a nice benefit, because the ALM suite will already be configured and ready for use upon ordering, and the licensing costs the cloud provider charges might be less than a single customer would pay for its own copy.
Some Dev/Test offerings provide the application development team with the ability to promote individual or multiple VMs to the next phase of the application lifecycle. For example, when all testing of an application release is completed in the Dev/Test environment, clicking a “promote” button would automatically copy or move the VMs to a staging or production network within the cloud provider’s datacenter, facilitating an Agile software delivery and continuous application delivery automation.
An additional benefit to the customer is the ability to launch a new release of its application into production while maintaining the availability of its Dev/Test environment for the next release. If the Dev/Test VMs are no longer needed, they can be de-provisioned and the customer stops paying for them. The below figure shows a Dev/Test network with multiple isolated network segments for development, testing, and production.
Figure 1: Sample Dev/Test architecture
Pricing for Dev/Test offerings is typically in the same range as multiple VMs within an IaaS—any ALM tools you purchase will of course incur additional charges. You pay either a fixed fee and/or variable fees each day, week, or month for using the VMs and storage. You can pick your VM sizes, OS templates, and storage amount just as you would in production. You often don’t need as large a VM in Dev/Test as you do in production, because you are usually not running simultaneous production users (unless you are using your Dev/Test service for load testing and quality assurance). This can result in savings by ordering smaller, less powerful VMs in Dev/Test.
Figure 1 shows a Dev/Test network with multiple isolated network segments for development and testing and production. In theory, there could be even further network segmentation for the Dev/Test and production portions of this notional architecture and for each unique application or development team. We intentionally do not indicate whether this is a private or public cloud.
Many organizations utilize public cloud for its significant elasticity and no initial investment in IT assets that a private cloud requires. Some organizations use a combination of public and private clouds to do their development testing and hosting of production applications using ALM tools to replicate, synchronize, or promote development code between environments.
