If you’ve ever looked at cloud server prices, or deployed a cloud server instance, you’ve likely noticed that most providers have a selection of “templates” to choose from. Users browse and select from a library of pre-baked server templates that contain combinations of compute, storage, operating systems, database technology, web servers, and commercial software. This isn’t the approach we take at Tier 3, however.
We see at least two challenges with templates.
- Impossible for providers to match complete need, and difficult for customers to maintain custom templates. The number of templates offered by leading cloud providers range from dozens to thousands. With templates, the provider aims to offer as many useful combinations of OS + software as possible. However, this requires providers to engage in an endless quest to assemble server images that are useful to customers.
What if the customer doesn’t see anything they like? Sure, you can upload custom templates, but that shifts the maintenance responsibility to the customer. The provider may have automation tools available for updating and patching images, but enterprise IT departments may not have the necessary capabilities to do the care and feeding of a custom template library.
- Not a complete replacement for the way enterprise IT builds servers today. IT organizations don’t typically rely on a library of server templates when they build new machines. Instead, they follow a more assembly-line approach to stand up a server for a particular system. This includes selecting the operating system, joining a server to a domain, adding storage, and installing the relevant software. Advanced organizations have software catalogs that help with automated installation, but many companies still rely on physical media or installation files residing on shared network drives. So what’s the problem? We find that a template-driven model can give a misleading sense of deployment speed as the server is *available* quickly, but still requires a significant number of follow on tasks until the server is actually enterprise-ready.
So what is Tier 3’s model?
The Better Way
Instead of relying on templates, Tier 3 offers a reliable orchestration engine (called Blueprints) that lets you choose what software and script commands to run when creating a new server.
There are three things that our customers like about this.
- Match unique needs through just-in-time software combinations. It’s impossible to pre-build server templates that match the individual needs of each customer. While a good template can serve as a foundation for subsequent manual activities, we went a step further. We offer a diverse set of base operating system templates, and offer a catalog of enterprise software products that can be layered on after the server is built.
The logical – and automated – extension to how IT builds servers today.Building a server isn’t just about installing an operating system and some software. System administrators go through a series of activities to provision storage, join network domains, acquire IP addresses, disable unnecessary services, and much more. Besides just offering a software catalog, we also provide a series of tasks and scripts that you can run against a new server. Tasks include activities such as adding a (public) IP address or taking a snapshot of the new server.
Scripts are commonly used to configure the server (and its corresponding software). Tier 3’s build process lets you run a variety of scripts to get your server into a finished state.
Extensible to meet enterprise standards. We won’t claim to have all the software and scripts that you need to meet your enterprise security and software standards. That’s why we fully encourage you to upload your own software and scripts into a private library just for your organization. Anything in your library can be applied to your new or existing servers.
Do you have a unique script command to run just for a single server build process? The Tier 3 Blueprints engine supports custom PowerShell, Command, and SSH script statements that get executed after the server is built.
Customers are free to create and maintain server templates in the Tier 3 environment, and some do. But we’re seeing more and more customers opt for the orchestration engine approach. This way, customers can build servers exactly how they want them, every time! Check out our tier3.com Servers and Blueprints pages to learn more about how we help you automate the server build process.
In the first article of this series, we discussed the major things to consider when looking to create a software-as-a-service version hosted on a cloud platform. One major factor called out in that article was the need for a solid hosting environment. In this article, we will look at how to use the Tier 3 Enterprise Cloud Platform to package a web application for SaaS provisioning.
To provide some real-life applicability to this article series, let us work with a fictitious, but realistic, use case. Elections to government posts are a regular part of most societies and it’s becoming increasingly critical for candidates to have a robust web presence. Let’s imagine that a web developer successfully built a web site for a local candidate and has realized that this site template could be reused by multiple candidates. Recall from the previous article that an application can be multi-tenant (and thus easier to maintain for multiple customers) in multiple ways:
- All customers could reside on the same instance of the web application and database.
- Customers can share a web application but maintain unique databases.
- Each customer gets their own web application and database instance and MAY share underlying infrastructure.
There are benefits and risks of each choice, but let’s assume that our web developer chooses option #3 because candidates will be hesitant to intermingle their donor list with others in the same database, and each candidate may want to perform some unique customizations that wouldn’t be shared by all web application users. Option #3 only works at scale if your hosting provider has significant automation capabilities that can handle actions like OS patching, system upgrades, and server scale-out with limited manual intervention. Fortunately, Tier 3 offers substantial environment automation capabilities that make management of distinct “per customer” environments entirely manageable.
Today, this web developer has a simple two tier application.
What he hoped to have is the ability to bundle up this configuration, and deploy one of these “pods” for each customer. Then, he wanted to add a single provisioning and management interface that could be shared by all the customers. The Tier 3 Enterprise Cloud Platform allows servers to be managed in “groups”, so in this case, each customer (candidate) will be provisioned into their own group. This makes billing, scale thresholds, and configuration much more personalized.
Creating Application Templates
We’re going to help this web developer out by showing the steps necessary to get his application deployed in a SaaS-y way. The first activity to perform involved creating templates of each “pod” of servers. A basic pod consists of two web servers (for a load balancing) and a single database server. Using Tier 3’s “template” technology, we can take a server and turn it into a reusable image. So first off, we needed to create a template out of the web server that had the web application installed. However, note that the database server will NOT be converted to a template as we want a fresh SQL Server installation for each new pod. Unless a specific sysprep occurs on a SQL Server machine, there can be issues (e.g. server name collisions) when instantiating a SQL Server-based virtual machine snapshot. As Tier 3 doesn’t yet offer a SQL Server-specific sysprep, we’ll rely on a bit of automation and a bit of manual intervention to get each pod deployed.
First off, we built a web server that could be templatized. In the Tier 3 Control Panel, I navigated to a Group meant to hold all of this customer’s servers.
After clicking Create Server, I selected which Group to put this server into, and chose a location, type, and name for the machine.
Next, I had the option of defining the network segment, resource allocation and server operating system.
At this point, we’ve walked through what many Infrastructure clouds have to offer when provisioning servers. What follows after that is fairly unique to Tier 3. The final (optional) step for any server provisioning is the choice of server tasks (e.g. reboot machine), software installation (e.g. SQL Server) or script execution (e.g. “install Windows Active Directory”). In this case, we wanted a server that already had the IIS 7.5 web server installed so that we could avoid doing it manually.
The Create Server button queued up the server for construction, and within a few minutes, the machine became available for access. The next step was to install the web application onto this server. By default, Tier 3 servers aren’t exposed to the public internet, so we used a VPN client to access the machine. Once connected, we transferred the web application bits to the server and created a website in IIS 7.5.
With this web server in a “complete” state, it was now ready to be turned into a template. The “server details” page on the Tier 3 Control Portal has a button called Create Template which, when clicked, crafts a reusable template from a server. These templates than then be leveraged for new servers or play a part in a Blueprint.
Building the Application Blueprint
Blueprints are Tier 3’s orchestration component which lets developers and system administrators craft complex environments that can then be deployed with a single click. In this case, we want a Blueprint that creates a pair of web servers (based on our just-created template) and a database server. This Blueprint can then be used by every customer and save the SaaS provider from manually constructing each and every environment.
This Blueprint started off with a name, version and privacy setting. Blueprints can be made public (for all Tier 3 customers) or private / private shared which restricts access to a given Tier 3 account holder.
The second step of a Blueprint involves adding servers. Our first two servers relied on the web server template that was created earlier. During the configuration of each server, we had the option of selecting server tasks, software installation and script execution activities to apply to it. For the web servers, no new software was needed because everything we needed was already contained within the template.
After defining the two web servers, a third server was added to the Blueprint. For this one, the Blueprint installed SQL Server 2008 after the machine was built.
With all the servers defined, we could then rearrange the build order, add tasks (such as software installation) and even embed OTHER Blueprints! In this case, the Blueprint was finished and could be saved. After the Blueprint was published to the library, it could be instantiated, or “deployed.” The first deployment step required us to pick server passwords, which Group to place the servers in, and since we chose to install SQL Server, we were asked for database credentials.
The second step of this wizard simply asks the user to confirm all their choices before the Blueprint runs and builds all the servers. Satisfied with our selections, the Blueprint was deployed and its status could be closely monitored.
Testing the Deployment
All three servers were now online. To finish provisioning this environment, we first needed to install the application’s database on our new database server, and then update the web application’s connection strings on the two web servers. There are new capabilities in the Tier 3 product pipeline that would automate this step, but for this example, the process was done manually.
Note that we had yet to configure a centralized management application (that’s coming in an upcoming article!), so for now, the configuration tables were also included in this website’s database. In total, the WebsiteDb database had two tables: one for storing donations to the candidate, and the other which drove the look-and-feel of the website.
The WebsiteConfiguration table described the colors used by the site, the candidate’s name and more.
Finally, the website application was updated so that it pointed to this database for its configuration and donations.
Upon browsing the website, we could see that everything was working and online.
In this article, we saw how a developer could decide to “SaaS their app” and bundle their previously-built web application into a template that could be deployed over and over again for each customer. However, deployment of the application is just one piece. In the next article, we will look at how the SaaS provider can use the Tier 3 Enterprise Cloud Platform to monitor, backup and configure their SaaS environment. After that, we will see how to use the Tier 3 API to create a provisioning and management interface that SaaS customers could use to create and configure their personal environment.
Manual environment deployments can be time-consuming and expensive. Over the years we’ve felt our customers’ frustrations: enterprise IT departments trying to be more agile in the face of business demands; ISVs that need faster time-to-money; Systems Integrators that are bogged down in repetitive work. That’s why we’re thrilled to announce the launch of Environment Engine, a toolset that automates environment and application deployments to the enterprise cloud using “Blueprints.” Blueprints contain the DNA of an environment—from host configurations, to firewall and load balancing rules, to any applications running on top. (And yes, before you ask, these tools are completely free to use for all Tier 3 customers.) With Environment Engine, the elusive IT-as-a-Service is no longer a myth. Now IT pros can create best practice-optimized Blueprints that others can use later to deploy complex applications and environments on-demand. Rollout times drop from days or weeks to hours or minutes, and because deployments are automated across the whole technology stack, build-outs are consistent and leave little room for pesky human errors. So how exactly does all of this work? Let’s get into the nitty-gritty… 1. Using the Blueprint Designer, a technical expert can create Blueprints that include host and network configurations; firewall, load balancing, and autoscale rules; and applications that will run in that environment. The resulting Blueprint can be published to private libraries for internal use or to the public Tier 3 Blueprint Library for increased exposure and adoption across organizational boundaries. 2. From the Blueprint Library, users can select the Blueprint best suited to their requirements based on variables including categories, keyword, characteristic filters such as OS or sizing, Blueprint maturity, and social feedback. 3. Because no one likes surprises on their bills, the Blueprint Builder displays estimated monthly costs of an environment, as well as any resource or software requirements. From there users can adjust pre-defined variables in the selected Blueprint to ensure proper configuration, then deploy best practice-optimized environments to the Tier 3 Enterprise Cloud Platform. Curious as to what kinds of applications you can deploy using Environment Engine? We are in the process of creating several Blueprints based on common environments, or those that may benefit from our team’s expertise. (Our goal is to expand this list over time as others publish to the public Blueprint Library and we add Blueprints to meet demand.) - Microsoft SharePoint® Server - Microsoft Exchange® Server (Single Server) - Microsoft Exchange® Server HA: Using data availability groups - Microsoft SQL Server 2008 - Active Directory - Team Foundation Services - ASP.NET & SQL Web App: Single Node - ASP.NET 2 Node Web Application: Contains front end web server and backend SQL server - LAMP Stack Check out the Environment Engine Datasheet, the recorded Environment Engine demo, or drop by Booth #213 at VMworld from August 29 –Sept 1 in Las Vegas for a live demonstration.
There is nothing worse than getting that email or error warning you that provisioning has failed. And inevitably this happens at the very last stages of getting an environment automated.
You ask yourself: What happened? Why did it fail? And then: Did I build my own logging? Did the person that built the orchestration provide logging (and, if so, where is it)?
After asking yourself all of these questions, you realize that the orchestration/provisioning layer only shows you a simple “failure” message and no details of where it failed or why.
With Blueprints, even failure is amazing…
“Blueprints” is Tier 3’s environment templating engine. It allows you to combine virtual machine templates, infrastructure tasks, script packages, and software packages to create a fully deployable environment—such as building a Microsoft Exchange server environment with just the click of a button.
The other Blueprint feature that is simply incredible is the debugging and details that you have access to when deploying a Blueprint. This includes access to not only the status of the deployment, but also the tasks being executed. If something fails, you know where and why.
Here is an example of a blueprint being executed that fails on step 9 of 18. Normally this would be difficult to troubleshoot, but here it is reporting where it failed and what the error message is from the log.
When building your own Blueprint the feature gives you great debugging insight: you can test and see where your deployment is breaking down instead of just guessing what the problem is.
You can also restart tasks at any level to keep testing and make adjustments as needed. Here is an example an error in the log:
2012-02-02 15:53:25.9724 [Error] [vFabric Gemfire Install] - ./install.sh: line 4: /gemfire_install.expect: No such file or directory
2012-02-02 15:53:33.7689 [Error] [vFabric Gemfire Install] - Error building
2012-02-02 15:53:34.2220 [Error] [Build Server GEM] - Error building
2012-02-02 15:53:34.6907 [Error] [Root] - Error building
2012-02-02 15:53:35.0657 [Trace]  - >>>>>>>>>> Blueprint completed with errors
Today Tier 3 announced access to a Starter Kit Blueprint for VMware vFabric on the Tier 3 Public Cloud. We know that most of you are busy enough with your job, so setting aside time to try the latest technologies is often hard to juggle. To make it a bit easier, we created the starter kit blueprint!
This blueprint enables you to quickly deploy a small vFabric environment and be up and running in no time—without the need to troubleshoot.
What is in it?
The Starter Kit Blueprint for VMware vFabric comes with four virtual machine instances and the advanced vFabric applications:
vFabric tc Server: vFabric tc Server, the best place to build and run Java Spring applications, provides enterprise users with the lightweight server they want paired with the operational management, advanced diagnostics, and mission-critical support capabilities businesses need.
vFabric GemFire® Server: GemFire is a distributed data management platform providing dynamic scalability, high performance, and database-like persistence. It blends advanced techniques like replication, partitioning, data-aware routing, and continuous querying to help you.
vFabric Web Server: Unlike Apache, vFabric Web Server is pre-compiled, pre-configured and pre-patched, which reduces deployment times from a typical 3 days to 30 minutes. It has a consistent installation process and structure across all supported operating systems and installation is via self-extracting archive, with no requirements as to install location and no dependencies on graphics libraries. You can patch and upgrade multiple instances as well for further reduction in deployment and support costs.
vFabric Hyperic® Server: vFabric Hyperic, a stand-alone component of vFabric Application Performance Manager, helps web operations teams monitor the application infrastructure for custom web applications across physical machines, a virtual infrastructure environment, or the cloud and provides immediate notification of application performance degradation or unavailability.
Each of the servers is configured with 4GB RAM and 2 vCPU by default but you can change the configuration easily in the Tier 3 Control Portal after deployment.
With Blueprints from Tier 3, deployment is very easy and can be done in 4 easy steps:
1. Logon to the Tier 3 Control Portal and go to Blueprints > Search for “vFabric Starter Kit”
2. Click on the vFabric Starter Kit Blueprint and on the next screen click Deploy Blueprint.
3. Next you will want to customize your blueprint by specifying the following information:
Password for the servers
Network to place the servers on
Primary and Secondary DNS
4. Last step is to deploy the customized vFabric Starter Kit blueprint by clicking on the Deploy Blueprint button at the bottom of the screen.
The platform will now do all the orchestration and deploy a fully working vFabric environment for you.
To access the environment all you have to do is logon via VPN (we have instructions here).
For a full overview of an install with vFabric Starter Blueprint, watch our video taking you from deployment to configuration with Shantu Roy.
How do I get started?
Getting started is pretty simple. Go to Tier 3 and activate your account, which will give you access to this blueprint.
VMware has also published a blog post about our Starter Kit Blueprint. You can view that post here.