Appistry Bridging Application Clouds
Reuven Cohen
computing. Appistry an early pioneer in enterprise cloud computing,
today announced a new product that gives companies the power to
migrate their heterogeneous applications to cloud-based environments.
Called Appistry CloudIQ Manager & Engine they describe the product as
a single point of application level management utilizing public and
private clouds. From what I can tell, it looks very promising.
Before I go any further, in full disclosure, Sam Charrington (VP
Product Management and Marketing at Appistry) is one of the
co-creators of Cloud Camp as well as a key backer of both the Cloud
Computing Interoperability Forum (CCIF) and Unified Cloud Interface
Project (UCI). I know Charrington well and Interoperability is a big
area of interest for him both personally and professionally.
Regardless of our previous work, this is a very interesting
announcement and marks one of the first true hybrid cloud products on
the market today.
In my conversation with Charrington this morning he said that "one of
the problems we see at the infrastructure level is folks being forced
to deploy and manage things at the granularity of the virtual
machine--we think that that is a cumbersome approach and want people
to be able to package, deploy and manage applications independent of
the VMs themselves"
I couldn't agree more, the benefit for legacy applications is a VM
acts as a legacy container, something that bridges the old with then
new. But in the very near future, the line between application and OS
will quickly become blurred. The flavor of OS will no longer be a
chief requirement, but rather the flavor cloud provider (internal or
external, open or closed) will become the new OS of choice. Appistry's
approach is targeting this new reality. A seamless global application
platform or to put it another way, you can think of it like a hybrid
"google app engine" for the enterprise.
What I like about this approach is their infrastructure & application
agnostic, although still focused largely on enterprise private clouds
they've realized the opportunity in providing tools to bridge public
and hybrid clouds in a secure and efficient way. More simply, they've
built a platform geared toward extensibility for existing application
stacks, while enabling these existing applications to be packaged and
deployed to a cloud without modification, simplifying migration and
application portability. A tangible example for the hybrid cloud
model.
Another interesting aspect is in their approach to application
portability across a wide variety of private and public cloud
environments, allowing enterprises to choose the right cloud for the
right job at the right time. According to Charrington they will
support Amazon, GoGrid and Skytap in the initial release due out this
spring.
The folk at Appistry have heard me rant about this a few times, but I
will mention it again. Appistry is a closed source product but they
are taking steps to become an "open" and "interoperable" platform. To
put it another way, you aren’t locked into a particular cloud
provider’s infrastructure, but you're still somewhat locked into
Appistry's. In response to my lock-in concerns, Charrington had this
to say "With CloudIQ Manager we are packaging and managing the
lifecycle of existing applications -- you are telling us how to manage
your apps and bundling them up and we take it from there. There are
absolutely no dependencies on us. CloudIQ Engine, that's an
application framework for people building apps for extreme scale. We
try to minimize lock-in by supporting existing Java and .NET
components, but there is a little."
In the conversation, Charrington goes on to describe an open
application packaging format for apps deployed to their engine called
a FAR (fabric archive). Basically it's just a zip with your app code,
files, media, etc and some XML they call a Service Definition
Template. You can think of a FAR as a kind of OVF (Open Virtualization
Format) for application centric cloud environments. Given the
simplicity of the FAR spec, my recommendation is the they open up the
FAR format under an open source license such as BSD.
What is exciting about this news is the work we've been doing with
Appistry on the Unified Cloud Interface project. Their platform uses a
set of open and extensible APIs, allowing enterprises to integrate
CloudIQ Manager with existing management tools such as the Enomaly ECP
platform, VMware and others to create what they describe as
next-generation "cloud management mashups." More specifically CloudIQ
will be among the first platforms to support the UCI (Unified Cloud
Interface) specification from a platform-as-a-service point of view.
Together this will allow users to universally bridge application
workloads among a world wide cloud of compute providers. (Keep posted
for more "UCI" news in the near future) Combining UCI and FAR would
make for a killer "open cloud" application stack!
--
--
Reuven Cohen
CCIF Instigator
JM
Sam, how do you provide minimize lock in for .NET and Java. Did you
rewrite a virtual machine to run bytecode for Java and .NET?
"CloudIQ Engine, that's an application framework for people building
apps for extreme scale. We try to minimize lock-in by supporting
existing Java and .NET components, but there is a little."
Sam Charrington
One way to think of CloudIQ Engine is that Engine is like a container for components (as opposed to CloudIQ Manager which is like a container for applications).
CloudIQ Engine embeds the standard, off-the-shelf Java Virtual Machine and .NET CLR and orchestrates requests to components distributed out across the underlying fabric. We've worked hard to minimize lock-in and in the case of Java and .NET in many cases you don't need to update your code to run it in Engine.
Engine is able to take advantage of JVM/CLR features to introspect your existing components and manage their lifecycle without you needing to insert custom code. That said, we provide APIs that you can take advantage of for things like data caching and affinity and using those APIs ties you a bit more closely to the framework.
Sam
Sam Charrington
As a company we've worked very hard over the past several years to open up our platform and minimize customer lock-in. In many ways the introduction of CloudIQ Manager today is the culmination of that effort in that it allows us to manage applications that aren't tied to the Engine framework.
Openness and interoperability are important elements of our business strategy since we offer an infrastructure-agnostic platform and aim to unify the private clouds that our customers are deploying with the public clouds that our partners own and operate.
We certainly can, and will, take it further and I really like your idea of opening up the FAR/Service Definition specification. Stay tuned!
I also really like the "OVF for applications" analogy. That's great.
Sam
tluk...@exnihilum.com
TL
-----Original Message-----
From: "Sam Charrington" [s...@charrington.com]
Date: 03/09/2009 09:20 PM
To: cloud...@googlegroups.com
Subject: Re: Appistry Bridging Application Clouds
Jason,
One way to think of CloudIQ Engine is that Engine is like a container for components (as opposed to CloudIQ Manager which is like a container for applications).
Engine is able to take advantage of JVM/CLR features to introspect your existing components and manage their lifecycle without you needing to insert custom code. That said, we provide APIs that you can take advantage of for things like data caching and affinity and using those APIs ties you a bit more closely to the framework.
On Mon, Mar 9, 2009 at 3:06 PM, JM <jason....@gmail.com> wrote:
good stuff.
Sam, how do you provide minimize lock in for .NET and Java. Did you
rewrite a virtual machine to run bytecode for Java and .NET?
> acts as a legacy container, something that bridges the old with then
> new. But in the very near future, the line between application and OS
> will quickly become blurred. The flavor of OS will no longer be a
> chief requirement, but rather the flavor cloud provider (internal or
> approach is targeting this new reality. A seamless global application
> platform or to put it another way, you can think of it like a hybrid
> "google app engine" for the enterprise.
>
> What I like about this approach is their infrastructure & application
> agnostic, although still focused largely on enterprise private clouds
> and hybrid clouds in a secure and efficient way. More simply, theyve
> built a platform geared toward extensibility for existing application
> stacks, while enabling these existing applications to be packaged and
> deployed to a cloud without modification, simplifying migration and
> application portability. A tangible example for the hybrid cloud
> model.
>
> Another interesting aspect is in their approach to application
> portability across a wide variety of private and public cloud
> environments, allowing enterprises to choose the right cloud for the
> right job at the right time. According to Charrington they will
> support Amazon, GoGrid and Skytap in the initial release due out this
> spring.
>
> The folk at Appistry have heard me rant about this a few times, but I
> will mention it again. Appistry is a closed source product but they
> are taking steps to become an "open" and "interoperable" platform. To
> put it another way, you aren’t locked into a particular cloud
> Appistrys. In response to my lock-in concerns, Charrington had this
> to say "With CloudIQ Manager we are packaging and managing the
> lifecycle of existing applications -- you are telling us how to manage
> your apps and bundling them up and we take it from there. There are
> application framework for people building apps for extreme scale. We
> try to minimize lock-in by supporting existing Java and .NET
> components, but there is a little."
>
> In the conversation, Charrington goes on to describe an open
> application packaging format for apps deployed to their engine called
> files, media, etc and some XML they call a Service Definition
> Template. You can think of a FAR as a kind of OVF (Open Virtualization
> Format) for application centric cloud environments. Given the
> simplicity of the FAR spec, my recommendation is the they open up the
> FAR format under an open source license such as BSD.
>
Reuven Cohen
Sam, please feel free to share any details of the FAR specification
with the group. I'd be interested as well in seeing any API
documentation you may have available.
It also occurred to me after I wrote the post, that your approach is
kind of like a jeOS image, (Just Enough OS) but instead for
applications, jeAPP, (Just Enough App), -- random thought.
As a side note, I'm curious how CloudIQ might work with 10Gen's
mongodb or Apache Hadoop? Both seem like a nice fit, specially as FAR
appliances.
Keep up the good work!
Ruv