Advanced Cloud Automation and Platform (PaaS) Services

Advanced Cloud Automation and Platform (PaaS) Services
Author: James Bond
This article is a follow-up to my previous topic “The Importance of Automation in Cloud Computing” published at http://wp.me/s3qrAW-11.   This time I will discuss the automation processes that cloud providers employ for more advanced functions such as multi-tier, multiple virtual machine (VM) platforms or Platforms-as-a-Service (PaaS).
Most cloud service providers offer virtual machines and storage as part of their Infrastructure-as-a-Service (IaaS) offering.  With a typical IaaS service, the customer selects their desired operating system and sizing of virtual machine (CPU, memory, disk storage) through a web-based service catalog.  Upon order completion, the automation system, that runs behind the scenes within the cloud provider, provisions or hydrates a virtual machine based on existing pre-created templates.  Once the virtual machine is ready, the customer can manage all of their online virtual machines via the cloud provider’s portal.
Platform services or PaaS is a much more complex ordering, configuration, and provisioning process.  Many traditional IaaS cloud providers add PaaS services to their list of offerings once their ordering and cloud management systems are upgraded to handle the automation tasks.  There are several factors, beyond normal IaaS-based virtual machines, that a PaaS service must configure and automatically provision upon a customer’s order:
  • Multi-VM platforms.  Many applications hosted in the cloud require, or are best configured, using multiple virtual machines—each VM is configured to run part of the application environment such as one VM running a database while a second VM runs the application.  The ordering process and automated provisioning systems must treat these multiple VMs as a group.  Each VM is assigned a boot order to handle situations where one VM/host must be online before the application or other VMs attempt to boot up.  VMs within a single project/environment may have the same security and administrators assigned but this platform, or group of VMs, cannot be seen or managed by any other users or platforms.  Virtual networks and roles-based security permissions are provisioned by the automation system.
  • Application Development (also called Dev/Test) platforms.  Similar to simple multi-VM environments, a Dev/Test platform will provision multiple VMs for developers to create and test applications.  Developers often run multiple simultaneous application servers and client desktop VMs as they develop and test their code/applications.  Additional VMs in a Dev/Test platform may include Application Lifecycle Management (ALM) tools that development teams utilize to store programming code, share project information, and test applications.  Finally, Dev/Test environments can be configured to allow promotion of applications from Development VMs and virtual networks to Testing and then to Production networks/VMs.  For more details on Dev/Test cloud services, refer to my article entitled “What is Dev/Test as a Service” at http://wp.me/p3qrAW-n.
  • Network virtualization.  Multi-VM environments common utilize multiple virtual networks to separate traffic from other platforms or other projects/teams within your organization.  Even within a platform consisting of multiple VMs, virtual or software defined networking can be configured to separate network traffic into multiple paths, improve security, or for scalability.  Automated deployments of PaaS platforms are usually based on pre-defined templates that include the VM configuration as well as storage and networking settings to be deployed when a customer places an order.
  • Shared storage.  Multiple VMs or platforms can also be configured to share storage.  This storage may be assigned to multiple clustered VMs or the storage can be configured as shared storage accessible by multiple VMs within the defined platform.
PaaS cloud services, as described above, go beyond just the operating systems that are defined and provisioned within each VM.  Platform services involve a higher layer, on OSI model, where applications and even data may be pre-loaded onto the VMs.  This brings additional automation requirements such as software license tracking, application patching, software upgrade tools and processes to keep the platform up-to-date with latest manufacturer or custom application releases.  The cloud provider will also assume more responsibility to manage more than just the operating system for a PaaS offering–refer to my article entitled “Who Manages Cloud IaaS, PaaS, and SaaS Services” at http://wp.me/p3qrAW-h.
A cloud provider’s automation system must be configured to handle all of these PaaS-specific tasks.  This requires a significantly more advanced cloud management and automation system behind the scenes that the cloud provider operates.  This is why you will notice many new or smaller cloud providers focused on IaaS virtual machines and they may be rather weak on PaaS capabilities.  You should ask your current or potential cloud provider exactly how they define, provision, and manage multi-VM application stacks or platforms.  Not only ask how platforms are automatically provisioned but also how customizable the templates are, who manages templates, and how virtual networking is configured within platforms.   A true PaaS provider should be able to clearly articulate their platform provisioning process and know the different between a platform and just a group of unrelated IaaS-style virtual machines.
About the AuthorJames Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , , , , , , , , , , , ,
Posted in Uncategorized

Operational Changes When Transitioning to Cloud Computing

Operational Changes When Transitioning to Cloud Computing

Author: James Bond

When an organization migrates or adds a cloud service to a traditional data center (or managed service), there must be distinct changes made to the Concept of Operations (CONOPS).  This doesn’t relate as much to a public cloud service, since the provider handles most of these functions for you; the CONOPS changes are really for private cloud models, where the customer is involved with most operations.  The operational topics below are arranged in ITIL (Information Technology Infrastructure Library) format and nomenclature, to match the many organizations that have adopted ITIL as their service management model.

Note: All organizations and cloud services are unique; therefore there is no realistic way to capture every possible change that may need to be addressed.  The areas below are based on significant customer experience, Federal Government and commercial organizations.

Request Management

Ordering of cloud services will be done through the cloud management system, usually a web-based portal.  This portal includes a service catalog of all available offerings and options.  All orders, cancellation orders, and usage tracking for billing purposes will be handled within this system.  Legacy methods for consumers to order services will normally be retired, with this service catalog becoming the new method for ordering services – even if money does not change hands as in some private or communication clouds.

There may be a link from the cloud management portal to a traditional support ticketing system to allow customers to request assistance.  These will be handled in the same manner as any other legacy user request/support ticket.

Incident Management

