INAP IS NOW HORIZONIQ.
Click here to LEARN more.

Sep 18, 2017

When Should I Use a Hosted Private Cloud?

INAP

In our eBook, 4 Economic Benefits of Hosted Private Cloud, we highlighted the differences between a hosted private cloud and an on-premise private cloud. In this blog, let’s explore the question: When should you use a Dedicated Hosted Private Cloud?

In a hosted private cloud model, the infrastructure, data center facilities, power and cooling and a variety of services and security options are provided by a service provider. Conversely, with an on-premise private cloud model, the infrastructure, data center facilities, power and cooling are provided by your IT staff.

Hosted Private Cloud Considerations

When choosing a hosted private cloud, consider the options and functionality of both virtual private cloud (VPC) and dedicated private cloud (DPC) solutions and the importance of each to your application and IT resources.

What Are Virtual Private Clouds?

VPCs are multi-tenant, logically isolated cloud computing environments. Use cases where VPCs make sense include applications that have significant variable computing resource usage, do not require physical isolation of data for security purposes or smaller deployments that cannot justify dedicated hardware.

What Are Dedicated Private Clouds?

DPCs are fully isolated single tenant hardware nodes dedicated and customized for a single client, providing on premise experience coupled with the benefits of the cloud. DPCs offer dedicated compute and firewall resources to the client and the ability to access the underlying hypervisor. DPCs are ideal for large environments, compute/memory intensive and legacy applications, complex architectures, highly customized configurations or applications that require the physical isolation of data for security purposes.   

Let’s dig into some of the key attributes of a Hosted Dedicated Private Cloud in more detail.

Secure, Dedicated Compute and Networking Infrastructure

The DPC compute and network infrastructure is 100 percent dedicated to you. No risk of a noisy neighbors rogue application consuming shared compute or network resources.This becomes important for applications that are compute and memory intensive or if you have PCI or HIPAA compliance requirements. Shield Managed Security included free with all private cloud hosting solutions. Upgrade option to Shield Plus for advanced network and application-level security.

Rightsizing and Investment Protection

Solution design and rightsized environments mean you won’t overpay for resources you don’t need — a proven mechanism for reducing server sprawl. Typical DPC deployments have a minimum of 2-3 nodes and are running at least 30 virtual machines. We’ve found that smaller deployments would be more economical on our Hosted Virtual Private Cloud platform. Spin up unlimited VMs at no additional charge. You only pay for the reserved cloud resources providing a predictable model with flexibility to scale for special projects or growth.

Every INAP Hosted Dedicated Private Cloud is purpose-built from the ground up and starts with a Free Private Cloud Architecture Consultation by our expert engineering team to custom design your DPC and ensure it meets your requirements.

Flexible Managed Services You Control

Managed services allow IT teams to focus on tasks and projects that move the business forward as opposed to simply “keeping the lights on.” Leverage our expertise and remove the burden of routine infrastructure and OS management from your IT organization’s support queues. With INAP, you’re always in control. We offer flexible managed services — fully managed or co-managed. Let us do the busywork. Take over whenever you need.

As you evaluate your requirements and use cases, other questions will arise and we’re here to help, please reach out to us. We’d love to hear from you!

Updated: January 2019

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

INAP

Read More
Sep 14, 2017

Current Trends in the Public Cloud: Hybrid Cloud Services

INAP

Have I mentioned that I love RightScale’s annual “State of the Cloud Report”? This year’s report was full of several great nuggets of data. The main theme continues to back up the previous year’s forecasts of cloud adoption: the industry, especially larger enterprises, have adopted a hybrid cloud strategy to move further towards the cloud.

What is a Hybrid Cloud?

The RightScale report talks briefly about private clouds working in conjunction with public clouds. At INAP, however, we understand that hybrid cloud strategies come in many forms. Not only can we offer colocation for customers to build their own private cloud, but we also have a robust OpenStack public cloud offering for other workloads.

In fact, a “hybrid” approach is 100% feasible solely within our Agile Public Cloud offering. Let’s look at some of the options.

