When Public Cloud Isn’t Public

One of the key misnomers in cloud technology today is the idea of “public cloud”.  In our work with clients, and especially when discussing Infrastructure as a Service providers such as Amazon Web Services, we invariably have to walk some potential clients off the “public cloud” ledge.  Companies such as AWS are immediately labeled “public” simply because the public can access it.

In fact, we recently worked with a client that asked if AWS could meet the NIST definition of “private cloud.”  The answer is emphatically yes.  NIST defines private cloud as:

[C]loud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
– NIST Publication 800-145, The NIST Definition of Cloud Computing, at pg. 3.

It is a simple two-sentence definition, so let us look at what is there and why AWS can qualify as a private cloud.  Quite simply, the use of the AWS Virtual Private Cloud provides the exclusivity that is required for private cloud status.  Per the AWS web site, VPC:

…lets you provision a logically isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

The client, of course, does not directly own the physical AWS hardware but the logical isolation afforded by the use of VPC allows the deployed AWS infrastructure to be exclusive to the client.

The second sentence’s key component is that the term “combination”.  In the case of the Federal Government, the combination is key.  As we encourage all of our clients to do, they should own their own account, meaning the Government owns the AWS infrastructure (above the hypervisor), manages that infrastructure, and operates the infrastructure.  If it chooses, a third party provider, such as JHC, can also handle the management and operation – the “third-party” NIST identifies.

At the end of the day, cloud knowledge continues to filter down, and we are always happy to provide as much of it as we can.  I hope that we will quickly dispel the misnomer of AWS and others as public clouds simply because the public can use the infrastructure.  Once deployed correctly, AWS and others transition directly into private clouds.

Matt Jordan is the Cloud Services Manager for JHC Technology. He can be reached at mjordan(at)jhctechology.com, @matt_jhc, or connect with him on LinkedIn.

 

 

 

­­Non-Technical Cloud Barriers: What Do I ­­Do With My Datacenter?

Some of the most common questions that I receive from customers about moving to the Cloud are centered on the following: 

• How do we justify going to Amazon Web Services (AWS) Cloud solution when we just bought new hardware for our organization? 
• What do I do with my old hardware and datacenter?

These are actually valid questions that businesses should be asking when moving to an Infrastructure as a Service (IaaS) Cloud solution.  AWS has shown to have significant financial saving for most organization over short term and long term analysis; however, supporting current operations and translation of service from on-premise to AWS still has it’s initial investment that are not realized immediately.  JHC Technology recommends the following approaches based on specific organizational business requirements to help transition to AWS while taking advantage of previous datacenter and hardware investments.

Disaster Recovery failover, High Availability Service, and/or Network Extension

Organizations can make use of Amazon Web Services (AWS) as a disaster recovery failover, high availability service, and network extension (example: Reduce latency for remote offices).  Instead of taking the hard stance of all or nothing, organizations that have already invested into their physical datacenter hardware can still take advantage of AWS to address other business requirement.  Sample business requirements:

• Improve disaster recovery by using AWS regions for failover

• Enhance network performance by bring datacenter closer to the end user

• Development and Test Labs

New Business Requirements and Hardware Refresh

It is unrealistic for some organization to move all datacenter operations 100% to the cloud in a short period of time.  Some reasons are contractual obligations, classification of content, migration complexity, and/or education/skill set of resources.  Understanding these business constraints is extremely important as your organization moves to the cloud and JHC recommends incorporating a methodology that utilizes AWS for new business requirements.  Additionally, implementing a change control process that will allow the organization too slow transition infrastructure/services to AWS during hardware refresh cycles, thus getting the most return on your physical infrastructure investment.

Recycle/Go Green

JHC Technology has designed a process that provides the logistic and recycling capability for customers to recycle/exchange physical infrastructure into financial credits that are used to offset Amazon Web Services costs.  The program is available for international and/or domestic:  Commercial, State, Local Governments, Non-Profits, and Federal Government.  This program allows our customers to recoup investment into datacenters, helping improve the environment, and assists in offsetting cost of AWS.

Check out other blogs in the Non-Technical Cloud Barrier Series.

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas(at)jhctechnology.com, @JHC_JamesHirmas, or connect with him on LinkedIn.

Non-Technical Cloud Barriers: Does the Cloud Take My Job Away?

A common question that I receive from people looking into Cloud technology is: “Does the Cloud get rid of my job?”  Mostly I receive this question from System Administrators, Server Engineers, and Network people.  In most cases the answer to this question is a resounding no; however, it will change the day-to-day focus of these resources by simplifying common tasks (through automation) and removing physical operational tasks (racking and stacking infrastructure in datacenters).  This transition, however, does not come without a cost.  In order to work proficiently in Cloud technology (specifically IaaS), resources will need to be educated and trained.  Fortunately, the training path and adoption is rather quick.  In most cases, technical resources immediately see the value to moving to Infrastructure as a Solution providers like Amazon Web Services.  Moreover, by removing physical operational tasks and simplifying common tasks it opens up opportunities for these resources to focus on enhancements of the user experience through:

1.       Optimization of network, applications, storage, and compute;

2.       A more flexible secure working environment;

3.       Streamlining of the Change Management Process;

4.       Disaster Recovery and COOP

Optimization Examples

·        Networking:  Architecting solutions that bring datacenter, network, data, and applications closer to the end user, thus reducing latency in world-wide deployments.  Few examples:  Utilizing AWS World Wide Regions and Availability Zones, AWS Direct Connect between Organizational datacenters and AWS regions, and AWS Route 53.

·        Applications:  Making legacy applications cloud aware by migrating and re-engineering applications to cloud platforms and decoupling traditional dependencies of application on data and compute.  Few examples:  Utilizing AWS Simple Queue Service, Simple Notification Services, and Simple Workflow Service.

·        Storage:  Simplification of a storage archive by utilizing cloud storage solutions.   Few examples: AWS’s Elastic Block Storage, Simple Storage Service (S3), and Glacier.

·        Compute:  Use the power of cloud computing to automatically provision compute when you need it and scale down compute when you don’t need it.   Few Examples:  Cloud Formation, Elastic Compute Cloud, Auto Scaling, and Elastic Load Balancer.

Flexible Secure Environment Examples

·        Resources and Organizations can now take advantage of cloud security enhancements and focus on the following:

o   Zero Trust Models

o   Two-Factor Authentication

o   Identity Access Management

o   Certificate Key Pair in order to manage infrastructure

Change Management Process Examples

Organizations and resources can improve the change management process:

·        Quickly and cost effectively provision Development and User Acceptance environment as part of the overall change management process.

·        Utilize third party tools like CloudCheckrd that monitor utilization, change control, and compliance of your AWS environment (CloudCheckr)

Disaster Recovery and COOP Examples

The Cloud allows a simplified path to Disaster Recovery for organizations that logistically or financially could not implement DR solution:

·        Utilize multiple stage disaster recovery on AWS to fail over between Availability Zones and AWS Global Regions.

·        Enhanced disaster recovery options available on AWS include Active-Active Disaster Recovery across regions.

·        Utilize AWS built in fault tolerance for compute, network, and storage.

The accessibility and cost effectiveness of Cloud platforms allows businesses to expand their infrastructure, thus providing opportunities for staff to expand their knowledge base and focus on improvement of the over user experience.

Check out other blogs in the Non-Technical Cloud Barrier Series.

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas@jhctechnology.com, @JHC_JamesHirmas, or connect with him on LinkedIn.

Non-Technical Cloud Barriers Series

Over the last four years working in the Cloud IaaS arena, I have come to the realization that many of the “Barriers” Organizations face when moving to a Cloud IaaS platforms (like Amazon Web Services) have less and less  to do with technical issues but more to do with what I like to call “Non-Technical Cloud Barriers.”  Cloud platform providers have made technological leaps over the last 6 years that have resolved the majority of the Cloud technical limitations for industry specific clients (i.e. Banking, Government, Healthcare, etc).  Additionally, cloud vendors, like AWS, have made it a priority to provide industry compliant cloud platforms that meet the following certifications/compliance:

• SOC 1/SSAE 16/ISAE 3402
• SOC 2
•  FISMA, DIACAP, and FedRAMP
•  PCI DSS Level 1
• ISO 27001
• International Traffic In Arms Compliance
• FIPS 140-2
• HIPAA
• CSA
• MPAA

Now that the IaaS Cloud platforms have matured from a technology perspective, the “Non-Technical Cloud Barriers” have become a focal point of the Cloud funnel.   These “Non-Technical Cloud Barriers” can account for Cloud IaaS project stalling and endless meeting loops that tend to spin out of control.  Some of these barriers include, but are not limited to:

• How do organizations procure cloud services in a non-friendly, pay as you go model (i.e. firm fixed price model)?
• How do organizations justify going to an IaaS cloud platform when they just bought new Hardware for their organization?  What do they do with their old hardware and datacenter?
• The Cloud is less secure  than my own datacenter
• If we move to the cloud and we don’t have our own datacenter then is my job going away? 
• Traditional infrastructure vendors adapting to organizations wanting to move to cloud computing.
• Overall lack of education on Cloud computing
• General fear of Cloud computing solutions
• How do I change our IT organizational processes (Change Management, IT governance, approval process, lifecycle…) to Cloud computing model?
• Overwhelmed by the “end solution” and missing sight of low hanging fruit (Quick wins).

The purpose of this blog series is to address these “Non Technical Cloud Barriers” and provide organizations looking to move to IaaS Cloud platform the information necessary to remove and/or mitigate these Non-Technical roadblocks before they become significant impacts on their migration to IaaS Cloud Platform.  The first article in the series will be released in May and will address the following topic; “How do organizations justify going to an IaaS cloud platform when they just bought new Hardware for their organization?  What do they do with their old hardware and datacenter?”

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas(at)jhctechnology.com, @JHC_JamesHirmas, or connect with him on LinkedIn.