A common change to incident management will be the monitoring of additional event logs within the cloud services.  Since the majority of cloud compute provisioning will be performed in an automated fashion, careful tracking of the event logs and creation of alerts will be essential to detect any failures in the automated processes.  For example, you could run out of available memory or storage space – something you should be proactively monitoring for – and therefore all new orders for virtual machines would fail.  As the cloud manager, you will have two areas to monitor and manage incidents:

  • Cloud Infrastructure.  You must manage the cloud infrastructure itself – meaning the data center facilities, server farms, storage, networks, security, and applications.
  • Customer services.  You will also need to detect when a new virtual machine or other resource is automatically provisioned, so that you can begin monitoring it immediately.  Since these services will be used by customers, you may be managing virtual instances of a server or how many resources a customer is using for billing purposes.

Change Management

Due to online customer ordering, approval workflow, and automated provisioning systems within the cloud service, change control will be significantly affected, and will need to adapt existing processes.

  • New Virtual Machines.  When a customer places an order, the VM(s) will be automatically provisioned.  All of them will be based on pre-approved and security certified operating system images, applications, and patch levels.  The cloud service portal should be programmed to automatically generate a change control request, with a completed status, upon every successfully automated provisioning event.  Any exceptions or errors in the automated provisioning process will be handled through alerts, and generate a “completed” change ticket once the VM is online.
  • Changes to Servers/Hosts.   Customer requested changes will follow normal change control procedures already in place.   Routine maintenance, updates, security patches and new software revisions will also follow existing change control procedures.   One typical exclusion is the Dev/Test service, since these are often VMs provisioned behind a firewall to keep non-certified development applications isolated from production networks.  With this service, VMs do not require change control in order to allow the developers to do their job without change control slowing them down.
  • Updates to Common Operating Environment (COE). Cloud services automatically deploy templates or build-images of standard configurations.  These COE templates will be created by the cloud provider or customer with all updates, patches, and security certifications completed.  These COE images can be automatically deployed within the cloud environment without going through the typical manual accreditation process for each server.   The cloud provider is usually required to update COEs at least every 6 months to keep the catalog of available operating systems and applications up-to-date.  All updated COEs will again go through the manual security approval process, and then can be ordered and deployed using the cloud’s automated systems.
  • Server (VM) Add to Network and Domain.  As each machine is automatically provisioned, the it will automatically be added to the network domain.  This will be an automated process, but the specific steps required, as well as change and security control policies involved, need to be adjusted to allow this to occur; this process of joining the domain typically required manual security approval in the past.
  • User/Admin Permissions to New Servers/Hosts.  Similar to the above “Server(VM) Add to Network and Domain,” as new machines are automatically added to the network, permission to log into the new operating system will be granted to the cloud management system, usually using a Service Account.  Specific steps to automate this process, and adjustments to the existing security processes will need to be made to accommodate this automated process.
  • Network Configuration Requests.  Every VM based server has a pre-configured network configuration.  In the case of an individual machine – physical or virtual machine – standard OS and applications are installed that require outbound initiation of traffic within the production network, and possibly to the Internet.
    • All network configuration, load balancing, or firewall change requests follow existing procedures.  When possible, the cloud management self-service control panel will allow customers to configure some of this by themselves, although advanced network changes will need to go through normal change control and possibly security approval.
    • In some VM templates or COEs, there may be multiple servers deployed as part of a COE.  For example, a complex COE may include one or more database servers, middleware application servers, and possibly front-end web servers; this collection of VMs is called a Platform.  In these situations, the virtual machines have already been configured – as part of the overall platform package – to communicate with each other via the virtual networking built into the VM hypervisor.  In the given example, only the front-end web servers would have a production network address, while all other servers are essentially “hidden” within the virtual machine network enclave.
    • Customers may submit requests to have production firewalls, load balancers, or other network systems custom configured for their needs.  When evaluating these requests, the cloud provider should always default to making the changes within the hypervisor virtual network environment.  If that is not sufficient, he may consider changing physical data center switches, routes, and firewalls; many of the requests can be handled using virtual networking settings within the hypervisor tool.
  • Virtual Machine Configuration Changes.  Customers may have the ability to upgrade or downgrade their virtual machine CPU, memory, or disk space within the cloud management portal.  Changing this configuration requires a reboot of the customer’s virtual machines, but no loss of data.
    • If a customer requests manually through a support ticket, the cloud provider will make this change using the cloud management software, so that billing and new VM configurations are automatically updated. Do not make changes to the back-end hypervisor directly, or the cloud management system will have no knowledge of that change.
    • Manually changing the VM configurations is NOT the appropriate process; billing and configuration management will not be aware of the new settings, and the downstream asset and change control databases will not be updated.
  • Release Management.  All VM templates, COEs, and software will be fully tested in an offline lab or staging network, then quality checked and security approved  before any changes to production cloud service is scheduled.
    • Updates to Common Operating Environment (COE).  Cloud compute services automatically deploy templates or build-images of standard operating environments.  These COE templates will be created by the cloud provider or customer with all updates, patches, and security certifications completed.  These COE images can be automatically deployed within the cloud environment without going through the typical manual security process for each server.  The cloud provider is usually required to update COEs at least every 6 months to keep the catalog of available operating systems and applications up-to-date.  All updated or new COEs will again go through the manual security approval process before they can be ordered and deployed using the cloud’s automated systems.
    • Customers must be provided with advanced notice – 10 days, for example – before any changes or updates are made to already deployed customer VMs.  Customers may “opt out” of any planned upgrade within this window if they believe it will negatively impact their project, timeline, or code stability.
      • It is the cloud provider’s goal to keep all new and existing VMs up-to-date; therefore, the cloud provider should adequately document the need, importance, testing results, and impact of each upgrade to encourage customer adoption of the new updates.

Configuration Management

