In Virtualizing Applications with Delphix - part 1, I discussed the methodology for identifying candidate applications for virtualization. In this article I will discuss what I do with the outputs from applying that methodology. As an example, I will leverage the application from my recent blog post, SugarCRM Community Edition (“Sugar”). When I was first approached by my boss about possibly virtualizing Sugar with Delphix, I knew very little about the application other than they had a lightweight and free application that was a popular alternative to big industrial (and expensive) CRM applications, who shall remain nameless. With no in-house expertise on Sugar, I began seeking out the answers to the questions from Part 1 via the internet and through experimentation. Here’s the shortlist of what I discovered (answers in parenthesis):
Understand the Architecture of the Application
- How many tiers? (2)
- What is the purpose of each tier? (1 Web Application, 1 Database)
- How does each tier communicate with each other? (Apache Web Application => MySQL)
- How many nodes? (1)
- Does the # of nodes and tiers change? (i.e. Dev vs QA vs Prod) (N/A)
- Is the application stateless? (No)
- Does the application leverage/utilize an RDBMS? (Yes, MySQL or Oracle)
- Does the application leverage the file system for caching or high-transaction temp? (No)
- After the initial installation and configuration, what changes in the environment?(There are some configuration objects that are stored on the application tier, such as the company logo).
- Where do those changes get written? (
- What is the I/O driven at the various components (filesystem, dba, etc) ? (lightweight)
Understand the Backup, Restore and Continuity of Operations Process of the Application
- How is the application backed up for DR? (The application has a backup tool that stores the entire contents of the htdocs directory in a compressed tar ball. The database component is backed up separately via RDBMS tools.)
- How is the application configured for HA? (N/A)
- If the power plug on one, or all, of the application tiers were pulled, what would be the process to get the application running again? (Simply starting the database, then application)
Understand the Non-Production Lifecycle
- How are non-production application instances created? (Create a database from production backup and extract a copy of the application from compressed tarball into a working apache installation. Both DB and App backups need to be in sync.)
- How are non-production application instances refreshed? (Same process as above)
- How are non-production application instances reset after destructive actions? ( i.e. destructive testing, misconfiguration, corruption" (Same process as above)
- If non-production instances are masked, how is the masking performed today? (N/A)
- What I/O loads are typical for non-production instances? (Lightweight)
Since I wasn’t trying to capture an application that was really running in our production infrastructure, and the architecture was mine to determine, the key question from the list was “How is the application backed up for DR?” With a little research and exploration, I was able to see that Sugar leverages the native tools of the RDBMS (in this case MySQL) and also has an application tool to archive the entire application. As Sugar leverages a Delphix-supported MySQL DBMS, I knew this piece would be as easy as linking Delphix to the sugarcrm database. Following the Delphix documentation, I linked the Sugar MySQL database and performed an initial sync, which created a full compressed and filtered copy in the Delphix Engine. I also enabled LogSync so that my Delphix Engine would stay in near real-time sync with the Sugar DB. Probing a little deeper into the native application-level backup, I was able to ascertain that the backup utility simply creates an archive of the Sugar application sub-directory of the Apache installation (i.e., /var/www/apps/apache/htdocs). And this answers an important question when trying to determine how to virtualize the application: Where does the application really live? I could have just virtualized the whole apache application, as I did to create our Employee WebApp use case. But, while that is a simple straightforward approach that may work in some circumstances, I wanted to virtualize this in a more realistic format. In the case of Sugar, Apache is the supporting application. If I am a Sugar developer/admin, I may want to deploy my Sugar Application into different environmental configurations for development and testing. For example, perhaps my company is making a move from Oracle Linux to Redhat Linux, or perhaps we are changing from one specific LAMP stack to a XAMPP stack, or perhaps we are looking to depart from a monolithic development and deploy our Sugar application into a containerized environment (like Docker). In short, by boiling Sugar down to its most base components, we are able to make the virtualization far more portable and compatible to the ever changing needs of our environment. In this case, by virtualizing only the Sugar application data (and not the Apache application) we are able to develop, test, and QA the same application data in all three scenarios, though the apache versions may be different or configured differently. This is the same approach that we take with Delphix as it relates to databases. We virtualize the data of the databases, but not the RDBMS itself (i.e. the Oracle binaries). This addresses the majority of the problem in the Oracle world. That being said, we do have use cases where Delphix is virtualizing Oracle Homes as well for some specific use cases and challenges. And indeed, in the Sugar case, you may want to also virtualize the Apache application too, and if you have such a need, it can be done. But, as with any problem you are trying to address, you must look at it from a needs/benefits perspective. After I identified what application data to virtualize, I then contemplated how to deploy it. In my case, I decided to deploy both tiers to a single system. Also, for my demonstration purposes, I deployed Sugar into a XAMPP stack with a newer version of Apache (my source was from a FastStack installation of SugarCRM Community Edition). After deploying the Sugar application data into the Apache directory, what next? I could have just manually reconfigured Apache and restarted the application to bring up Sugar, but I decided to create a simple script for Delphix to execute when Sugar is provisioned and refreshed. In Delphix, there is an easy way to attach and call this automation via our “Hooks” screen in the provisioning window. How much automation you want to provide via Delphix is up to you. If you have existing automation and self-service tools, Delphix provides open REST API’s to easily integrate Delphix into your SLDC or self-service environment.
#DemoEnvironment