By Andrew Simon
Just get me into the Cloud already
There are many barriers to implementing cloud solutions for companies. As management and stakeholders clamor for more and ready access to cloud solutions publicized in commercials, conferences, seminars, and elsewhere, the real work of assessment and, where appropriate, planning, adoption and implementation must be performed.
At the start, a significant barrier is often properly defining just what the cloud is and what adopting certain cloud technologies means for an organization. There are three types or categories of cloud implementation: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Importantly, cloud services are traditionally known as ‘managed hosting’ or managed services. Whether the service being managed is file sharing (DropBox) or a full compliment of servers (Amazon), it qualifies as the cloud.
Defining and understanding cloud implementation opens the door to discussing and strategizing about if, which and when cloud services can be adopted by an organization. Examples of IaaS services are Amazon Web Service (AWS), Rackspace, Google Compute Engine (GCE), and Microsoft’s Azure. The product being supplied is basic computer infrastructure in the form of virtual machines and/or physical servers, network, storage, and operating system. More on IaaS follows a little further on.
The PaaS service offers a group of virtual servers in an architected solution of computing tiers, plus a core set of platform specific software. Examples of PaaS providers are Godaddy and their stand-alone web servers, and Acquia’s tiered computing Drupal platforms.
Finally, there is SaaS, with the obvious example of email provider Gmail from Google. What transformed Gmail from an individual’s Internet web email to SaaS was it’s business-to-business offering. Gmail enabled corporations to migrate their entire mail server systems into Gmail systems: user accounts, domain names, and all. Gmail then serves as the organization’s official email SaaS.
Because cloud implementations vary so widely (IaaS, Paas and SaaS) and there are so many products and vendors out there, it’s a monumental task to write about all of the challenges, let alone attempt to suggest workable solutions for them. As the title of this paper alludes, I will focus on some of the challenges and resolution for the adoption of Infrastructure as a Service.
Note that the barriers facing PaaS and Saas adoption are often similar to IaaS adoption. The main differences between IaaS and PaaS/SaaS are in the application stack: what the application is and how the service is managed and delivered to the end-users.
To digress a moment, we want to level set and define and/or understand what computer technology infrastructure people do, whether in an organization’s internal data center or in the world of the cloud. From there, the vendor tends to delineate for the client where the responsibilities of the Iaas provider ends, and the organization’s responsibilities begin.
To be sure, this line between ‘us’ and ‘them’ does perhaps pose a significant challenge to adopting IaaS. An organization’s unwillingness to accept its reduced share of responsibility is most often a showstopper to adoption. For bigger, more mature companies, giving up responsibility is a huge challenge. In some rare cases, this line is can move slightly towards the customer. Conversely, the more the line moves away from the customer, meaning the more responsibilities befall the vendor, the quicker the customer is heading towards a PaaS or SaaS solution.
The IaaS cloud provider is responsible for most of the physical infrastructure1, including the data center buildings, physical security, server hardware, disk storage arrays, racks, cabling, UPS, PDU, cooling, fire suppression and network access between components and to/from systems. They are also responsible for some of the infrastructure specific software, including virtualization (VM) software, storage area network (SAN) software, network access to software repositories, billing systems specific to IaaS delivery, and ‘low level’ OS (BIOS and/or boot sector) software that lives in firmware or restricted partitions on disk drives.
The challenges for an organization adopting IaaS, therefore, focuses on provisioning the baseline systems and establishing an organization’s connectivity to the IaaS provider; as well as to provide architecting and implementation (creation) of the multiple computing tiers that create a platform on which applications are installed. The infrastructure group is also tasked with performance tuning, disaster recovery, OS and related upgrades, and many other duties.
Feel the love
With or without adoption of an IaaS, the responsibilities and challenges for an organization’s IT group are many. Naming the major headlines for these challenges really looks no different than the challenges any IT organization faces. There are: legal, technical, financial, security, personnel, strategic, and tactical challenges to implementing any IT plan. So, it stands to reason these same challenges are faced in delivering secure, affordable, high performance, comprehensive, scalable and redundant cloud based infrastructure.
Though not the focus of this article, there are many benefits to cloud adoption. One benefit that is relevant to this discussion is that a potentially significant portion of the infrastructure provisioning responsibilities of an organization’s staff will be transferred to the IaaS provider’s staff. The transfer of responsibilities to a vendor’s cloud staff also depends on how much corporate infrastructure can be migrated to the cloud.
The pending transfer of responsibilities leads to a potential barrier. Will the IT staff be willing or motivated for this change? When a significant number of machines are migrated to IaaS, it frees up an organization’s staff to do more of the architectural design, software configuration and related product management responsibilities. This is arguably higher level and potentially more fulfilling (and better paying) work than physical server provisioning.
It’s veritably unheard of that an organization’s management embarks on a cloud solution with the aim or intent at reducing head count2. So, if head count is reduced, it’s likely such reductions had to happen anyway. A discussion with staff about the organization’s motivation for cloud deployments is as important discussion to have.
With IT staff retention concerns addressed, the next hurdle facing cloud adopters revolves around the Purchasing Department and the related Service Level Agreements (SLA) and Statement of Work (SOW), if any, that define exactly what it is the organization is buying. One of the immediate complications in this area is the IaaS provider’s ‘”self-service, pay-as-you-go” business model.
Typically, organizations create requisitions against budgets, and purchase orders (POs) are created against those requisitions for specific products and services to be delivered on one or more specific dates. Most requisitions and/or POs are detailed itemized lists of exactly what’s being purchased, how much of it, the cost, and on what terms and conditions.
One way to overcome the hurdle of a self-service, pay-as-you-go purchasing model is to create an open PO, with pre-allocated funding, a time limit, and cap. The details of the requisition relegated to the umbrella trademark named service product (e.g. Amazon Web Services or Google Compute Engine), without giving much detail at all as to what or when, components within that service product are delivered.
Though the open PO may lead to less visibility and more risk to budgets in early ‘first-time’ purchases, the detailed billing (usually monthly) from the vendor will help significantly in providing for future budgeting and cost controls on the various components within the umbrella service. In fact, with IaaS, the days of multiple detailed requisitions and corresponding POs to deliver specific IT infrastructure components (servers, racks, cables, etc) to an organization are thankfully disappearing.
Organizations need to remember the IaaS vendor wants your business
One of the advantages of being a customer in the world of new startups, niche players, and ever expanding new offerings is that, to a greater extent than in past years, negotiating for exactly what you want is not just feasible, it may very well be necessary. With fewer monopolies and less hegemony in the IT space, negotiation is not just easier or more rewarding, it’s often required to get the SLAs and SOWs you need to move forward. Doing so will overcome one of the largest barriers to adoption.
Part of the SLA is clearly defining what the Support Agreement (if any) contains, and if the SLA and Support Agreements match the legal, business, and technical requirements of the organization, the purchasing department will be able to purchase the product or service. Often the SOW involves initial environment configurations, additional training of personnel and similar work not necessarily covered in a ‘basic’ offering. The ability for the vendor to provide these other non-core services is often key to an organization’s ability to move forward with adoption of new methods and technologies.
Related to purchasing, another factor is defining what the licensing agreements covering ownership and use for the different non-service components that are to be purchased. The solution to this hurdle is to be specific and get answers to the many product related questions in writing. For instance, will there be a period of free use during the transition, and if so, what is included? Is there access to source code? Will the customer be able to move certain pieces of software, such as custom kernels or drivers into another vendor’s (or in-house) service? Can the customer get historic reports on various things like billing, access, usage, and availability?
Having addressed a few purchasing and business issues, now is a good time to segue into more of the related legal discussion. Since I am not a lawyer, I think I will only briefly touch on a couple of the more common legal issues that I am aware of that need to be overcome. Without a doubt, depending on the business your organization is in, such as medical (e.g. for HIPPA compliance), financial and government (e.g. for SOX compliance), and where the business is incorporated, the laws and requirements can vary greatly.
However, all businesses are expected to conform to, and adopt policies that adhere to Federal Regulations on Civil Procedures (FRCP), and for IT departments, particularly as it pertains to Rule 343. Depending on your business, how those requirements are met will differ. This will almost always require your organization to protect customer data and archive various documents relevant and pertinent to the business as may be required to be produced in a court of law.
The ability for your IaaS provider to provide detailed data in the form of server and (security related) access logs, emails, instant messages (chats), and other types of data may be crucial to your organization should there be legal action taken against it, or should they have need to take action against others. More importantly, it may be necessary to actively and routinely collect that data and transfer it to other storage systems for the purpose of archiving that data.
The fact that data “is available” does not mean it has been retrieved, organized, stored or indexed; nor does it mean it will always be available. Negotiating with the vendor before engagement regarding the need to access, collect and store certain IaaS generated data may be one of the more difficult hurdles to adopting IaaS. Whether the IaaS vendor performs the service on the organization’s behalf (and, at what cost), or whether the organization wants to enlist independent resources for this compliance issue should be part of that negotiation.
It’s the network, dummy
With a few of the more germane contractual and legal hurdles addressed, I’d like to finally address what form perhaps the most significant hurdle (or set of hurdles), and poses both technical as well as organizational challenges. From my experience on numerous customer sites, I found overcoming hurdles surrounding connectivity to, if not outright integration of, the IaaS network components with the organization’s corporate and production communications networks to be the biggest challenge. And, those challenges can run the gamut of security related, technical, legal, logistical and cost.
An organization’s private network serves two generic functions – it interconnects the machines that are the property of the organization, and it provides a buffer between internal network traffic and the public network known as the Internet. It is through this buffer of network switches, firewalls and other appliances that the internal network machines may be able to access external machines on the Internet; and for machines on an external organization’s network, or individual users (i.e. staff and/or customers) via the Internet or dedicated (leased) communication lines, access an organization’s internal machines.
For server machines hosting applications that don’t require connectivity to other machines or have little need to connect to external users or machines to initiate and complete their assigned tasks, computer interconnectivity with an organization’s private network of machines is less of a problem. This is because of the limited scope (e.g. few or no external users or machines requiring access) of the connectivity requirements. Yet, those types of applications and server machines may be few among the dozens, hundreds or thousands in an organization. They may also tend to be of lower importance and criticality.
More likely, there are key systems such as payroll, HR, research, billing, customer service, and so on, that all interconnect, pulling input data from one networked data source, running programs to crunch numbers, and pushing the output to yet more machines. To work around the issue of connecting these types of servers, IaaS vendors provide VPN connectivity, and through that, offer a VPC – or virtual private and/or hybrid cloud. This allows companies to utilize their in-house firewalls and gateways, and to enable specific servers in their private network to communicate to the cloud servers using the full range of TCP/IP services (i.e. network ports) beyond the typical FTP, SMTP, SFTP, and SSH protocol services.
The major drawback of virtual private clouds is that the IP range on any/every private local area network of the organization must be unique from the private local area network established in the cloud. Otherwise, routing network traffic from the two different segments may create a scenario where there can be duplicate IP addresses across the organization’s wide area network, opening the possibility for additional and unpredictable software and networking issues.
To overcome this hurdle, the organization needs to involve the network engineer group early, before creating the VPC private network segments in the cloud, to identify and provision one or more unique network segments to assign to the cloud’s private segments. This will allow for communication to/from the cloud private segments to the organization’s private segments as though all of the servers were on the organization’s physical network infrastructure.
A related hurdle is the nature of the virtual private cloud connection, which essentially traverses the Internet to the IaaS provider’s public IP addresses. Though VPC traffic is encrypted, Internet connections are not dedicated connections as would be the case for servers within an organization’s servers. And, occasionally network IP addresses can be ‘spoofed’, tricking switches and routers to route traffic to the wrong server or network. Conversely, organizations big and small often will pay for telecommunications leased lines from one physical location (e.g. remote data center) to another (e.g. corporate headquarters). And, within each location, there are switches owned or managed by the organization and the IP address assignments and SLA are all in control of the organization.
By relying on only an Internet connection for server connectivity to their IaaS provider, the organization will not have a dedicated connection to their servers in the cloud. Since there is no ‘Service Level Agreement’ for Internet connectivity (e.g. there is no guarantee of bandwidth or connectivity) and IP spoofing is a possibility, it is generally a bad idea for organizations to rely solely on the Internet to connect to their mission critical systems. For instance, if an Internet connection goes down, or the destination IP is spoofed, there is no vendor to call, no SLA, no contract, and little to nothing that can be done about it.
Though leased telecommunications lines do travel off of an organization’s physical property, there is an SLA and call support center with the telecommunications company that will investigate and remedy. And, generally speaking, there are no IP addresses between the endpoints of a leased line. So, in order to overcome our last hurdle, there are some IaaS providers (Amazon, to name one) who, if paid the amount of money they ask, will accommodate a request to install permanent, dedicated leased communications lines from one (or more) of their data centers to the organization’s site. Though this may be cost prohibitive or unnecessary at first, as the push to put more mission critical servers into the cloud becomes a mandate, the cost issues will be both justifiable and likely comparable to what the organization already pays to link it’s own physical properties with leased telecommunication lines.
To summarize, the hurdles to adopting the cloud range from defining what the cloud is and choosing what to migrate, to legal contracts and accountability; from staff misconceptions on why the organization is adopting cloud solutions to how to fully integrate the cloud with the organization’s current wide area network. I hope this paper sheds light not just on some of the more complex issues, but gives a fairly detailed roadmap on how to overcome them.
_______________________
1“What is Infrastructure as a Service?” IBM.com. Last modified Thu, 25 Jun 2015. http://www.ibm.com/cloud-computing/us/en/what-is-iaas.html
2“Gartner Survey Reveals That SaaS Deployments Are Now Mission Critical”. Gartner.com. Published November 15, 2014. http://www.gartner.com/newsroom/id/2923217
3“Federal Rules of Civil Procedure”. Cornell.edu. Last Modified Tue, 28 Jul 2015. https://www.law.cornell.edu/rules/frcp
Andrew Simon, founder of Technology Leadership, LLC in New York, is a hands-on DevOps engineer and project lead. He has performed numerous consulting and engineering roles for a variety of small and large companies, assisting in their migration efforts of in-house infrastructure and applications to cloud based platforms and technologies.