Our AgileCLOUD is the traditional virtual public cloud offering. Our AgileSERVER is our bare-metal cloud offering where DevOps teams can provision and manage dedicated bare-metal instances in a cloud-like manner. Both products are powered by OpenStacks’s standardized portals and API toolset for seamless management. Both the virtual AgileCLOUD and the Bare-Metal AgileSERVER allow customers to leverage each environment’s unique strengths in handling differing workloads.

Why Choose a Hybrid Cloud?

There are a few reasons why INAP’s AgileCLOUD could be ideal for your cloud needs. First, we can support bringing your own VMware license to our cloud. In a recent post, I talked about the option of using your existing investment in our AgileSERVER without any complicated conversion process. This is a major benefit, especially if you’re moving from an existing environment.

Second, some applications and workloads do not perform as well in traditional public cloud deployments.  The heavy I/O and transactional requirements of a MySQL or MS SQL database typically necessitate more CPU, Ram and disk I/O than a virtual cloud can offer. This is where our AgileSERVER outshines the competition.

We offer three series types:

  • Deploy on Demand – 12 preconfigured server builds that are instantly provisionable via our portal or the OpenStack API
  • Upgrade on Demand – 72 upgraded server builds that are provisioned in 24 hours or less and are then manageable via our portal and the OpenStack API.
  • Order on Demand – A virtually unlimited number of configurations to meet the highest performance needs customers may have, custom ordered to your specification.

The important thing to keep in mind here is that our AgileSERVER lineup provides access to the full processing power of dedicated servers to meet unique requirements of high-performance workloads and applications. This gives the customer cost efficiency on the public cloud side, while maintaining or increasing performance. This is critical when dealing with NoSQL databases like Hadoop, Cassandra, Mongo, Aerospike, etc. Those platforms require a higher number of IOPs to run properly, and virtual cloud won’t provide the levels of performance the customer expects – bare metal can.

Finally, AgileCLOUD is specifically suited for web, application and other non-I/O intensive workloads. It is also ideally suited for elastic workloads to support bursting in peak hours.

We offer two series types:

  • A Series – For small databases, websites and content management systems that require moderate network throughput.
  • B Series – For medium databases, complex websites and scheduled batch processing tasks that require additional memory and higher network throughput.

Like the AgileSERVER instances, these are provisioned through our portal and via the OpenStack API set.

Connecting You to Hybrid Cloud

With so much focus on hybrid cloud strategies in current networking outlets and research reports, we urge you to keep an eye on your performance for cost. As our unique bare metal approach continues to meet increasing big data demands, you may want to see how INAP can help you build a hybrid strategy to free up resources so you can continue to focus on projects that add value to your organization’s mission.

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

INAP

Read More
Sep 13, 2017

Designing a Private Cloud for PCI Compliance

Ryan Hunt, Director of Content & Communications

If your organization stores or processes credit cardholder data, here’s a fact you’re probably already quite familiar with: Maintaining PCI DSS compliance internally is no easy feat.

Points of weakness for a data breach can occur anywhere in the network chain. Without proper isolation, that makes identifying and monitoring entry points for unauthorized access a huge operational headache.

So what does proper isolation look like? Check out the following example using an INAP Dedicated Private Cloud.

Isolated Security Zones in a PCI Compliant Private Cloud

PCI compliant private cloud reference architecture

Employing multi-layer security architecture, the Cardholder Data Environment (CDE) in the above architecture diagram is securely isolated from other networks and applications in the cloud.

(Note: This configuration will also work for dedicated server architectures and the security principals outlined apply generally to a broad range of use cases.)