The cloud management system will automatically populate the configuration management database of all VMs as part of the automated provisioning process.  Since cloud compute services can be ordered, approved, and automatically deployed at any time and day the customer desires, this automated update to configuration management is critical.

  • Changes to the actual VM servers and software should be treated differently than to customer-owned virtual machines.  Normally the cloud provider upgrades their server farm, then in a different maintenance window, schedules any necessary customer upgrades.
  • VMs running within the Dev/Test sub-networks do not require the same level of configuration management as production VMs because they are sandboxes for developers to work in.  There is little point in enforcing strict change and configuration management and only slows down the developer’s efforts.  Only when the VMs are deployed into production must they begin to follow all change, security, and configuration management policies.

IT Asset Management

All existing procedures for Asset Management will be followed; however, the automation within the cloud management platform will automatically update asset databases.  This automatic real-time update is often part of Federal Government IT security requirements.

  • As the number of customer orders increases, additional physical blade servers and SAN storage will be required; capacity planning and monitoring is critical to success.  As new servers or storage is added, the Asset Management system will be updated as per normal procedures.
  • Virtual machines running within DTaaS (pre-production) and IaaS/PaaS (production) networks must have all assets tracked, including the VM itself and potentially applications contained within VMs.

Service Desk Function

Most cloud providers – certainly public cloud ones – do not provide tier 1 user support; customers normally provide this function, or contract a third-party.  The cloud provider manages all devices and software within their cloud service, and customers typically manage only their applications or VMs.  However, issues can be escalated to the cloud provider through the management portal, email, or telephone depending on the offering, terms and conditions.

  • It should be noted that customers within DTaaS may attempt to submit tickets relating to software development programs or problems found in their custom applications; each of these are development issues that should be handled by the customer’s development staff, and not the cloud provider.

Service Level Management

While the cloud provider normally establishes Service levels,  customers may request additional or more enhanced SLAs.  Accepting the modified terms is ultimately up to the cloud provider — normally public providers do not change their SLAs, but this is a primary benefit to a private deployments.  The provider should provide customers with some form of reporting mechanisms, such as:

  • Online “dashboards” as well as monthly “manual” reports included with invoices.
  • Utilization metrics shown on dashboard, showing VM CPU utilization levels, memory, disk, network and disk throughput, and uptime: all examples of what is normally measured and reported on.
  • Billing history, and all reports and metering should be shown per customer and department.

Availability Management

Inclusion of availability statistics should be included in the cloud management portal for customer visibility.  See also Service Level Management

Capacity Management

Constant monitoring of the cloud compute servers and storage systems is required.  Since ordering and provisioning is done automatically 24×7, it is easy for the system to run out of available physical servers or storage, thus causing a failure in future provisioning new orders.  There is lead-time required to purchase, install, configure, and certify any new equipment, so monitoring and establishing alert thresholds is critical; the cloud provider needs sufficient time to add capacity.  The cloud provider could over-purchase capacity that remains idle until utilized, but this costs money to procure, power, and cool – costs which get passed on to customers.  It is far preferable to have a reasonable amount of extra capacity, with rapid replenishment plans in place.

  • It should be noted that several sizes of VMs are available to the customer; therefore, the more often a “large” or “extra-large” VM is ordered, the more CPU, memory, and disk are allocated.  This means fewer VMs will fit on a physical blade server, and the cloud provider will need to add additional capacity sooner.
  • Note that capacity management needs to consider that the following technologies are deployed in the cloud environment, affecting methods and calculations for capacity planning:
    • All cloud compute physical servers normally run a hypervisor product such as VMware or Microsoft Hyper-V.  These servers and VMs boot from a storage area network SAN, and have no local hard drives.
    • Thin provisioning is commonly used throughout the SAN, thus you need to carefully calculate actual disk usage versus what has been sold and what is remaining in capacity.
    • Thin provisioning free space reclamation may be a scheduled, not automatic, process to run.  Automatic is preferable, but not all SAN system support it.
    • If over-subscription of CPU or memory was calculated within the hypervisor configuration, monitoring of system performance and capacity is even more critical.
    • Useable capacity on the SAN does not include additional space to hold any daily backups or snapshots,  so actual useable capacity will be 25-50% higher.
    • Consider having the SAN supplier provide a “utility storage” agreement, whereby they stage additional SAN capacity at the cloud provider data centers but do not charge them until it is utilized.  This shares the costs and risk of managing extra storage capacity between the cloud provider and their SAN vendor.

IT Service Continuity

Most cloud services are deployed with multiple server farms and data centers to provide continuous operations, even during maintenance or disasters.  If you are hosting your own cloud service, there are numerous technologies and products that can facilitate the load balancing, failover, and continuity functions.

Financial Management

Depending on the cloud provider and how billing occurs, customers may need to adapt the way they procure the services, amortize IT assets, and manage their budgets.  Customers may be able to use ongoing operational funding instead of capital funding to procure cloud services, as was earlier discussed.

Customers may desire to establish pools of funding, or purchase orders, so that individual cloud service orders (called subscriptions) are charged against this pool of money.  To avoid the finance or procurement department being involved in every micro-transaction and subscription, these pools of money have proven to be a more acceptable financial management technique.

Security Management

Security management will be significantly involved in the certification of a private cloud offering.  VM templates or Common Operating Environments (COEs) will need to be pre-certified by security teams, so users can order services at any time and have the automated cloud management launch everything immediately.  This pre-certification is often the most significant change to the way organizations run today, but is critical to the automation of a cloud saving time and money for the end-customer.

Security will also be involved with any networking change controls or custom COEs created or requested.  Internal network changes between VMs in the cloud environment also need to be approved by security, unless the network settings are part of a pre-approved COE, in which case security has already approved.

Monitoring and scanning of all physical servers and customer virtual machines must be continuously performed; data scanning of all new VMs to safeguard against sensitive data loss may also be necessary.  The key to success here is to use the cloud management system to automatically add new compute devices to the monitoring systems, so security personnel are immediately aware of new systems, and the monitoring can begin immediately.

Technical Support

For Dev/Test services, no developer-level support is available from most cloud providers.  All cloud compute VMs are managed up to the OS level, with customers managing only their application development.

