ISWest Moves its Dedicated Hosting Customers into the “Cloud” with Apache CloudStack
ISWest Moves its Dedicated Hosting Customers into the “Cloud” with Apache CloudStack
Join the DZone community and get the full member experience.Join For Free
Curator's Note: The content of this article was originally written by Karen Vuong on the CloudStack blog.
ISWest is a regional ISP based out of Agoura Hills, CA (approximately 30 miles north of Los Angeles). Started originally as a dial-up ISP, ISWest moved into the standard suite of ISP services including various forms of connectivity (DSL, T1, DS3, OC-x, Ethernet, etc) as well as ancillary services such as shared web and email hosting. Early growth was accomplished with a focus on small and medium sized businesses in the southern California area through strategic partnerships with outsourced IT organizations and customer referrals.
Business situation: To Stay Competitive by Offering an IaaS Cloud Service
With the benefit of owning and operating their own datacenters ISWest had a considerable amount of experience with the underlying infrastructure such as HVAC, UPS, Generators, structured cabling and other physical aspects related to datacenters. The ISP side of the business gave ISWest experience with designing and implementing highly redundant, high performance networks, as well as the servers associated with various essential internet services such as DNS, email, and hosting. Offering an IaaS cloud service was the next logical business step to stay competitive.
The business goal was to target existing clients either through the existing partner network of outsourced IT consultants or direct contact to prospects (typically colocation customers with old hardware). The requirement for these customers was different than “traditional” cloud which was largely based around public-facing e-commerce or other consumer driven websites. In contrast most customers were looking for a way to re-create network environments they were currently using which were primarily private (NAT) with only a limited number of public IP addresses used. At the time this type of configuration was either not possible with the popular cloud providers (AWS, Rackspace, GoGrid, etc), or was exceedingly complex to configure.
Given the predictable usage of the target customer, a system that provided hourly billing data was not required, but it would be good to have available should it be required in the future. An integrated billing system was also not required, as long as the usage data could be exported in a standard and structured format such as XML, JSON, or CSV.
The ultimate goal was to provide each client with their own private network, or in some cases multiple private networks, VPN access to those networks, and use VLANs to segregate customer networks from each other. ISWest evaluated a range different IaaS CMPs including Eucalyptus, Enomaly, and OpenNebula. At the time OpenStack was in its infancy and there were concerns as to its stability and/or production readiness, what direction(s) the project was moving in, and what type of support would be available if commercial support was needed.
ISWest had no full-time developers on staff so a system with as little customization as possible was required. In addition, given that the typical client would be rather small (15 VMs or less), most of the interaction with the system would be through a graphical UI and not API. To accommodate larger clients as well as the possible needs for automation a powerful and well documented API would be extremely beneficial.
After interviewing many customers it became apparent that the ideal CMP would easily allow the management of a diverse environment of multiple hypervisors was required. This was due to the fact that many customers had a mix of hypervisors including KVM, Citrix XenServer, and VMware. A CMP that was agnostic to server hardware, storage, and hypervisor would allow for an easier ingestion process for existing customer environments to ease the transition from physical and/or virtual to cloud.
The Solution: Apache CloudStack
To summarize the core issue faced with many of the CMPs that existed at the time, the focus was on the compute layers first and the network second. OpenStack provided the modularity, flexibility, and automation to allow ISWest to build around this type of “network first” service model but with virtually no development resources available it would not be possible. And even if this was surmountable there was also no friendly user interface for OpenStack. The same was true with Eucalyptus, which was built to be an AWS work-alike. All user interaction had to be done with API calls or tools which managed API calls such as euca2ools. The two CMPs that provided the best “turn-key” cloud were CloudStack and Enomaly.
Both CloudStack and Enomaly had intuitive and friendly user interfaces. Enomaly was focused not only on the service provider’s cloud but also to act as a central clearing house in which providers could auction off spare resources. Ultimately, however, the roadmaps for both applications showed a greater degree of focus on network functionality for CloudStack. It is worth noting that OpenStack allows for the type of flexibility as well but would require development resources in order to present it in a customer-friendly fashion as well as any ongoing support that is required any time customizations are made to a pre-existing system (upgrades, feature integration, etc).
When it came time to both evaluate and create proof-of-concept environments CloudStack provided ISWest with excellent support from the community, both in the form of users as well as cloud.com employees. Any CMP carries with it a multitude of complexities due to the sheer amount of resources it is expected to manage and manipulate. The learning curve is steep and the community was very helpful in providing direct help, tips, documentation, and advice on best practices.
By leveraging CloudStack, in a little over a month ISWest had a fully functioning IaaS cloud. The network segregation via the use of VLANs provided the network security required by customers which allowed for the rapid adoption of cloud services. In addition, VLANs allowed ISWest to connect existing colocation clients directly into their own private cloud providing them with the security of a completely private environment, with the elasticity of a cloud readily availble, and without the expense of a fully private cloud solution. This type of privacy, and familiarity to the customer’s existing networks, allowed ISWest to alleviate a number of the security concerns associated with purely public cloud offerings. With SDN on the horizon when the limitations of VLANs would be reached SDNs could be implemented to overcome those hurdles as well.
ISWest’s current cloud environment is based on blade servers from Dell, storage from Compellent, and networking components (switches, routers, etc) from Cisco. Dell and Cisco were chosen because much of the existing server and network infrastructure owned and managed by ISWest was built on Dell servers and Cisco routers, switches, and firewalls. Compellent was chosen because of the automated block-level dynamic RAID configurations which were a great fit for a service provider environment. Disk performance requirements could be easily and automatically handled to provide performance when needed by leveraging 15k and/or SSD drives, and density for everything else with 2TB 7.2k drives. However given the dynamic nature in which Compellent works, the pricing structure would be easy to handle since the majority of data would rest on slower, cheaper, larger drives.
The Benefit: Private environment, savings and elasticity
Shortly after bringing the ISWest cloud into production an effort was made to reach out to existing dedicated server hosting customers to move them into “the cloud”. The benefit to customers was that the same resources available on their dedicated servers would be guaranteed to be available in the cloud but with the additional redundancy provided by both the more robust cluster design, as well as the automated recovery from failure provided by CloudStack. This meant that customers, for the same price or sometimes less, could have all of the guaranteed resources with the added benefit of additional redundancy. Since virtualization allowed for a much greater density of customers on the same hardware profit margins on cloud vs. dedicated managed increased from an average of 35% to an average of over 85% (shortening the ROI on hardware purchased by ISWest from 10-12 months to typically less than 2 months).
With the generic/universal method in which CloudStack handles the split between primary storage (where VMs run in real-time) and secondary storage (where snapshots, ISO images, and templates are stored), ISWest has now begun the process of automating the replication of secondary storage between two datacenters in different states. This will allow for cloud based disaster-recovery-as-a-service for existing cloud customers easily and efficiently, even if both sites have dissimilar hardware. ISWest is currently in the final testing phase of this service with a key client, and this will allow them to recover an entire virtual private cloud with a simple DNS change and a few API calls.
By leveraging the network flexibility in CloudStack, along with the diverse support of hypervisors and hardware, ISWest has been able to increase the revenue per square foot in the datacenter considerably. Whereas an average colocation client represents approximately $1,200-$1,800 per rack in monthly revenue, the average cloud rack represents approximately $90,000-120,000 in monthly revenue. While this increase in revenue benefits ISWest, customers typically see lower overall costs of as much as 20% once the cost of new hardware, SAN storage, support contracts, and labor are taken into an account. This allows customers to focus on their business, while ISWest maintains the core infrastructure that their business runs on at a savings to them, and increased profitability to ISWest.
Opinions expressed by DZone contributors are their own.