Over the past few weeks I’ve been asked what’s my view on adoptions barriers and challenges when moving application to the cloud (either public or private), specifically as it relates to large organizations. I’ve shared those views with several of our customers and prospects on EC2 (big as well as small) and I thought it would make sense to blog about this as well.
Security
This is probably the first question people ask. Can I put my application on a public cloud? My first answer is why do you think your data center is more secured than
Amazon's,
GoGrid's,
Flexiscale,
Joyent, etc.. (same analogy of money under the mattress and banks a few decades ago). My second is answer is that you should go with the Cloud provider that satisfies your concerns (e.g. a cloud vendor called
AppNexus is providing advanced security features designed specifically for hedge funds requirements), while having the flexisbility to move from your own data-center (or “internal/private” cloud as it’s called today) to the cloud of your choice. Obviously this is not a trivial thing to achieve without a framework like
GigaSpaces.
When drilling down to this question I find it interesting that in some cases security comes down to – what happens if I’m running the business logic outside the cloud and the data inside (is the client-server traffic secured?) and what happens when I need to persist the data (e.g. flash to
S3 or
EBS in the case of Amazon) to maintain a runtime state. If this is your security concerns then GigaSpaces can help reduce both – with
Space Based Architecture, logic and data are running together in the same in-memory process (in the same Amazon Machine Image - AMI in the case of
EC2). As for latter, you can keep your runtime data partitioned in-memory across any number of AMIs (while having one or more in-memory backups for each partition) without the need to persist it to S3. (note also the performance implication of this later in the post)
In addition partitioining is a great soltution for "not keeping all the eggs in one basket", or in this case all the data in one AMI. This can serve as a secutirty mechanism as well as a way to "control and contain" a pontetail damage (see the Audit section below).
Please read the recently released
Amazon Security White Paper, I think this long-awaited paper helps address some of the common security concerns as well.
Reliability, SLAs and data loss
The second most common concern is “Amazon does not provide SLA”, “What happens if my AMI fails”.
The whole idea behind sharing recourses in a virtual environment is that you shouldn’t care about the availability of a specific resource. In other words, nodes in the cloud can and will break. Amazon will undoubtedly provide some sort of SLA very soon, other vendors like
GoGrid or
Joyent offers it today, but none of these SLAs will truly cover zero data loss and data reliability. The reason for that is simple (and accurate in my view), this is the responsibility of the application architecture and not the cloud provider. The question one is asking, does this mean I need to develop my own reliable data-layer, the answer in most cases is yes.
However,
XAP Cloud Application Server solves this problem out-of-box. So if you are using GigaSpaces on EC2 for example, you really don’t care if you’re AMI fails, your application will fail-over , at in-memory speeds to another AMI that is running a “hot” backup. The result - zero data loss and zero downtime.
Persistency is another painful issue with regards to reliability. I believe all cloud vendors will have issues in making cloud persistency available in a high-performance reliable manner (our customers are having a lot of issues with
S3, and thank you Amazon for releasing
EBS). Ironically, the the cloud vendor is not at fault, it is the tier-based architecture itself. Cloud environments simply “shines” the need to persist a-synchroniously to the “cloud disk”, while having the run-time data partitioned in-memory across many nodes. This is exactly why our
cloud framework includes support for GigaSpaces
Mirror Service.
The risk of complexity or the “hidden costs of the cloud”
I agree with
Nikita that deploying and developing to the cloud involves complexity and architectural challenges. It is somewhat ironic that the cloud offers enormous potential in terms of cost saving and efficiency but at the same time can introduce considerable hidden costs (thank you
John Willis for this coining the term). I believe cloud vendors and solutions like
RightScale will make it simpler to use the cloud as we move forward, but the fundamental fact will not change – moving a complex application (specifically “enterprise grade” transactional and data intensive) from a “static” environment to the cloud is not a simple and trivial task. In fact, although I seldom hear this as a primary concern, I believe this is the most significant barrier of moving to the cloud.
The good thing is I also believe
XAP Cloud Application Server considerably reduce this risk and basically “cloud enable” and “future proof” your application. In other words, by running your application on GigaSpaces you are making sure to avoid these “hidden costs” and that your application will not break when you move it from the single developer machine to a cloud of hundreds of AMIs.
Development and “cloud lock-in”
I often hear the argument that cloud is not platform agnostic, forces you to use specific software stacks, etc… Well as I mention above, I believe cloud portability combined with a flexible/"open" development environment is the answer. There will not be one cloud for everyone (as we see de-facto today), so you have to “enable” your application to run on multiple clouds. In addition your developers will want to use their familiar IDEs, debugging and testing tools, or basically “develop on their desktops” and use the cloud as the deployment and runtime environment.
Gigaspaces
Cloud Framework approach is exactly that – develop on your desktop with Java/.NET or the scripting language of your choice and then deploy it to a cloud like EC2 with “one click”. The big advantage of using GigaSpaces in this context is twofold:
1. Due to the “Write once Scale anywhere” capability, you CAN develop and test on a single desktop and then seamlessly deploy to a large cloud
2. As your application logic bundled with the data it needs, it becomes an atomic unit running as a service on the GigaSpaces
java-based containers. This means you can move your application, almost seamlessly, between clouds.
Audit, logging and compliance
A concern I hear often, is “I have no idea where my data runs”, “How can I audit, track and isolate an issue with my application, it can run anywhere”. Specifically I heard this concern in the context of
Google App Engine and the
BigTable implementation.
As for GigaSpaces, the fact that your data is coupled with the logic in several
Processing Units that runs on specific nodes, plus the fact that you can easily decide how your data (and logic) are partitioned across the cluster, enables you to have a much higher control of the “application whereabouts” in the cloud.
Recently I did the
cloud framework demo to a Telco company. They were very concerned about knowing at any given moment where a specific application service is running, after seeing the demo they commented “all I have to do is watch the GigaSpaces UI and track a specific Processing Unit and I can know
instantly on which AMI it is running”.
Additional advantage of this approach, that may be helpful to our friends at
Singapore is that if something goes wrong in a specific service, the problem is “contained” to this specific node and its backup.
Another concern I encounter in this context is data segmentation, people wants to achieve a locking and SQL access isolation in a granularity of a specific row or a specific column in a table (you can think of it as a security concern as well). This can be somewhat complex to achieve with databases today in the cloud, however simplier to achieve with GigaSpaces. In the "space approach" everything is object-based - a "row" is an instance of an object, a "column" is a value of a specific attribute within this object. GigaSpaces enables roles and permissions hadnling in the granularity of an attribute within an object.
Performance “Penalty” and Scalability – will my application run faster and scale?
Obviously people are concern about what will be the performance implications of moving their applications to the cloud. From my experience this revolves mostly around latency and not limited to public clouds (i.e. the same concern applies to organization who are thinking about implementing clouds in their own data centers).
If you plan to run your business logic and data on different nodes, or logic outside the cloud and data inside, on top of the security issue you are in for an unpleasant surprise in terms of high latency. The appropriate solution is to run the data and logic together on the same cloud node. This is not trivial to achieve on your own, but literally out-of-the-box with Gigaspaces.
As for linear scalability or the “holy grail” of cloud computing, the answer can be quite complicated, as traditional tier-based middlware will not scale out-of-the-box. Fortunately, I truly believe that with GigaSpaces scalability CAN be made seamless. In my personal view, this one of the most compelling reasons to use GigaSpaces on the cloud. Or in other words, by using Gigaspaces on the cloud you can truly make the
“Cloud Computer” works 'as advertised' (credits to Kent from
Joyent of coining this term). Please read a nice
post by Nati Shalom in that regards
To conclude…
I personally think they are, big time! Not without serious concerns, but they are gradually moving in this direction, mainly due to the fundamental fact that it makes perfect economic sense.
I believe the biggest advantage about implementing your application on top of GigaSpaces is that it allows you to take “baby steps to the cloud” while significantly reducing the risk of joining this emerging, but challenging, technology.
Go out there and start clouding…