The cloud provider technical support staff will need to become familiar with hypervisor and cloud management systems in order to conduct normal operations, troubleshooting, patching, and upgrades.

About the Author

James Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , , , , , ,
Posted in cloud, cloud computing, Uncategorized

Unique IT Security Concerns in a Cloud Environment

Unique IT Security Concerns in a Cloud Environment

Author: James Bond

 

Information technology security is of paramount importance for all computers, server farms, data centers, and their applications.  Security involves both physical security of the facilities and IT assets, security monitoring and management of the network infrastructure, servers, and applications.  Obvious goals are the prevention of intrusions, attacks, and the protection of data.  Basic security concepts are assumed knowledge so that we can focus on the unique challenges within a cloud environment.

First, we will briefly review the top aspects of security in a traditional data center environment then add cloud-specific considerations.  This list is by no means an exhaustive catalog of security systems available in the industry, but we will build upon it to explain cloud-specific threats, vulnerabilities, and recommended protection.

  • Perimeter security of the network.  Protecting the network infrastructure using firewalls is the most common part of securing your systems.   These firewalls can be in the form of specialized appliances, or standard servers running firewall software.  Traditional firewalls track and allow or disallow network traffic from one network, commonly the Internet, to another network.  Some organization deploy multiple firewalls in layers for increased security, but more often create so-called demilitarized zones (DMZs), where public-facing web services can be offered while back-end protected data is behind additional firewalls.

Many legacy firewalls protect through configurable rules, and monitor low-level layers of the OSI model.  Advanced modern firewalls offer improved protection of known and unknown threats as they monitor and restrict traffic based on more advanced logic – all the way up to the application layer of the OSI model.

  • Intrusion prevention and detection.  Monitoring network traffic searching for unauthorized access or attempts to hack into the system is a normal secondary step.   Through perimeter detection devices such as firewalls, we can block access to unknown networks or types of traffic, but we cannot necessarily stop traffic that appears to come from legitimate sources or computer activities occurring inside the network; it’s simply beyond the firewall’s ability to detect.  Intrusion detection systems monitor many aspects of the network, server farms, applications, and event logs, searching for patterns that represent known harmful activities, as well as suspicious ones that could represent a new, unknown security threat.  Once detected, intrusion systems can trigger alarms to computer support personnel, and in some cases of advanced security systems, actually begin a response to the potentially harmful activity, such as isolating the user, network traffic, or suspected malware.
  • Anti-Virus and anti-malware.  Protection from numerous types of computer viruses and malware are usually provided as an add-on software tool on servers and desktop workstations throughout the internal network.  Even computer systems that do not have access to the Internet should be protected, so that one infected machine cannot turn around and infect others within the internal network.  Network-based applications for anti-virus and malware also exist that can monitor network traffic to identify patterns of known and unknown viruses or malware; these network-based systems can also be included within an application-layer firewall system.

Managing and monitoring the network, servers, and applications is typically performed through a combination of computer systems, processes, and people.  Computerized systems normally do a reasonably good job of protecting known threats and vulnerabilities, but are challenged when it comes to detecting new or unknown threats.  As new threats appear by the dozen every day, a computerized security system will regularly come up against threats against which it has no library of protections.  Detecting these zero-day attacks requires both the detection of the incoming threat, and hopefully an alert to support personnel or automated isolation of the suspicious traffic.

Constantly Improving Security Systems and Tools

Although this is a broad summation of the IT security industry, the last 10+ years have focused on basic security protection and monitoring, but is highly flawed.  Human beings are heavily relied upon to monitor system logs and events, rather than computer systems detecting and automatically responding to events on their own.

Recent trends in computer security are certainly improving, and are now able to better detect potentially harmful behavior or traffic seen on the network, rather than solely relying upon a library of know signature files in need of constant updating.  These systems are better – but not perfect – in detecting patterns of activity that may not be individually harmful, but could be evidence of a hacker, virus, worm, Trojan, or other intrusion.

Figure: Proactive and Reactive Security Protection

Screen Shot 2013-04-19 at 7.54.05 AM

 

Unique Cloud Computing Threats and Vulnerabilities

Cloud systems, being inherently based on users and customers accessing everything via the Internet, expands both the need for more advanced forms of traditional security systems, as well as new security technologies unique to cloud.