Let’s go through it step-by-step:

  1. A shopper accesses an e-commerce retailer’s website from the public web.
  2. The customer’s request is first sent to a Load Balancer, which helps maintain application and network stability by distributing traffic to web servers based on the number of existing connections. Each load balancer includes a SSL certificate that encrypts and authenticates each session.
  3. The load balancers also contain a Web Application Firewall (WAF), which protect against application-level coding issues that may allow illicit requests to enter the protected network and permit cardholder data to be exposed.
  4. When the customer is ready to make a purchase and enter their credit card number and personal information, the request leaves the web network (the DMZ) and enters the CDE (Trusted Zone). After passing through a redundant firewall, the request goes directly to the application servers, which power the payment portal. Note that the application servers process business logic for the website while the web servers render web pages and communicate with customer browsers. The firewall only allows the web servers to communicate with the app servers, securing the customer’s checkout process.
  5. The app servers communicate directly with the database servers, which search and store records. In this example, a clustered pair shares the data, though this could be a single VM.
  6. The AD servers (Active Directory) are required for server clustering. However, some environments may use AD or LDAP (Lightweight Directory Access Protocol) for storing usernames and credentials.
  7. But here’s the important thing to remember – passing a PCI DSS Audit requires more than just isolating and securing the CDE. You must ensure procedures are in place and resources allocated to monitoring and scanning to comply with specific sub-requirements. If you’re an INAP Shield Plus Compliance customer, that’s covered for you.
  8. Threat Manager is a combined intrusion detection sensor (IDS) and vulnerability scanner.  The vulnerability scanner meets a sub-requirement designated in the PCI DSS, which dictates that scans be performed quarterly. Threat Manager allows for more frequent scanning, however, and includes the option for on-demand scans, providing the INAP Shield Plus Security Operations Center (SOC) team with up-to-date information on the environment. The IDS sensor included in Threat Manager is also required under the DSS and is monitored 24/7 by the SOC.
  9. PCI DSS requires that logs be inspected daily. With Shield, technicians take care of these critical, but tedious, inspections for you. Log Manager streamlines all your logs, including operating system event logs and application logs, into a single, chronological list so that logging can be more easily correlated.
  10. The Management Zone, which includes cloud backups and your cloud management console. This has restricted access and is well-protected using two factor authentication for administration.

Updated: January 2019

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

Ryan Hunt

Director of Content & Communications

Read More
Sep 8, 2017

Internap is Now INAP

INAP

Last week we had the privilege of ringing the Nasdaq stock market Closing Bell to celebrate INAP’s new identity. The evolution of Internap Corporation (INAP) has been underway since Peter Aquino joined INAP nearly one year ago. Changes have and are being made to improve the company, our products and services, and our customer experience, but with change also comes questions. We’d like to address some of the larger changes in hopes of answering the most common questions.

New Executive Leadership Team and Alignment under Two Business Units

One of the first major initiatives was to hire a new, geographically disperse executive leadership team and align the organization around two pure-play business units that we now refer to as INAP COLO and INAP CLOUD. Our new leadership team consists of very experienced individuals with strong track records of success. They reside in various parts of the U.S. and Canada to ensure they are in tune with our customers and the employees of those different markets. Organizing around two business units, each with their own general manager, allows for more autonomy and accountability so we can better support our customers’ needs in a way that more closely aligns with the market.

Improved Financial Position

In the first half of 2017, we raised $43 million in a common equity private placement and completed $300 million in senior secured debt refinancing. This increased financial flexibility bodes well for the confidence of our investors and lenders regarding the future of INAP. Our company is financially healthy and poised for growth. We will continue to invest in enhanced products and management tools for our customers, new data center locations and growth at our existing data centers.

Updated Branding

To demonstrate our commitment to the future growth of INAP and create an enduring reminder of the accountability we owe our customers and investors, we’ve rebranded the company to better align with our stock ticker symbol – INAP.

As we continue to roll out this new brand, we refocus our efforts on the values that are at the heart of our success:

Integrity: We believe in being honest — with ourselves, with each other, with our customers. It’s this expectation of integrity that sets us apart.

Quality and Service Excellence: We’re proud to offer superior colocation, cloud, managed hosting and network services, but we believe our most important attribute is our superior customer service. Every employee’s top priority is taking care of our customers.

