Recently Skytap announced the release of a new feature, termed Inter-Configuration Network Routing or ICNR for short. We have seen broad adoption of this feature so far, and I thought for today’s topic we look to a couple of fantastic use-cases for this new capability within the Skytap cloud.
Just a brief re-cap. ICNR allows you, as a Skytap user, to create a network level connection between multiple Skytap configurations within your account. Typically this is used for centralized resources. For example, you can setup a centralized database that has several different application configurations attached to it. Essentially, you can create complex network topologies within Skytap as needed and on the fly.
There are three use-cases that are, in my opinion, a perfect fit for this new feature. The first is a central database server. Many of the development and test use-cases that run in the Skytap cloud rely on a database as the primary back-end component. A typical setup is a single configuration that contains both the backend database communicating directly with the front-end web app servers on the VLAN specific to the configuration. Consider using ICNR in this case, to keep your front-end web servers unique to a configuration and the backend database component as a centralized server connected via ICNR to your various front-end servers. Rather than stamp out each configuration with a database attached, save your resources by having one database for your functional, performance or unit testing.
The second use-case: utilizing a Domain Controller within Skytap. Some of the more common use-cases that I encounter as a Cloud Solutions Architect rely on a Domain Controller running in some cases IIS and in other cases Active Directory. Invariably, virtual machines within Skytap access the domain controller via a hybrid model that utilizes an IPSec tunnel allowing communication between specified on-premise servers and Skytap virtual machines. This is particularly relevant in the extension of active directory to configurations running in Skytap. Now, with ICNR, you can do all of this directly within Skytap. In certain situations, it may make more sense to push a domain controller to the cloud and utilize active directory as a central server within Skytap connected to your active configurations.
Finally, in some situations, two-factor authentication is a necessity for certain subsets of your infrastructure in the cloud. In some cases, IP limiting within Skytap works well for this. You can effectively put all of your Skytap infrastructure behind your corporate VPN and enforce an IP limitation – all users will be required to VPN into your corporate domain, potentially behind a rolling token, to gain access to Skytap itself and the virtual machines that reside within Skytap. In other cases, a central authentication server may be setup. All logins to the virtual infrastructure will initiate a text message or phone call to the associated user who is attempting to login. Once the token has been input, the user will only then be allowed login. This is another perfect scenario for ICNR. You can leverage this authentication server as a centralized resource connected to all of your cloud infrastructure and scale within different configurations as needed over time.
The best part: this is just the tip of the iceberg. Given that Skytap is 100% self-service, I am consistently amazed by the quality and complexity of the work that is being done in the Skytap cloud. ICNR only further enhances the topologies that may be easily setup utilizing the automation at the UI layer within Skytap. If you have an idea for ICNR, I would welcome the opportunity to exchange ideas and get it up and running.
George Stamos, Cloud Solutions Architect – Skytap