Cloud computing considerations include:

  • Perimeter security.  In a cloud environment, a much larger percentage of the computer systems are Internet facing ,or directly online for access by customers and their users and customers.  In a traditional data center, only a fraction of servers might be available via the Internet – such as public web sites – and the internal users of the organization are on the relatively safe internal networks.  In a public cloud environment, the internal cloud users are both employees of the customer, but also users from the Internet. This means the threats are increased, and the number of users and activity to be scanned increases.   In a private cloud, the computing services can be hosted from an internal customer data center, and thus internal users would not necessarily access their systems via the Internet.  To mitigate the increased risks, the most advanced firewalls, application layer firewalls, intrusion detection systems, monitoring systems, and dedicated security personnel are all combined to protect the environment.  As discussed earlier, the amount of automation in the cloud system is also a security risk.  Virtual machines and new users can be added to the cloud service at any time of the day; this means that the security management systems must become aware of them as they are provisioned.  There can be no gap in security protections, thus the cloud management system should automatically insert new VMs into the network and security monitoring systems in an automated fashion as part of the provisioning process.
  • Denial of Service (DoS) Attacks.  Although any network or customer can become a victim of a denial of service attack, a cloud service – especially a public one – often hosts many customers.  Any attack against a customer affects other customers sharing the same cloud provider network, and the chances of a cloud provider being attacked are higher than any one individual customer network.  These DoS attacks usually consist of one or more hackers sending massive amounts of data through the Internet at the target in an attempt to overwhelm the perimeter security defenses and shut down the system, denying access to its rightful owners and users.  In order to generate enough traffic to flood or overwhelm large pipes, attackers will initiate a Distributed Denial of Service (DDoS) attack using hundreds or thousands of computers all simultaneously sending traffic.  The attacker has access to these thousands of computers by activating trojan-infected machines on the Internet, and turning each of the computers into a zombie or bot.  The good news is that a successful cloud provider will have systems in place to mitigate or deal with denial of service attacks while keeping all customer services online.  Common techniques they might use can also be deployed for private clouds, and even legacy data centers.  Some of these recommended security systems are described in the next section.
  • DNS attacks.  Although technically a DNS attack can be categorized as a denial of service attack, we highlight it here to make the point that DNS attacks are increasing in popularity.  If a cloud provider is prepared and successfully mitigates a traditional denial of service attack, a DNS attacker simply goes after the Domain Name Servers (DNS).  By saturating the DNS servers with traffic, the hacker essentially inhibits the ability for customers or users to find the web site or cloud service they are trying to access.
  • Application attacks.  One of the newer and more sophisticated attacks target public-facing Internet applications or computer services.  An attacker could find a search feature on a web site, and submit a query for a file or keyword that does not exist, producing a “nothing found” error after the server has scoured its network performing the search.  Now imagine the attacker sending 3000 of these searches every second, and you can see how this would cause the web server to fail.  Take this one step further; let’s say the attacker finds a “contact us” form on the web that updates an SQL database on the back-end server farm.  By running a script that submits this form 5000 times per second, the attack causes the web server and the back-end SQL system to fail, overload, timeout, or otherwise crash.  These kinds of attacks are called layer 7 attacks, referring to the name of the Application Layer in the ISO model.  Protection against these attacks are difficult, since the attackers are constantly finding new ways to attack.
  • Bot networks.  Bot networks, zombies, and compromised systems occur when a computer within a network has been compromised through a virus, worm, or trojan horse.  Scanning systems often detect infection after it occurs, but rarely prevent the infection.  These compromised systems remain idle until called into action by an Internet-based control system, most often to accomplish some harmful task such as leaking data, spreading to other systems, corrupting or deleting data, or just clogging the network with overwhelming traffic.
  • Social networking.  Interception or discovery of data from social networking or human beings is a common threat.  Spear Fishing is a prime example of using both technology and human vulnerabilities to send out – for example – emails to targeted users while pretending to be from a legitimate source.  Unsuspecting users click on the email and are asked to log into, what they believe, is a legitimate bank or commerce web site.  However, it is a fake site that obtains their user login information, then either sells it or exploits it to commit fraudulent activity.  Virus and malware scanning do not provide adequate protections against these types of attacks.  The email message, in the above spear fishing example, appears just like any other legitimate email except the URL within the message leads the end-user to a fraudulent location.

Consolidation of Systems and Data in the Cloud

The basic concept of cloud computing is the transformation of compute services and data into the cloud.  By consolidating legacy server farms and data centers, you centralize your data in a cloud environment physically hosted at a cloud provider or customer facility, depending on your public or private deployment model.

Customers and security industry experts often ask the if their cloud environment is more or less secure than a traditional behind-the-firewall network inside a customer owned data center.  There are two diverse opinions amongst industry experts on this:

  • Less Secure.  Some industry experts claim that consolidating all customer data and servers into a single cloud means that a successful hacker could have access to massive amounts of customer data in the same physical data center.  This would make the risk of data loss or tampering higher in cloud environments, compared to distributed server farms and applications in traditional data centers.
  • More Secure.  The majority of security industry experts agree that the cloud is more secure than traditional server farms, data centers, and applications.  The theory is that a consolidated location for servers, applications, and data is easier to protect and focus security resources on than traditional non-cloud distributed systems.  Public cloud providers, and any private cloud owner, can procure all of the very latest in security appliances and software, centralize a focused team of security personnel, and consolidate all systems events, logs, and response activities.  The quantity of security devices is actually less, as is the cost; however, the cost of newer and better security products will balance this out.  Industry experts point to consolidated focus, and simpler correlation of logs and events as reasons for cloud environments being more secure than most legacy server farms.

In a cloud environment, the security posture and mitigation systems in place are across the entire network.  They have sufficient capability and capacity to monitor and react to real or perceived security issues.  However, since this is a multi-tenant environment, any individual customer with higher-than-normal security needs cannot be accommodated.  This is probably the number one reason for private cloud deployments.  The cloud is dedicated to one customer – or community of customers – that have shared goals, and more important, a shared security posture.

 

About the Author

James Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , , , , , ,
Posted in Uncategorized

What is Dev/Test as a Service (Cloud Computing)?

Dev/Test Logical Diagram

What is Dev/Test as a Service (Cloud Computing)?

Author: James Bond

A Development and Test as a Service (also called DTaaS, Dev/Test, or AppDev) cloud offering is a form of Platform as a Service (PaaS) with several unique features that facilitate application development teams.

First a Brief Description of a DTaaS cloud service

The DTaaS service consists of one or more virtual machines, each running an operating system and applications–all hosted by a cloud service provider.  There are often multiple tiers of database, application, and web front-end virtual machines that could be scaled out for more capacity/performance when deployed to a production environment.  All of the DTaaS virtual machines and applications are stored on non-production networks so that, often numerous, developers can program the applications, test, and continuously improve.  There are often specialiced Application Lifecycle Management (ALM) tools in place for the development staff to utilize as they create and test the applications.  Finally, when the application is ready quality control/review or production use, the virtual machines and applications can be copied, moved, or “promoted” to production networks and server farms–now available to the end users or customers.

Customer Use Case

Customers benefit from a DTaaS by being able to quickly launch new virtual machines within minutes, perform testing of an application, and turn off the DTaaS service when no longer needed.  Because all the servers are hosted with virtual machines in the cloud, the consuming organization does not have to pre-purchase and deploy a server farm in-house, sitting idly when an application development team has finished their work, or between application releases.