Mutual Support, Teamwork and Generosity of Spirit: We have a strong team to thank for our innovative approach to internet connectivity, so we’re committed to integrating collaboration into every aspect of our corporate culture.

Innovation and Creativity: We can only move ahead by continually generating new ideas and critically evaluating ourselves. Our creativity is instrumental for our future.

We have embraced this past year as a year of change and welcome the refocus on running our business for the long-term.

We are INAP!

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

INAP

Read More
Sep 7, 2017

How to Provision Your AWS Infrastructure with Terraform

INAP

There are a number of tools out there to help you provision and make changes to your AWS infrastructure. Each have their own strengths and weakness. One such tool which we use here at INAP is a product from HaishCorp called Terraform. Terraform is a powerful tool that lets you provision AWS services as Infrastructure-as-Code or IAC. There are many other tools that let you provision IAC such as Chef, Puppet, Ansible or Cloudformation, but I  think Terraform offers several advantages.

However, Terraform can, at first glance, be a daunting thing to understand. Although the documentation is fantastic, there are many commands and many variables for those commands. In this article, I’ll introduce TerraForm by building a simple network configuration example in AWS. We will be designing for a basic web application that will have three layers – Load Balancers, Application Servers and RDS or database instances.

AWS Terraform

First, we will need to declare some variables prompted by the TerraForm application. These are simply the AWS Access key and Secret key. For information on obtaining these please see this guide from Amazon.

variable “access_key” {}

variable “secret_key” {}

variable “region” {

 default = “us-east-1”

}

Next, we will create a basic VPC and use the following subnet 172.17.0.0/16.

resource “aws_vpc” “prod-main” {

 cidr_block  = “172.17.0.0/16”

   tags {

   Name = “prod-main”

 }

}

Now we will need subnets inside of the VPC to use to host our application. Since we always want to design for maximum availability we need to ensure that no service rests on a single Availability Zone (AZ). To that end, we are going to create six subnets in total – two each for our Elastic Load Balancers, EC2 Instances, and our RDS instances.

resource “aws_subnet” “app-main” {

 vpc_id     = “${aws_vpc.prod-main.id}”

 cidr_block = “172.17.10.0/24”

 availability_zone = “us-east-1a”

 

 tags {

   Name = “app-main”

 }

}

resource “aws_subnet” “app-secondary” {

 vpc_id     = “${aws_vpc.prod-main.id}”

 cidr_block = “172.17.11.0/24”

 availability_zone = “us-east-1d”

 

 tags {

   Name = “app-secondary”

 }

}

Note that the above block of code creates the subnet for the application layer and uses the us-east-1a and 1d AZs so that we can place our EC2 instances in both those zones. We will repeat the above for the ELB and RDS layers.

Next, we will create an internet gateway and attach it to the VPC.

resource “aws_internet_gateway” “gw” {

 vpc_id = “${aws_vpc.prod-main.id}”

 

 tags {

   Name = “maingateway”

 }

}

The last thing we need to do is create some security groups, specifically a security group for our ELBs allowing access to port 80.

resource “aws_security_group” “elb-main-sg01” {

 name        = “elb-main-sg01”

 description = “Used for the ELBs”

 vpc_id      = “${aws_vpc.prod-main.id}”

 

 # HTTP access from anywhere

 ingress {

   from_port   = 80

   to_port     = 80

   protocol    = “tcp”

   cidr_blocks = [“0.0.0.0/0”]

 }

 

 # outbound internet access

 egress {

   from_port   = 0

   to_port     = 0

   protocol    = “-1”

   cidr_blocks = [“0.0.0.0/0”]

 }

}

Once you complete this activity, you should be able to see just how powerful a tool Terraform is for creating IAC for deployment in AWS.  Better yet, the application also allows you to make changes to the IAC and only deploy those changes to AWS as opposed to a complete teardown and rebuild.

You can download the full Terraform AWS Network Template [.zip] here.  If you have any questions, reach me in the comments. Or if you’re looking for someone to design, optimize and manage your AWS environment, get in touch today.   

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

INAP

Read More