Blog

1. Increased competitiveness
2. The combined solution becomes easier to sell
3. The combined solution becomes easier to buy

The first and second cases are very closely linked.  A sales person’s job is made much easier if they can offer a prospect a “two for the price of one” argument.  The problem is, through this conversion of providing greater value to the customer, value in the form of potential additional revenue to the vendor is destroyed.

Using the cloud, we can make individual software components available with a business model that better fits the use model.  Isn’t this the path to customers gaining greater value from their vendors, and vendors capturing growth through innovation?

Posted under cloud, industry

It has been wonderful to discuss with software vendors both large and small their transition to the cloud.  And as you would expect, security is very much “top of mind”.

After reading a post by Olivier Coudert, I decided to provide a high-level description of some of the main techniques used to secure a cloud implementation.  Hopefully it’s useful when considering a cloud (Infrastructure-as-a-Service, IaaS) or platform (Platform-as-a-Service, PaaS) provider.

Most of our customers use our platform with the Amazon cloud.  And so the infrastructure portion of this discussion will be taken from their implementation, described in more detail in their white paper.  (One of the primary reasons why we built our platform on top of Amazon’s infrastructure is because of their security.)

The areas to consider are illustrated below.  The user (client) on the left, and the public or private cloud on the right form the two end-points.  The communication network in between (what we used to call “the cloud”, before there was “The Cloud” ) is the other key component.

End-points to Cloud Security

The Cloud - Physical Security

This is the most fundamental of considerations.  Not only is it important if your data is valuable, but if you’re in a public cloud consider what else could be stored and valued in the same physical location.

The Amazon Cloud boasts extensive physical security measures, protocols, and technology, including “military grade perimeter control berms” and other “natural boundary protection”.

The Cloud - Logical Security

Firewall

Many breaches of security come from bots pinging IP addresses on multiple ports, mechanically looking for a way to get in somewhere (Port Scanning).

This type of attack is prevented at the Firewall:

(i) Close all ports except those that are to be used.  And only open those when they are actually used.

(ii) Restrict access by the protocol used (http, ssh, etc.)

(iii) Restrict access to only known client IP addresses.

In addition to this, AWS detects port scanning, stops it and blocks it.  Counter measures are also in place to protect against Distributed Denial of Service (DDoS) and Man In the Middle (MITM) attacks.

Operating System (Host and Guest)

Operating System Security

The Host Operating System that resides on the actual hardware needs to have strong key access to a limited number of Administrators.  No one else should have access at this level.  And those that do have access should only have it on a limited basis and only when they are doing actual work.

Guest OS’s (the virtual instances that are actually used by the hosted software) are isolated from the Host by the hypervisor (which also provides isolation between running instances).  Unprivileged Access to these instances should only be allowed via token or key-based authentication.

Key control is paramount for success at this level.

Data - Backup & Encryption

All stored data should be redundantly backed up, ideally (as with AWS) in multiple physical locations.  In addition, data can be encrypted on the remote instance.  In fact, encryption can be taken down to a very low level, but performance trade-offs come into play very quickly.

The Network

Other than protection from threats residing elsewhere on the network, data interception should be protected against.  Therefore, data traveling across the network should be encrypted.  In our case, we implemented communication and data transfer protocols that use AES-128 symmetric key encryption for all data sent between the client and the cloud server.

The User

After all of the above (and much more) has been put in place, we still need to provide access to users (customers) outside of the firewall.  And so we need to know who the users are, and to be able to confirm that they are indeed who they say they are.

In order to scale the business, the authentication and validation process must be automated and built into the on-boarding and access process.

Fortunately, as we’re dealing in a business-to-business environment, the easiest and most reliable way to automatically confirm identity is via an email validation process during user on-boarding.

Once validated and prior to accessing the cloud, the user’s identity should be authenticated again using the email address (or a username linked to the email address) and a password.

On the Xuropa Platform, we go one step further and add an additional security protocol to ensure that only the previously authenticated user can gain access to the cloud from a detected IP address.

Life’s a Trade-off

These are just a few of the techniques employed - when it comes down to it, anything is possible.  However, people need to have access, and in order for businesses to run, access needs to be straight forward for the user, monitored, controlled, and automated.

In architecting our platform, security is paramount, which means we have to put a great deal of effort into automation and the user experience (UX) design.

How are you securing your cloud processes?  And what are your concerns related to security?

Posted under Xuropa, cloud

Infrastructure-as-a-Service Breakdown

There’s an interesting post by Advanced Systems Group that provides the top-level costs they were able to derive from an internal study they did to compare public and private cloud implementations.  It’s the start of a good discussion (questions/comments I posted are still in moderation).

Their post compares three different cloud options from a cost perspective: 1) Public Cloud from Amazon EC2; 2) Purchased Private Cloud infrastructure; and 3) Leased private cloud infrastructure.

All three systems were based around the equivalent of (using AWS parlance) 10 Extra Large CPU instances, 60 Large CPU instances, and 30 Small CPU instances.

The cost calculations were run by ASG over 3 years assuming an increase of 15% in compute demand, and not accounting for depreciation.

When ASG noted in an answer to a comment that all instances are assumed to be running 24/7 my curiosity was piqued to drill in a little bit.  The problem is, solely comparing private and public based upon 100% utilization removes one of the most compelling reason for the cloud - a pay-as-you-use model.  It skews the conclusion from the start.  (How many data centers run at 100% utilization anyway?)

Also, from a rough calculation, we can see that their Amazon numbers appeared to be based upon the cost of On-Demand Instances.  24/7 utilization over a three year period is not a cost effective use model for the On-Demand pricing model.

Performing a straight hardware costs calculation, (I’m assuming that ASG were adding in some additional costs for storage and data transfers to get to their top line numbers, as I couldn’t get there from a simple calculation.  Their 3Yr cumulative cost for the Public Cloud scenario was slightly over $1M, where as mine below came in slightly under), I got the following top line numbers for an On-Demand instance scenario (the least economical).  For completeness, I also added in the two more sensible scenarios of either a rolling 1 Year Reserved Instance model or a one-time 3 Year Instance model.

Public vs Private Cloud Costs (100% Utilization)

And so, taking these basic calculations in isolation of all other considerations, we can see that from a purely hardware resource expenditure perspective, a Public Cloud implementation is roughly the same or even less than a private cloud implementation.

However, this is still only part of the story.  As mentioned, a key draw to public cloud computing is the elasticity of the model - Pay-as-you-Use.  And so, considering a selection of rough percentage utilizations, we get the following breakdown of the different hardware costs of a public cloud implementation.

AWS Public Cloud Costs: Time vs Model vs Utilization

The comparison relative to utilization becomes even more stark when charted.

Cloud Cost Comparison vs Percentage Utilization

Not only is AWS more economical over utilization rates over extended periods, but it provides flexibility.  For example, if the software used on the servers is upgraded (as is likely) and hardware requirements increase (equally likely, given history), moving an image (AMI) from a Small to a Large instance is straight forward (for an “IT guy”).  No hardware needs to be thrown out or shipped in.

Additionally, there is some flexibility around migrating across business models.  Of course, it is easier to upgrade than downgrade

Posted under cloud