Example: A good example case scenario is where the application development team needs a new 10-computer environment deployed.  With one purchase via the cloud management portal, 10 new virtual machines are provisioned with 2 SQL servers clustered, 2 front-end web servers, 2 middleware application servers, and 4 QA workstations (for testing to be used by developer team).  Once launched, the application team can load their custom application code and begin further programming or testing.  They can add or remove additional virtual machines as needed or snapshot the environment, test the system, and roll back the entire 10-system environment back to the snapshot state – retrying their test each time based on their base snapshot image.

There are often many versions of the environment held on the storage system so the development team can roll back or forward to various software versions.  The development team can also operate multiple sets of the 10-system environment, so that the operations team can do routine testing or troubleshooting against a copy of the production/released code while the development team works to develop the next release.  This requires multiple sets of the 10-virtual machine environment, but this is economical because everything is based on virtual machines that can be brought up and down, paying only for actual usage to the cloud provider.

Features of DTaaS

Specific features of a Dev/Test environment are detailed below.  The basic offering and systems architecture is similar to IaaS, which means there is a pool of physical servers, each running a hypervisor system providing capacity for hundreds of thousands of virtual machines on-demand.

  • Isolated Dev/Test network.  Many organizations have strict policies and procedures that must be followed whenever a new virtual machine or application is installed in the production network.  In a dev/test environment, the application developers need the ability to quickly bring VMs up, reconfigure them, install application code, test it, then shut the systems down.  All of this is performed regularly during the time a development team is creating their application for production release, and can last for months.  For the developers to have this “freedom” without being restrained by paperwork, isolating the Dev/Test network from the production network using a firewall is a common technique.  Even if both the production and dev/test networks are hosted by a cloud provider, organizations want to protect their production network from untested or new application code.  In fact, some dev/test systems provide a separate subnetwork for each application project, so that one application development team cannot interfere with others.  This protects other development teams from such possibilities as an untested, ‘run-away’ application clogging the network with traffic.
  • Multiple versions, snapshot and rollback.  The ability of the application development team to make a backup or snapshot of a VM – or the entire environment – was briefly touched on earlier.  This snapshot saves a copy to disk, and allows the development team to run numerous copies of their system.  They can perform testing against a copy of their environment rather than on a single instance, and avoid potentially messing it up.  If testing is successful,,a rollback of the environment is not necessary, and this set of VMs would become the new “baseline” release.  This feature is a very significant benefit of using virtual machine/hypervisor technology, and by only paying for the usage of VMs and storage, the consuming organization truly benefits from on-demand just-in-time provisioning and shutdown in developing their application projects.  Creating numerous copies of VMs with many different versions can consume a great deal of storage space, so a great deal of storage space can be required by the system.  To keep costs low, delete older copies that are no longer needed.
  • Application Lifecycle Management (ALM) tools.  Many application development teams use application lifecycle management tools to help coordinate and facilitate the development process.  These ALM tools can be installed on one more VMs within the cloud alongside the application VMs and database systems.  The application development team uses the ALM tools to track their project milestones, maintain a code repository, perform QA checks, perform load-testing, and promote application revisions from Dev/Test into production.  Popular ALM suites in the industry include offerings from Hewlett Packard and IBM.  There are also many smaller, and even open-source. tools that an application team may use.  Additionally, some cloud service providers that offer DTaaS will offer the ALM suites as an option – this is a nice benefit, since the ALM suite will already be configured and ready for use upon ordering, and the licensing costs the cloud provider charges may be less than a single customer would pay for their own copy.
  • Promotion into staging and production.   Some dev/test offerings provide the application development team with the ability to promote individual or multiple VMs to the next phase of the application lifecycle.  For example, when all testing of an application release is completed in the dev/test environment, clicking on a “promote” button would automatically copy or move the VMs to a staging or production network within the cloud provider data center.  This automated promotion greatly speeds the deployment process when releasing new versions of applications.  Technically, this same promotion from dev/test into production can be utilized for any and all new applications, even COTS software, that the consuming organization wishes to test and configure before loading into the production network.  An additional benefit to the customer is the ability to launch a new release of their application into production while maintaining the availability of their dev/test environment for the next release.  If the dev/test VMs are no longer needed, they are simply de-provisioned and the customer stops paying for them.  I recommend keeping a copy of all dev/test VMs in storage (ie. dormant VMs not incurring costs) so you can revert to previous code should the need later arise.

Figure: Sample Dev/Test Architecture 

Dev:Test Logical Diagram

Pricing for Dev/Test offerings is typically in the same range as multiple VMs within an IaaS.  You pay either a fixed fee and/or variable fees each day/week/month for using the VMs and storage.  You can pick your VM sizes, OS templates, and storage amount just as you would in production.  You often don’t need as large a VM in dev/test as you do in production, since you are not running many active users.  This can result in savings by  ordering smaller, less powerful VMs in dev/test.  Any ALM tools you purchase will of course incur additional charges.

About the Author

James Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , , , ,
Posted in cloud, cloud computing, Uncategorized

Who Manages Cloud IaaS, PaaS, and SaaS Services

Cloud Provider and Customer Roles for Managing Cloud Services

Who Manages Cloud IaaS, PaaS, and SaaS Services

Author: James Bond

Customers of cloud services often ask who manages their cloud services.  Depending on the type of service, the cloud provider would manage everything from the data centers, network, storage, servers, and operating systems–leaving the customer to manage their own applications and data.  In other types of cloud services, the cloud provider could manage the entire system all the way up to and including the application and data.

This diagram shows a high-level view of the provide and customer roles for Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

Cloud Provider and Customer Roles for Managing Cloud Services

Cloud Provider and Customer Roles for Managing Cloud Services

About the Author

James Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , , , , , , , ,
Posted in Uncategorized

The Importance of Automation in Cloud Computing

The Importance of Automation in Cloud Computing

Author: James Bond

The automation of workflow processes is an essential part of cloud computing.  Without automation, many of the benefits and characteristics of cloud computing cannot be achieved at the price point that cloud services should be offered.  Failure to automate as many processes as possible results in higher personnel labor costs, slower time to deliver the new service to customers, and ultimately higher cost with less reliability.

What is meant by automation?  This can best be described by going through a typical example of a customer placing an order within their cloud service web-portal, and following the steps necessary to bring the service online.  The actions below illustrate a very high level scenario that cloud management software typically automates:

  1. Customer logs into web-based cloud portal, views a catalog of available services.
  2. Customer selects a cloud service such as a medium-sized virtual machine running the Linux operating system.  The service catalog shows this size of VM comes with 2 CPUs, 4GB of memory and 50GB of disk storage at a price of $250 per month.  Customer choses quantity 2 of this VM, and goes to the checkout section of web site.
  3. Customer pays for services using a credit card or an existing financial account/credit on file already with the cloud provider.  Customer completes the checkout.
  4. Customer may have an approval process in place (especially for a private cloud deployment) that requires their financial/procurement team to bless the order before it is finalized.  So the cloud management system sends an email to the designated approver of this order.  The customer approver receives the email, clicks on the URL link, logs into the cloud portal, and approves the order for $250 per month with quantity 2, or $500 per month in total.
  5. The cloud management system sees the order was approved and immediately begins the process of building the requested virtual machines. The system knows which server farms and pools of available resources it has, and automatically selects which physical server node will host the VMs initially.  Storage is allocated/assigned to the VM and a template used for the VM.
  6. The VMs are booted for the first time and any needed patches or updates automatically installed.  The cloud management system detects that the VM has launched and is ready for the customer.  It charges the customer’s credit card or deducts funds from the customer’s online account with the provider.
  7. The cloud management system send a welcome email to the customer indicating the network address and login instructions for how to use their new VMs, along with information on where to obtain documentation and whom to call for support.
  8. Customer logs into the VMs and performs any further application installations, configurations, and loading of production data.  The cloud provider manages all future system updates and ensure systems are operational at all times.  Customer manages their own applications and custom configurations themselves.
  9. Cloud management system automatically renews and re-bills customer every month (or whatever the billing cycle length is).  Depending on the type of service offered, there may also be variable expenses, such as if the customer wanted the VMs to automatically increase memory, CPU, or storage upon increased load.  The cloud management system will provide the metered resource information to the customer, and charge them accordingly.

As you can see in the above case scenario, there does not need to be a human being involved within the cloud service provider anywhere in this process.  In a real public cloud scenario, this process is repeated at all hours, thousands of times per day.  This is where the cloud provider gains such scales of economy that the customer is paying less for their cloud service then they would had they built and hosted the service themselves.  Without automated processes and cloud management systems, none of these economies of scale are possible and the cloud provider’s costs will be anti-competitive.  There are some smaller cloud providers today, that still accept orders via their web sites for cloud services, but there are numerous IT professionals manually configuring everything behind the scenes with little or no automation–this business model is usually not profitable for the provider causing less accuracy, consistency, slower provisioning, and ultimately a poor customer experience.

What to ask your potential cloud provider:

When evaluating your cloud provider choices, ask for a detailed workflow diagram or process that is followed by the cloud provider’s automated workflow system.  The cloud provider should be able to provide you a live demonstration of their cloud management platform, ordering process, and show the automated workflow as a cloud service is deployed.  This automated deployment is sometimes called orchestration or service provisioning.

About the Author

James Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , ,
Posted in cloud, cloud computing

The Evolution To Cloud Computing (How Did We Get Here?)

The evolution from mainframe to cloud computing

The Evolution To Cloud Computing (How Did We Get Here?)  

Author: James Bond

Most of us know the basic of Cloud Computing so in this blog, I will focus on why it is important to understand how we arrived at this point in the information technology industry.  I won’t spend too much time reminiscing about the past, as too many television documentaries do, but there is value in understanding the origins of Cloud Computing.

The basic concepts behind cloud computing have been part of the IT industry all along.  Dust off an old mainframe concepts book and you will be surprised by the similarities to today’s cloud computing.  History does tend to repeat itself and this applies to the computer industry as well — I will explain how historical technology trends have brought us here, how we’ve already “been here” for 30 years, and how these historic principles are still valuable today.

From Mainframe Centralized Compute to Distributed Compute and Back Again

In the early days of computer technology, the mainframe computer was a physically very large, centralized computing platform with terminals used by end-users.  These terminals could be compared to thin client devices in todays industry and the mainframe the centralized cloud computing platform.  This centralized mainframe held all of the computing power (CPU), memory, and storage systems managed by a small staff for shared use by a massive number of users.

There are further similarities when comparing mainframe computing environments to today’s cloud.  Although the mainframe was incredibly large physically, it wasn’t all that powerful in terms of memory and CPU until well into the 1980s.  What the mainframe excelled at was throughput of Input/Output processing — its ability to move data through the system.  When managed wisely, the mainframe hosted a centralized IT staff to maintain security, account management, backup/recovery, system upgrades, and customer support — all components of today’s modern cloud system.

Virtualization is another area that existed 30+ years ago, and is heavily utilized in mainframe computing.  Multiple customers and users all share the overall system, but each physical server hosts multiple virtual machines (VMs)–each VM running an operating system, applications, and having its own allocation of memory, CPU, storage, and network.  Today’s high-density server hardware is exponentially more powerful than most mainframes were 30 years ago but the practicality and benefits of virtualization have been well proven over the past three decades.

Distributed Computing

For about 20 years starting In the late 1980’s and into the year 2000, the industry began a huge shift to distributed computing with small servers (compute devices).  Each server held more memory, CPU, and storage than even the best mainframe, but had inferior levels of shared computing, shared management, and I/O performance.  After 20 years of deploying countless new, smaller servers across thousands of data centers, computer resources (CPU, memory, storage, networking) and management (security, operations, backup/recovery) are now spread out across organizations, and sometime even across multiple contractors or providers.

By most business models, the cost of managing our systems actually went up; however, the cost of compute power is a fraction of what it once was due to ever-increasing performance at lower prices each year.   Combine this with the pace of technology improvements and some in the industry started experiencing over-allocation of compute resources where large network servers had more horsepower than needed with lots of unused “idle time”.

Transforming to Consolidated Computing

Most  large organizations have numerous data centers, server farms, storage, and applications spread across offices, campuses, and cities worldwide.   Organizations have realized that the cost of these numerous and distributed facilities is too expensive and inefficient for many reasons (available skilled labor, physical location/asset costs, maintenance and upkeep, etc.).  The consolidation of server farms and data centers is in full swing both as a cost savings measure but also to better focus an organization’s IT staff.  Some organizations have come to the maturity to realize they have huge internal IT resources and costs that could better be utilized to focus on core customer-facing services rather than a huge IT department that might be better to outsource.  This will eventually bring down operational and management costs, doing more with fewer IT facilities and personnel, which are some of the costliest assets.

Servers are being consolidated at an increasing pace and achieving densities within data centers never before thought possible.  Using smaller high-density server hardware and storage systems, one-rack of equipment in a data center can easily host an equivalent of over 10 equipment racks containing legacy servers.  This consolidation of data center facilities, server farms, and storage systems is packing so many computer resources in small spaces that the data center/building’s power and HVAC are the limiting factors.  Some data centers are now utilizing alternative sources of energy, advanced air handling systems and other “green” energy technologies to supplement the normal power system (not to mention the environment benefits of drawing less power from the grid).

The Evolution to Today’s Cloud Environment

In a relatively short period of time, we have gone from centralized compute processing with thin end-user/edge devices (called terminals) to highly distributed compute environments, and are now headed back to centralized computing once again.  History is repeating itself — let’s hope we are making some intelligent decisions and doing it even better this time.  Some could argue that mainframes still play a huge role in today’s IT industry, and  they may have been the “right” business model all along.

As we consolidate many of the distributed computing platforms, data centers, and the occasional elimination of a mainframe system, it is important to realize where we are headed and why.   As we look at today’s cloud computing environment and our immediate future, decisions are being made that make this shift back to centralized computing better than it was back in the early IT days of the 1960s and 1970s.

Here are some of the benefits and challenges faced today in the shift from centralized, to distributed, and back to centralized compute (or at least a hybrid).

Benefits:

  • Managed Service contracts replaced with Cloud Service providers at less cost, less risk to consuming organization
  • Organizations pay for the usage of cloud which is carefully monitored and measured — in past managed services models, it was difficult to see actual results based on IT spending
  • Centralized compute resources, within the cloud provider, are managed by fewer personnel with heavy use of automation and consistent processes resulting in lower cost to the consumers
  • Consuming organizations do not need a sophisticated IT staff which is expensive, hard to find and keep—internal technical talent/personnel will either focus on mission critical core business services or leave/transition to work for a cloud provider.  This improves quality, maintainability, security, and reduces cost to the consumers of cloud.

Challenges:

  • Not enough proven cloud providers at this time to truly give customers a wide selection of providers to choose from.  Numerous legacy IT integrators claiming to provide cloud solutions but are essentially still legacy managed service providers.
  • Organizations have significant legacy computing resources (servers, data centers, and IT personnel) that will need to be transitioned or eliminated in order to achieve true cost savings and flexibility provided by cloud providers/services
  • Mission critical applications that are core to the business or the consuming organization must be transitioned to the cloud.  This is neither quick nor easy, and will take some time.  Businesses need to evaluate whether their custom/legacy application is truly needed and worth the re-investment, or if an alternative already cloud-enabled service is a better fit in the long-term.
  • Procurement and budgeting for cloud services is a challenge to some commercial and government organizations.  Existing procurement policies may need to be adapted.
  • Existing security, operations and other processes within consuming organizations need to adapt to this new cloud computing model.

Where Are We Now?

Organizations now understand they may not be in the IT industry, and are therefore taking this opportunity to outsource their IT computing needs to cloud providers.  They are not just outsourcing labor to an IT contractor this time, as was the norm over the past 20 years, but are hiring truly established cloud providers offering a pay-per-use service at little or not capital expense.  The burden of building, maintaining, upgrading, and operating the compute systems is the responsibility of the cloud provider — giving the consuming organization ultimate flexibility and choice of providers without being locked in to one.  This results in faster deployment of services at a lower cost, so that the consuming organization can focus on their core business functions and customers, not on their IT department.  This is the paradigm shift that has taken 30 years to achieve.

Cloud computing results in faster deployment of services at a lower cost, so that the consuming organization can focus on their core business functions and customers, not on their IT department.  This is the paradigm shift that has taken 30 years

So where are we headed in the cloud industry?  There will be a reduction in the use of traditional “managed services” and “time and materials” IT contractors providing computer services labor.  Both small and large consumers of the cloud will be able to select the provider, pay for the services utilized, and terminate their agreement if finances or priorities of the business change.  Organizations won’t be stuck with unneeded computer systems, server farms, and data centers, leading to greater agility in their overall business decisions.

About the Author

James Bond is a Chief Technologist with Hewlett Packard Enterprise Systems.  His role within the U.S. Public Sector region is to educate and guide customers and internal HP account teams on cloud computing, design/deployment of public, private, hybrid clouds, and cloud brokering.  Mr. Bond has over 25 years experience with data centers, server farms, systems architecture, deployment, and operations.  Mr. Bond is a subject matter expert and trusted advisor to customers on Infrastructure, Platform, and Software as-a-service in private, public, hybrid, and cloud broker deployment models.

Tagged with: , , , , , , ,
Posted in cloud, cloud broker, cloud computing
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: