Requirements for Applications to be "Cloud-Ready"
Greg Pfister
Sassa
can the provider guess. If the app does need to do that itself, the
provider doesn't have the responsibility for ensuring a SLA.
W.r.t. self-tuning instance pool size, tuning for response time goal
is very different from maximizing throughput. At the same time, the
real resource size and utilization are what drives performance
metrics, not virtual. Looking at virtual CPU of 86% and the virtual
number of cores available doesn't tell you the amount of headroom left
on one instance. So I wonder how that sizing is done in reality.
Sassa
Bernard Golden
are "equal," with no subnetting possible, so all servers reside, so to
speak, on the same network segment. Each server can only see traffic
directed toward it. Also, each server has a publicly accessible IP
address (i.e., can be accessed from outside AWS).
This simplified network topology can be handled differently with AWS
Virtual Private Cloud, which allows self-assignment of IP addresses
and can support subnetting. In addition, AWS instances can be set up
to operate without a public IP address.
Penelope Gordon
established connections (firewall friendly), and minimal dependencies
on particular MAC and/or IP Addresses. For example, endpoints
(clients) in a pre-Netcool IBM Tivoli Management Framework (TMF)
configuration could initiate a connection with the Tivoli server, but
the server had to make a new connection back to the endpoint rather
than using the established connection (unlike the Tivoli Storage
Manager server which used (and uses) the connection established by the
client). This meant that while TMF was great a managing fixed
endpoints within the local campus network, it couldn't effectively
manage mobile endpoints (not using a fixed VPN tunnel).
On Dec 16, 11:10 am, Greg Pfister <greg.pfis...@gmail.com> wrote:
Mohammad
communications and networking. Cloud infrastructures can give you
guarantees on CPU and memory usage, but they can never give you any
guarantees on network, at least for now, since it's shared between all
tenants. Networks are oversubscribed (take a look at this for eg
http://alan.blog-city.com/has_amazon_ec2_become_over_subscribed.htm).
A lot of routers or switches might have congestions at some point of
time. Failures and misconfigurations of network devices can happen
(remember Amazon outage in N Virginia?). A lot of research papers talk
about the lack of network and communication guarantees in public
clouds, and this pushed a lot of requirements for cloud applications
to have.
Gilad Parann-Nissany
- ability to bring things up (and down) in minutes - servers, disks, other resources
- everything is API driven - the UI is a convenience on top of the API but everything can be done by API
- low level approach - the IaaS model (the subject of that article) allows you to install many things that would run in your data center , equally in the cloud; this happens because you have access to the good old-fashioned OS including its management, command line, installations on your instances, creating images and using them, and so on
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://2010.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
or get it on DVD at
http://www.amazon.com/gp/product/B002H07SEC, http://www.amazon.com/gp/product/B004L1755W, http://www.amazon.com/gp/product/B002H0IW1U
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
Dave Corley
Dave Corley
Greg Pfister
Greg Pfister
Larry Cable
On Dec 16, 11:10 am, Greg Pfister <greg.pfis...@gmail.com> wrote:
> I recently read an article on AWS successhttp://goo.gl/FT0upthat
> contained a point that was minor (maybe) in the article, but struck me as
> interesting: To run on a cloud, applications have to be built to certain
> general requirements.
>
> The article lists three things (embedded in a para, not a list like I have
> here):
>
> 1. Simplified network model (I have no clue what this really means.
> Simplified compared with what?)
>
> 2. Application takes responsibility for fault tolerance (neither servers
> nor local storage is persistent)
>
> 3. Automated scaling and management (? built into the application?)
>
If you consider the entities that a virtualization layer within a
"typical" IaaS (such as AWS) has visibility into (and hence control
over)
those entities are:
- physical servers and & virtual machine images therein:
- their CPU utilization
- and their memory utilization
- any network I/O that occurs between VM images/ports
- any network storage resources used by the VM images
- and the network topology of the (distributed) application components
(at the VM image/port level)
in additional scenarios where perhaps either the "guest O.S" and/or
the "application" is now somewhat "virtualization aware" then the O.S
and/or
application(s) can expose further telemetry (and control) to the
underlying virtualization infrastructure, thus extending the list (and
providing more fine grained
access to) such resources.
These entities (above) are all relatively "coarse" grain, and while
they are (in)directly related to the behavior of the application(s)
hosted therein, they are sufficiently abstracted
from the actual application domain semantics & entities to make them
insufficient alone for fine grain collaboration (telemetry and
control) between the virtualization layers and applications therein.
What the virtualization layer has little or no visibility into, nor
control of, are these "application" (domain) semantics, arguably even
the hosting (guest) O.S has little visibility into
these (independent of the presence of virtualization)
Thus neither the virtualization layer nor the guest O.S have the
visibility into the necessary telemetry and control required to accept
responsibility for taking over the
functions of either fault tolerance or scalability (as examples of
other such qualities and/or capabilities) for the applications that
they typically host.
For example, a virtualization management framework would only be able
to monitor VM image level CPU or memory utilization, and network I/O
in order to provide some form of automatic
scaling of resources for a hosted application; this level of
instrumentation may be sufficient to automate the scaling of a simple
web presentation UI by implementing some form of course grain
SLA upon the latency of any given client HTTP request, this could also
perhaps be linked into some smart front end load balancer to
(re)distribute incoming requests across a pool of both physical
and virtual servers hosting those web containers (thus perhaps
implementing some utilization SLA), but it would much much harder for
such infrastructure to determine that the connection (pools)
from those containers to a backend data source such as an RDBMS were
becoming saturated, or that the pool of physical/virtual servers
hosting that RDBMS should be adjusted to meet additional request
loads because the semantics of the connections (to the database) and
the role of the database are not exposed to the infrastructure to
control.
Further; above the VIP and network routing layers, it would be
difficult to intelligently control pools of physical/virtual servers
since it is not possible to discern a fine grain component failure and
the compensating
action to take when such an event occurs (beyond spinning up another
VM instance and adding it to the resource and LB pool).
Hence the requirements for #2 and #3 upon the "application"; since it
is only at this level in the stack that has domain knowledge about the
application level components (O.S processes, components etc)
their roles, relationships, their particular resource requirements,
characteristics and qualities, etc.
Luckily, not all "applications" are required to address these complex
"system" level capabilities, we have a variety of "middleware"
components such as application servers, etc, that in addition to
providing an
Application Programming Model for developers to create their
applications with, but these middleware components typically also
encapsulate qualities such as scalability, fault tolerance,
manageability, telemetry
etc. So typically (again regardless of the presence of virtualization
or not) it is the responsibility of the middleware (containers) to
transparently automate the scaling and fault tolerance (amongst other)
capabilities
on behalf of the applications they host.
What appears to have been (and appears to continue to be) absent, is
an integration between middleware and the management infrastructure
found in the virtualization layers of a typical IaaS "platform" that
would
enable a more complete "feedback" loop between the middleware and
virtualization layers to occur. this integration would allow
middleware operating in the presence of an IaaS to collaborate with
the lifecycle management of the resources
that the virtualization layer controls to provide a more complete
autonomic solution for application scalability and fault tolerance.
hope this makes some sense
Geoff Brown
Larry Cable
existence of a (complex) guest O.S is essentially twofold:
1) because all (pre-existing) applications are typically written to a
particular O.S "flavor"
and...
2) the O.S provides a useful resource isolation boundary/container
(for the applications) & an entity for the virtualization framework to
manipulate
While it may appear (to the "traditional" O.S system admin) that the
presence of their favorite O.S will make the task of administering
their applications
in the cloud simpler, the lack of integration and/or collaboration
between the virtualization frameworks and the O.S'es results in a
complex (DIY) integration
that is required between the virtualization lifecycle management
frameworks and tools and their "peers" in the favorite (Guest)
O.Ses...
For some interesting examples of vitualization application runtimes
that obviate the need for a traditional O.S as guest/intermediate you
should take a look
at Weblogic Virtual Edition, which combined the WebLogic J EE
Application Server along with the JRockit JVM with "BareMetal" to
enable WebLogic and the
JVM to run directly on top of the hypervisor or native (HAT).
On Dec 19, 12:24 am, Gilad Parann-Nissany <gilad.par...@gmail.com>
wrote:
> Hi all
>
> I tend to feel some of these points describe a moment in time - today -
> rather than the ultimate cloud topology.
>
> Of the three points, I feel Automated Scaling and Management will be the
> one that survives.
>
> On the other hands, points I would add would include
>
> - ability to bring things up (and down) in minutes - servers, disks,
> other resources
> - everything is API driven - the UI is a convenience on top of the API
> but everything can be done by API
> - low level approach - the IaaS model (the subject of that article)
> allows you to install many things that would run in your data center ,
> equally in the cloud; this happens because you have access to the good
> old-fashioned OS including its management, command line, installations on
> your instances, creating images and using them, and so on
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissanyhttp://www.porticor.com/
> > Post Job/Resume athttp://cloudjobs.net
>
> > Download hundreds of recorded cloud sessions at
> > -http://cloudslam.org/register
> > -http://2010.up-con.com/register
> > -http://cloudslam09.com/content/registration-5.html
> > -http://cloudslam10.com/content/registration
Rao Dronamraju
Well, let me ask, shouldn’t the question be Requirements for Clouds to be Applications-Ready?
Considering that billions if not trillions of dollars worth of applications have been deployed in the data centers in the last 30 to 40 years across the world, isn’t it much more efficient both in economic/financial terms and from a technology perspective to architect and design clouds to fit to the deployed applications rather than re-architect the applications to fit to the clouds?
The point is at least in the initial stages (may be 3 to 5 years) of cloud adoption, migrating existing applications AS-IS is the best route. Considering the economic environment of last few years and the uncertainity in the near future, no CIO/CFO/CEO would like to re-architect/redesign applications just because clouds are on the horizon.
Of course, enhancing existing applications for new HW and SW product features like multi-core, web/cloud scale performance, big data etc will be on the on-going roadmaps of the companies and will automatically facilitate the application to be cloud ready.
my two fen!
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
Larry Cable
of APIs that cover (some) aspects of the provisioning and control
(scalability) of applications on an IaaS.
On Dec 19, 6:57 am, Dave Corley <dcorle...@gmail.com> wrote:
> Gilad, I like the simplicity of your description. Only thing I'd add is that the API you describe be standardized with provision for vendor/SP extensions.
>
> Dave Corley
>
> On Dec 19, 2011, at 2:24 AM, Gilad Parann-Nissany <gilad.par...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi all
>
> > I tend to feel some of these points describe a moment in time - today - rather than the ultimate cloud topology.
>
> > Of the three points, I feel Automated Scaling and Management will be the one that survives.
>
> > On the other hands, points I would add would include
> > ability to bring things up (and down) in minutes - servers, disks, other resources
> > everything is API driven - the UI is a convenience on top of the API but everything can be done by API
> > low level approach - the IaaS model (the subject of that article) allows you to install many things that would run in your data center , equally in the cloud; this happens because you have access to the good old-fashioned OS including its management, command line, installations on your instances, creating images and using them, and so on
> > Regards
> > Gilad
> > __________________
> > Gilad Parann-Nissany
> >http://www.porticor.com/
>
> > Post Job/Resume athttp://cloudjobs.net
>
> > Download hundreds of recorded cloud sessions at
> > -http://cloudslam.org/register
> > -http://2010.up-con.com/register
> > -http://cloudslam09.com/content/registration-5.html
> > -http://cloudslam10.com/content/registration
>
> > or get it on DVD at
>
> > ~~~~~
> > You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
> > To post to this group, send email to cloud-c...@googlegroups.com
> > To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
>
> > --
> > ~~~~~
> > Register to attend UP 2011 Cloud Conference
> >http://up-con.com/register-now
>
> > Posting guidelines:http://bit.ly/bL3u3v
> > Follow us on Twitter @cloudcomp_group @cloudslam @up_con
> > Post Job/Resume athttp://cloudjobs.net
>
> > Download hundreds of recorded cloud sessions at
> > -http://cloudslam.org/register
> > -http://2010.up-con.com/register
> > -http://cloudslam09.com/content/registration-5.html
> > -http://cloudslam10.com/content/registration
>
> > or get it on DVD at
Miha Ahronovitz
The answer is here.
http://www.embrane.com/solutions/overview
Quote:
If they go over the cloud, they essentially take some functionality and bolt it on over the cloud infrastructure they can offer (compute and storage). It is not built for the cloud or the CSP business model. All of the complexity falls in the lap of the service provider’s customer.
By leveraging... for the on-demand delivery of high-performance layer 4-7 network services, CSPs now have the much more effective and differentiated option – one that is optimized for the cloud.
Embrane virtual network services are designed to clearly provide the cloud functionality with all of the agility, dynamic provisioning, elasticity, scale-out performance, multi-tenancy and cost savings the cloud promises – something you can’t get anywhere else.
I am not endorsing any vendor, I just found this web site to be clear and this may mean, in turn, Embrane are guys and gals who know what they are doing
Miha
http://ahrono.com
Jim Starkey
Well, let me ask, shouldn’t the question be Requirements for Clouds to be Applications-Ready?
Considering that billions if not trillions of dollars worth of applications have been deployed in the data centers in the last 30 to 40 years across the world, isn’t it much more efficient both in economic/financial terms and from a technology perspective to architect and design clouds to fit to the deployed applications rather than re-architect the applications to fit to the clouds?
Punch cards were not a good foundation for time sharing. Time sharing was not a good model for departmental computing. Departmental computing was not a good foundation for client/server. And client/server was a really rotten model for cloud computing.
Different platforms have different requirements. And the computing capabilities of modern machines with tens of gigabytes of ram and many cores have nothing to do with machines of yester-decade.
People are expensive and applications are cheap. If contemporary capabilities enable superior applications, trash the old and build for the new. Promoting user productivity is the name of the game, not preserving ancient investments.
The challenges are building quality, scalable applications with a developer base of diminishing skills. Trying to maintain 35 year old applications is a formula for going out of business.
Geoff Brown
Gilad Parann-Nissany
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
Ian Mills
0755 394 6958
Service to the customer, the pursuit of excellence, respect for the individual.
Chris Haddad
found in the virtualization layers of a typical IaaS "platform" that
would enable a more complete "feedback" loop between the middleware and
virtualization layers to occur. this integration would allow
middleware operating in the presence of an IaaS to collaborate with
the lifecycle management of the resources
that the virtualization layer controls to provide a more complete
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://2010.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
or get it on DVD at
http://www.amazon.com/gp/product/B002H07SEC, http://www.amazon.com/gp/product/B004L1755W, http://www.amazon.com/gp/product/B002H0IW1U
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
Rao Dronamraju
I did not mean to say that the 30 to 40 year old applications needed to be migrated as is. There has been a lot of investment that happened in the last 10 to 15 years if not 30 years and it is not economically and financially prudent to re-architect widely deployed applications just because we have a new technology called cloud. Clouds need to meet the markets not the other way around, especially given the financial turmoil in the world and the investment moneys available for IT.
In fact that is the reason why the public cloud business has not picked up as much as it was expected ($100+ billion by some estimates). Most of the growth has been in the private clouds, which is nothing but virtualization of existing applications as is.
Amy Wohl
Facts: Private Clouds are not just virtualization, but rather the ability to use a resource on a “who needs it now” basis. There is elasticity in properly built private clouds just as there is in public clouds – how much is up to the customer. Private clouds may also be shared among a group of users (with the owner’s permission). These could be partners, customers, geographically disperse users, etc. There are a number of government sponsored private clouds that are actually community clouds (China, Vietnam).
Old apps may need to stay in their data centers, but they can still connect to cloud environments. Eventually, customers can decide if it pays to rewrite an old app into a cloud format – some will, some won’t.
Amy Wohl
Amy D. Wohl
Editor, Amy Wohl's Opinions
1954 Birchwood Park Drive North
Cherry Hill, NJ 08003
Follow my blog at http://www.amywohlsopinions.com
Oya SANLI
Oya Şanlı
@oyasan @RollOutCloud
about.me
Linkedin
Profile
Skype:oyasanli1959
Gtalk:59oyasanli
Rao Dronamraju
I have used the word virtualization loosely. How much elasticity are you going to get in a private cloud?, are you planning to have 50,000+ servers (as in Amazon) in a private clouds as in a public cloud?
miha ahronovitz
This network virtualization is the� new darling of Silicon Valley. It would be nice to have a conversation on private to understand. You are right, communicating to real people - not only the geeks -� and then present it with a Steve Jobs scenic style that people explode in ovations - is an art by itself.
Steve's passing away - it was staged as the last product this great man has launched: the book by Isaacson, the documentaries and every magazine shelf with his picture, all have been somehow orchestrated. Yet, I am deeply influenced by his legacy
We talk a lot about cloud, but see the iCloud on Apple site. Essentially, every idea brought on this forum has merits. But unless it explains itself with utmost simplicity, it will fizzle away.
2 cents,
Miha
On 12/19/2011 10:06 PM, Geoff Brown wrote:
Miha,
Point taken about investing more in marketing and the need for better communications :-)
Respectfully, In the experience of my company it is not really about if Network Virtualization is either "over" or "under" the cloud as this explanation misses the point. I personally believe the key point is which heterogeneous technology in the context of network connectivity services provides the highest levels of scalability, security and robustness in the most cost effective and simplest manner to support SLAs in, through or around Clouds - via Network Virtualization. �
Innovations in Security and Trusted Computing are more desirable attributes for Network Virtualization, without these Network Virtualization will never be embedded in Enterprise and Telco grade Infrastructures and thus trusted to deliver SLAs.
Just my .2 cents
Geoff BrownCEO & Founder
Machine-To-Machine Intelligence (M2Mi) CorporationNASA Research ParkBuilding 19, #2063Moffett Field, CA 94035
On Dec 19, 2011, at 7:14 PM, Miha Ahronovitz wrote:
Network virtualization is very well explained by Embrane, another startup besides NICIRA, that explains more clearly the concept. The questions is: Should the network services Layer 4-7 go over the cloud (which seems to be #1 as Geoff describes it)� or under the cloud ?
If they go over the cloud, they essentially take some functionality and bolt it on over the cloud infrastructure they can offer (compute and storage).� It is not built for the cloud or the CSP business model.� All of the complexity falls in the lap of the service provider�s customer.�
By leveraging... for the on-demand delivery of high-performance layer 4-7 network services, CSPs now have the much more effective and differentiated option � one that is optimized for the cloud.
Embrane virtual network services are designed to clearly provide the cloud functionality with all of the agility, dynamic provisioning, elasticity, scale-out performance, multi-tenancy and cost savings the cloud promises � something you can�t get anywhere else.
I am not endorsing any vendor, I just found this web site to be clear and this may mean, in turn,� Embrane are guys and gals who know what they are doing
Larry, thanks for clearly and detailed text.
Speaking from having a few years experience in this field, there are two different approaches to network virtualization �(1) Virtualizing at the NIC level, mainly to remove Top of Rack Switch limitations and (2) Secure Network Virtualization that includes Orchestration and Automation across VM's, Power Management, Load Balancers (virtual and physical), Firewalls, �Access & Distribution Switches ( telco and Enterprise networking ) in essence transaction integration of end-point devices. �In my own honest opinion (2) is much more desirable as it delivers end-to-end support for Service Level Agreements.�
Providers of Private, Public and Hybrid clouds use Secure Network Virtualization to deliver SLAs.
Larry your right, this form of middleware is positioned within IaaS.
Trust this helps.
Geoff BrownCEO & Founder
Machine-To-Machine Intelligence (M2Mi) CorporationNASA Research ParkBuilding 19, #2063Moffett Field, CA 94035
--------------------------------------------------------------------THIS MESSAGE contains information that is CONFIDENTIAL and legally exempt from disclosure and that is intended only for the addressee of this message.� If you are not the addressee or a person responsible for delivering this message to the addressee, then please do not deliver this message to anyone and delete all copies.� Thank you.
On Dec 19, 2011, at 12:24 AM, Gilad Parann-Nissany wrote:
Hi all
I tend to feel some of these points describe a moment in time - today - rather than the ultimate cloud topology.
Of the three points, I feel�Automated Scaling and Management will be the one that survives.
On the other hands, points I would add would include
- ability to bring things up (and down) in minutes - servers, disks, other resources
- everything is API driven - the UI is a convenience on top of the API but everything can be done by API
- low level approach - the IaaS model (the subject of that article) allows you to install many things that would run in your data center , equally in the cloud; this happens because you have access to the good old-fashioned OS including its management, command line, installations on your instances, creating images and using them, and so on
Regards
On Mon, Dec 19, 2011 at 05:44, Penelope Gordon <pego...@1plug.com> wrote:
#1 might refer to use of standard ports and protocols, use of
established connections (firewall friendly), and minimal dependencies
on particular MAC and/or IP Addresses. �For example, endpoints
(clients) in a pre-Netcool IBM Tivoli Management Framework (TMF)
configuration could initiate a connection with the Tivoli server, but
the server had to make a new connection back to the endpoint rather
than using the established connection (unlike the Tivoli Storage
Manager server which used (and uses) the connection established by the
client). �This meant that while TMF was great a managing fixed
�
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
�
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://2010.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
�
�
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
�
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
�
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://2010.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
�
�
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
�
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
�
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://2010.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
�
�
Larry Cable
by removing the guest O.S that would require
re-writing many applications and other components such as middleware
containers that are based upon O.S APIs. That is
simply untenable (the example of WebLogic VE was to simply highlight
that there are alternatives, when the application architype
permits, to hosting a full O.S stack to obtain resource isolation and
mgmt).
My point was to highlight the issues that must be dealt with when
using virtualization in combination with existing O.Ses.
Virtualization infrastructure deals with very course grained entities,
VM images, that is the granularity that virtualization
manages (without any modification of the existing O.Ses, middleware
and applications to provide more telemetry and control).
This is problematic across a number of dimensions; some already
discussed in this thread, e.g: scalability and fault tolerance,
however there are others...
for example, provisioning a VM image with a "complete" copy of a guest
O.S such as Linux or Windows, results in considerable
memory overhead at runtime (since each VM image must contain an in-
memory copy of the O.S ready-only/text)... this reduces
the efficacy of the solution since multiple VM images on the same
physical server "waste" these replicated copies...
many distros now provide minimal kernel profiles that should be used
in conjunction with virtualization that effectively reduces not
only the on-disk but per VM image memory utilization.
The complexity, or flexibility of, a modern O.S and the familiarity
with it by system administrators is also problematic when provisioning
and configuring.
Once you modify the runtime environment of a VM image using the OS
level tools you have lost the audit trail from the perspective of the
lifecycle management tools at the virtualization layer ... so the
cloud administrator must coordinate the provisioning and configuration
that
occurs at these two layers of the system.
lastly, form the perspective of the flexibility of the elasticity
provided by the cloud; it is constrained by the opacity of the guest
O.S as a resource
isolation boundary; if all you can control is a VM image containing a
guest O.s which then contains 1 or more homogeneous or heterogeneous
application
components, then the cloud elasticity is constrained at the VM image
level, further application scalability has to occur transparent to the
cloud (i.e within the
a particular guest O.S) thus managing scalability is again a hybrid
solution in the virtualization layer and the guest O.Ses ...
On Dec 19, 11:49 pm, Gilad Parann-Nissany <gilad.par...@gmail.com>
wrote:
> Interesting point.
>
> However since the original question was about what makes a cloud
> highly successful and useful, I do feel that maintaining the low level
> approach - offering traditional OS services - will meet the test of time.
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissanyhttp://www.porticor.com/
Ray
Agreed. Companies that have 40 year old apps are probably on the lagging edge of cloud adoption. Consider what platforms those 40 year old apps might be running on, 370 hardware? CDC?. Not moving to cloud anytime soon since they were fine skipping client server, mini computer, PC etc…
Amy Wohl
Not likely! But you can have as much room as you’re willing to pay for. With interoperability, of course you can move things between private and public clouds, selecting what you’re willing to send from home. And while Amazon may have 50,000 users you’re competing with them for space on a moment to moment basis – and no cloud, even a large public one, is infinite.
Amy
Dave Corley
Dave
Yiping Zhang
application means the app must be able to scale "horizontally".
If your apache server is running out of capacity, just add more web
servers. For a multi tiered application, each individual layer should
be scalable horizontally, be it the web server, middleware server or
database server. To automate the scaling up/down process, each layer
needs to be behind a load balancer AND the application has to use the
load metrics to automatically adjust number of servers at each layer
to achieve optimum resource allocation/usage.
Yiping
On Sat, Dec 17, 2011 at 2:33 PM, Sassa <sass...@gmail.com> wrote:
> I wonder more about #3. If the app doesn't need to do that itself, how
> can the provider guess. If the app does need to do that itself, the
> provider doesn't have the responsibility for ensuring a SLA.
>
Larry Cable
virtualization layers therein) you must package each component (web
server, rdbms etc) in its own VM image,
i.e each component must be a homogenous/singleton deployable unit
since the only unit of management/scalability is the VM image ...
another arguement for using a custom
guest O.S configuration in order to keep the (on disk and in memory)
size (and complexity) optimal.
Combining components/containers in the same VM image (i.e pairing a
web server and RDBMS) essentially makes these a unit of scaling
monolith that is not instrumentable nor controlable
by the IaaS fabric (as individual components)
Jim Starkey
In the database world, we see the greatest interest in public clouds in new starts. Enterprise customers are much more focused on private clouds. And, happily, those customers are a great deal more interested in technology developed explicitly for cloud computing than pre-cloud products re-branded for the cloud.
-- Jim Starkey Founder and CTO NuoDB, Inc.
Sassa
more capacity is helpful.
On a micro level, adding one thread too many can turn a spin lock into
a fat lock, and throughput drops from 70K to 9K (for some real
application I looked at).
Also, automatically tuning a system with just dozens of possible
combinations of configuration parameters (think of two resource pools,
each having 5 states) takes minutes, if you give each combination you
try a few seconds to reliably perceive whether the change is doing any
good. Finding the best configuration for a given load in a system with
hundreds of combinations is going to take hours, and that alone is not
adequate to meet requirements to adapt to changing load. What about
thousands of parameters (think of one resource being a thread pool)?
Self-tuning a large system means taking into account configuration of
all components, and their self-tuning behaviours.
In summary, what I am saying is that you can probably solve this
problem for trivial cases or for embarrassingly parallel applications.
A little bit less trivial - and the problem becomes hard to solve
exactly in a suitable time. I am not sure to what extent a coarse-
grained decision to scale-out can suit real applications.
Sassa
Rubert, James M
I think there are reasons why 40 year old apps still exist. Some type of Federal requirement and/or no business case to move it. CIO should not move to a technology because it is cool, neat, and it is written in all the tech rags. I think you will always have old apps. The cost to re-architect and rewrite is not cheap.
Jim
From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Ray
Sent: Tuesday, December 20, 2011 10:14 AM
To: cloud-c...@googlegroups.com
Rubert, James M
ROI… If the cloud does not provide a short term and possibly a long term business case it should not be leveraged. Currently, the liability of within the security of the service will dictate the consumption model before the business case does. Amazon has a massive user base but they refuse take any liability of security.
Pietrasanta, Mark
How is that really any different than any other external hosting facility? For non-SCIF stuff. (This is a genuine question.)
From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Rubert, James M
Sent: Wednesday, December 21, 2011 10:47 AM
To: cloud-c...@googlegroups.com
Yiping Zhang
On Wed, Dec 21, 2011 at 1:46 AM, Sassa <sass...@gmail.com> wrote:
>> If your apache server is running out of capacity, just add more web> servers.
>
> Yes, it is knowing that it is a. running out of capacity; b. adding
> more capacity is helpful.
>
That's where "cloud ready" comes in to play :)
Roughly speaking, there are two main reasons for deploying an
application into cloud:
1) purely cost savings on hardware, IT personal, and management overhead
2) technical advantages (and cost savings associated with these)
From 1)'s point of view, most of today's applications can be deployed
in a cloud directly or with little modifications. In this sense, they
are already "cloud ready".
But from 2)'s point of view, many of today's applications are NOT
"cloud ready", as they can not take advantage of one of most important
technical attribute of cloud, "on demand provisioning of resources,
scaling up and down as needed"
> On a micro level, adding one thread too many can turn a spin lock into
> a fat lock, and throughput drops from 70K to 9K (for some real
> application I looked at).
That's why your application has to be designed from beginning to be
able to deploy in a cluster that scales horizontally. There are many
more technical challenges to be solved before an application can be
deployed in such a fashion.
>
> Also, automatically tuning a system with just dozens of possible
> combinations of configuration parameters (think of two resource pools,
> each having 5 states) takes minutes, if you give each combination you
> try a few seconds to reliably perceive whether the change is doing any
> good. Finding the best configuration for a given load in a system with
> hundreds of combinations is going to take hours, and that alone is not
> adequate to meet requirements to adapt to changing load. What about
> thousands of parameters (think of one resource being a thread pool)?
>
> Self-tuning a large system means taking into account configuration of
> all components, and their self-tuning behaviours.
>
>
> In summary, what I am saying is that you can probably solve this
> problem for trivial cases or for embarrassingly parallel applications.
> A little bit less trivial - and the problem becomes hard to solve
> exactly in a suitable time. I am not sure to what extent a coarse-
> grained decision to scale-out can suit real applications.
>
>
Agreed, not all applications would benefit from scaling horizontally.
Huge web apps like Facebook, Twitter, Linkedin, Yahoo, Etrade, MSN
need this capability, your average enterprise ERP app or company
employee portal web site may not.
Yiping
> Sassa
>
> On Dec 20, 7:38 pm, Yiping Zhang <yiping4...@gmail.com> wrote:
>> From a (practical) deployment point of view, "auto scaling"
>> application means the app must be able to scale "horizontally".
>>
>> If your apache server is running out of capacity, just add more web
>> servers. For a multi tiered application, each individual layer should
>> be scalable horizontally, be it the web server, middleware server or
>> database server. To automate the scaling up/down process, each layer
>> needs to be behind a load balancer AND the application has to use the
>> load metrics to automatically adjust number of servers at each layer
>> to achieve optimum resource allocation/usage.
>>
>> Yiping
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Dec 17, 2011 at 2:33 PM, Sassa <sassa...@gmail.com> wrote:
>> > I wonder more about #3. If the app doesn't need to do that itself, how
>> > can the provider guess. If the app does need to do that itself, the
>> > provider doesn't have the responsibility for ensuring a SLA.
>
Miha Ahronovitz
Regarding (1), a cloud bills every user of services, including the internal users if the cloud is private . No one collects the actual money from internal users, but the CIO has a clear record of much they would have had paid if using a public external cloud. See the slides http://bit.ly/jhXx8r "Making the IT profitable". Cloud has direct revenues, a Datacenter doesn't.
Regarding (2) security, this something that applied to any Data Center, be it cloud or not cloud. Talking about Amazon, here is their Customer Service agreement
http://aws.amazon.com/agreement/
I have heard that AWS will customize it's policy for very large customers, but for additional fees which may be substantial Out of curiosity, I looked at the law regarding a hotel liability for its' guests
http://www.enotes.com/travel-reference/hotel-liability
Basically a hotel is not entirely responsible for all disasters may happen to a guest,and limit their liability. To reduce this liability, a traveler may purchase additional insurance, which may not be cheap.
Who ever again and and again brings the security question in discussions unrelated, just because the fear of clouds, especially public clouds, I have news; there is no absolute security in this world, by design. This Universe is not secure if we always find an uncovered risk (like the risk to be hit by meteorite while walking a dog :)
Back to the cloud business model, as James and many others said before, we must make money with it. If we don't, let's not call this a cloud. And if we make money, perhaps we can develop better money making services (i.e. apps) where each $1 invested in development pays off $10 in services. Our goal is NOT to reduce costs at any price. Our cloud goal is to make more money with better and better ROIs
Once we decide the cloud is feasible, we design the security around it and in addition, spread out the risks of disaster by using multiple IaaS Providers that companies like TAPP and Rightscale provide.
Cheers,
Miha
Rubert, James M
Interesting… The current state of the cloud industry is at the build it mode. When do you think the security will be built so that the cloud vendors will accept the security liability if the image gets hacked? As no public cloud offering has taken any liability except the small cloud vendors who really have nothing to lose. Security is huge and it should not be ignored. Any company that puts company sensitive, national sensitive data or digital assets in the public cloud are putting themselves and their company at risk.
BUT, I think all companies have public data and non company sensitive data or digital assets that can go into the public cloud. From my understanding that is what most large companies are putting in the cloud . This allows them to test and evaluate a cloud offering while not putting the company at risk.
Company owned data center cost verses IaaS cloud will be back to the business case and business opportunity. PaaS and paaS with SaaS provide business value but many of these solutions provide vendor lock. If a company chooses a cloud solutions one needs to add the service termination plan and cost estimates to migrate off the one service and move to another. Needless to say the cloud is maturing and will eventually get there. A company wanting to leverage the cloud has to strategize the business value, weigh that value against the risk of cloud computing to their company.
From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Miha Ahronovitz
Sent: Wednesday, December 21, 2011 9:24 AM
To: cloud-c...@googlegroups.com
Gilad Parann-Nissany
Sassa
scale out because app servers do. The example with scale up is just an
example: things don't scale in the same way. For ten instances of web
tier you need one instance of mem cache. Then comes that day of the
month when the objects cached are 3x larger, so the ratio changes.
Autotune scalability of that.
Provisioning is easy. It has been done for a decade in a different
field, which is taboo here. Elasticity and billing is at least clearly
defined, so can be and is solved. Greg's question about autotuning is
very interesting. But I think it is extremely difficult to do that
precisely and fast - just because auto-tuning heuristics must have a
very small number of guesses to test. Consequently, either the guesses
are very complex (no straightforward formula), or coarse-grained
(accuracy diminishes with the size of the system), or the system is
very simple (not many things to tune).
Sassa
> > Download hundreds of recorded cloud sessions at
> > -http://2010.up-con.com/register
> > -http://cloudslam09.com/content/registration-5.html
> > or get it on DVD at
Rao Dronamraju
The most widely migrated enterprise application to public clouds is CRM. CRM applications generally do not have major security and privacy issues like healthcare (HIPAA compliance), e-commerce (PCIDSS compliance) and other applications. Security and Privacy have been and are still the biggest roadblock to public cloud adoption right from the beginnings of cloud computing. Whether the security concerns are real or imaginary does not matter. If they are imaginary cloud service provider need to get the CIOs some psychiatric help. If they are real, they better come up with solutions. Because if they do not, they will not be getting the ROI on their investments in the public clouds. It could be too late.
On the same note, just curious if anyone knows how much of Amazon.com runs in AWS and MSN.com runs in Azure. If they run a large part of their own data centers in the their own clouds, especially critical applications from business functioning, security and privacy perspectives, they can show case it to the world as successes of public cloud computing. If they do not then the question would be, why are they not eating their own cookies?.
Also does anyone know, if a CRM written in Java EE/EJB, can be migrated to spring source/spring framework/POJO based PaaS without any major code-rewriting?
From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Rubert, James M
Sent: Wednesday, December 21, 2011 2:11 PM
To: cloud-c...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
or get it on DVD at
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to
Greg Pfister
A quote: "...the idea of launching an EC2 instance on a particular VPC subnet is effectively obsolete. A single EC2 instance can now be attached to two ENIs, each one on a distinct subnet. The ENI (not the instance) is now associated with a subnet."
iamondemand
Great discussion though it seems that its focus somehow lost. Anyway I
will add my 2 cents by saying that generating a cloud-ready
application from a legacy one includes a huge amount of investment -
that traditional enterprises tend not to be happy to do as from their
perspective it doesn't end with a great core capability value (why
does my on-premise app need to be based on the cloud ?..this huge
effort will not add value to my users and products in my industry
domain).
This evident fact lead to an evolution of new vendors > the SaaS
vendors. These new guys in the market slowly but surely take a great
market share from their traditional sisters. The new SaaS vendors find
it cheap and easy to develop their offering thanks to the cloud on all
its layers (SaaS, PaaS and IaaS) and capabilities (no touch delivery,
ease-of-use, fast innovation and deployment .. etc) and and IMHO in
the next 1-2 years we will see some of the huge enterprises vanish and
new vendors (salesforce is a great example for emerging "new" vendor
and SAP struggle to keep on going) that take their place.
Ofir.
@iamondemand
Frank Greco
In general... see "SOA". If you think that's an old term, see "Services Architecture". If you don't like that term, see "Common Sense". ;+
There are several tools to help migrate Java EE apps to a cloud PaaS. I would suggest looking at Java 7 (and following the movement of Java 8) where Oracle and the community are including cloud-friendly features.
Specifically for EJB... gees... EJB?? why did you do that?... ;+
Take a look at CloudBees: http://wiki.cloudbees.com/bin/view/RUN/JavaEE
Frank G
Frank Greco
"embarrassingly parallel" is a grid requirement, not necessarily a cloud requirement.
"actor model interactions" is a model du jour. We've learned that trends disappear as fast as they arrive.
"REST"... now that WebSocket is an official specification, why would you use REST and twist the semantics of a service just to satisfy HTTP?
Frank G.
On 12/20/11 11:10 AM, Chris Haddad wrote:
Larry pointed out an excellent infrastructure requirement:
"What appears to have been (and appears to continue to be) absent, isan integration between middleware and the management infrastructure
found in the virtualization layers of a typical IaaS "platform" that
would enable a more complete "feedback" loop between the middleware and
virtualization layers to occur. this integration would allow
middleware operating in the presence of an IaaS to collaborate with
the lifecycle management of the resources
that the virtualization layer controls to provide a more complete
autonomic solution for application scalability and fault tolerance."
At the application architecture layer,
While IaaS can PaaS can wrap applications and increase cloud characteristics (i.e. rapid elasticity, scalable resource pooling, measured service, and on-demand self servic), a team's ability to realize benefits are limited by application architecture. When application are considered 'just workloads', infrastructure cannot properly optimize performance and scale. Traditional web application architecture introduces single points of failure, resource contention points, tight coupling, and single threaded reqeust-response models, which limits cloud characteristics.
Cloud architecture is required. For example, applications conforming to eventual consistency, embarrassingly parallel operations, actor model interactions, and REST.
/ChrisVP of Technology Evangelism, WSO2
On Mon, Dec 19, 2011 at 5:08 PM, Larry Cable <larry...@yahoo.com> wrote:
I'd like to take a stab at commenting on #2 & #3...
On Dec 16, 11:10 am, Greg Pfister <greg.pfis...@gmail.com> wrote:
> I recently read an article on AWS successhttp://goo.gl/FT0upthat
> contained a point that was minor (maybe) in the article, but struck me as
> interesting: To run on a cloud, applications have to be built to certain
> general requirements.
>
> The article lists three things (embedded in a para, not a list like I have
> here):
>
> 1. Simplified network model (I have no clue what this really means.
> Simplified compared with what?)
>
> 2. Application takes responsibility for fault tolerance (neither servers
> nor local storage is persistent)
>
> 3. Automated scaling and management (? built into the application?)
>
If you consider the entities that a virtualization layer within a
"typical" IaaS (such as AWS) has visibility into (and hence control
over)
those entities are:
- physical servers and & virtual machine images therein:
- their CPU utilization
- and their memory utilization
- any network I/O that occurs between VM images/ports
- any network storage resources used by the VM images
- and the network topology of the (distributed) application components
(at the VM image/port level)
in additional scenarios where perhaps either the "guest O.S" and/or
the "application" is now somewhat "virtualization aware" then the O.S
and/or
application(s) can expose further telemetry (and control) to the
underlying virtualization infrastructure, thus extending the list (and
providing more fine grained
access to) such resources.
These entities (above) are all relatively "coarse" grain, and while
they are (in)directly related to the behavior of the application(s)
hosted therein, they are sufficiently abstracted
from the actual application domain semantics & entities to make them
insufficient alone for fine grain collaboration (telemetry and
control) between the virtualization layers and applications therein.
What the virtualization layer has little or no visibility into, nor
control of, are these "application" (domain) semantics, arguably even
the hosting (guest) O.S has little visibility into
these (independent of the presence of virtualization)
Thus neither the virtualization layer nor the guest O.S have the
visibility into the necessary telemetry and control required to accept
responsibility for taking over the
functions of either fault tolerance or scalability (as examples of
other such qualities and/or capabilities) for the applications that
they typically host.
For example, a virtualization management framework would only be able
to monitor VM image level CPU or memory utilization, and network I/O
in order to provide some form of automatic
scaling of resources for a hosted application; this level of
instrumentation may be sufficient to automate the scaling of a simple
web presentation UI by implementing some form of course grain
SLA upon the latency of any given client HTTP request, this could also
perhaps be linked into some smart front end load balancer to
(re)distribute incoming requests across a pool of both physical
and virtual servers hosting those web containers (thus perhaps
implementing some utilization SLA), but it would much much harder for
such infrastructure to determine that the connection (pools)
from those containers to a backend data source such as an RDBMS were
becoming saturated, or that the pool of physical/virtual servers
hosting that RDBMS should be adjusted to meet additional request
loads because the semantics of the connections (to the database) and
the role of the database are not exposed to the infrastructure to
control.
Further; above the VIP and network routing layers, it would be
difficult to intelligently control pools of physical/virtual servers
since it is not possible to discern a fine grain component failure and
the compensating
action to take when such an event occurs (beyond spinning up another
VM instance and adding it to the resource and LB pool).
Hence the requirements for #2 and #3 upon the "application"; since it
is only at this level in the stack that has domain knowledge about the
application level components (O.S processes, components etc)
their roles, relationships, their particular resource requirements,
characteristics and qualities, etc.
Luckily, not all "applications" are required to address these complex
"system" level capabilities, we have a variety of "middleware"
components such as application servers, etc, that in addition to
providing an
Application Programming Model for developers to create their
applications with, but these middleware components typically also
encapsulate qualities such as scalability, fault tolerance,
manageability, telemetry
etc. So typically (again regardless of the presence of virtualization
or not) it is the responsibility of the middleware (containers) to
transparently automate the scaling and fault tolerance (amongst other)
capabilities
on behalf of the applications they host.
What appears to have been (and appears to continue to be) absent, is
an integration between middleware and the management infrastructure
found in the virtualization layers of a typical IaaS "platform" that
would
enable a more complete "feedback" loop between the middleware and
virtualization layers to occur. this integration would allow
middleware operating in the presence of an IaaS to collaborate with
the lifecycle management of the resources
that the virtualization layer controls to provide a more complete
autonomic solution for application scalability and fault tolerance.
hope this makes some sense
--
~~~~~
Register to attend UP 2011 Cloud Conference
http://up-con.com/register-now
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://2010.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
or get it on DVD at
http://www.amazon.com/gp/product/B002H07SEC, http://www.amazon.com/gp/product/B004L1755W, http://www.amazon.com/gp/product/B002H0IW1U
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com
Larry Cable
of the emerging tools etc (e.g cloudfoundry, GAE eclipse plugin, AWS
eclipse plugin) hide much of the
mechanism of various cloud platforms from developers, so its
relatively easy (perhaps with the exception of debugging) to become
productive quickly.
+1 on the model du-jour ... for example, anyone that programmed X
Windows would easily recognize node.js as a re-invention of the window
system event dispatch loop ...
As I understand it, WebSocket is essentially a "standard" javascript
API to an underlying TCP/IP socket (on the client/browser-side) so
it appears to me to be a cleaner way of implementing AJAX/COMET style
connections (in a browser portable fashion) (without tunnelling over
HTTP) so from that perspective
it is probably "more suitable" than REST (for such persistent style
connections), however...
HTTP does actually add some value (in a standard fashion) that
(appears to be) missing from WebSocket, that is the protocol requests
themselves (GET, PUT, POST, DELETE, ...),
content (type) negotiation, (header) metadata etc... WebSocket
developers will have to invent their own higher level protocols to
fill this gap ... after all how many "classical" client/server
style applications used "raw" sockets without some higher level
protocols - not many as I recall?
> > <mailto:larry.ca...@yahoo.com>> wrote:
>
> > I'd like to take a stab at commenting on #2 & #3...
>
> > On Dec 16, 11:10 am, Greg Pfister <greg.pfis...@gmail.com
> > Download hundreds of recorded cloud sessions at
> > -http://2010.up-con.com/register
> > -http://cloudslam09.com/content/registration-5.html
> > or get it on DVD at
> > http://www.amazon.com/gp/product/B002H07SEC,
> > http://www.amazon.com/gp/product/B004L1755W,
> > http://www.amazon.com/gp/product/B002H0IW1U
>
> > ~~~~~
> > You received this message because you are subscribed to the Google
> > Groups "Cloud Computing" group.
> > To post to this group, send email to
> > cloud-c...@googlegroups.com
> > <mailto:cloud-computi...@googlegroups.com>
>
> > --
> > +1.678.431.1656
> > mailto:ch...@wso2.com <mailto:ch...@wso2.com>
> > twitter @cobiacomm
> >http://blog.cobia.net/cobiacomm(blog)
>
> > ~~~~~
> > Register to attend UP 2011 Cloud Conference
> >http://up-con.com/register-now
>
> > Posting guidelines:http://bit.ly/bL3u3v
> > Follow us on Twitter @cloudcomp_group @cloudslam @up_con
> > Post Job/Resume
>
>
> read more »
SamJoyce
On Friday, December 16, 2011 7:10:17 PM UTC, Greg Pfister wrote:
I recently read an article on AWS success http://goo.gl/FT0up that contained a point that was minor (maybe) in the article, but struck me as interesting: To run on a cloud, applications have to be built to certain general requirements.
The article lists three things (embedded in a para, not a list like I have here):1. Simplified network model (I have no clue what this really means. Simplified compared with what?)2. Application takes responsibility for fault tolerance (neither servers nor local storage is persistent)3. Automated scaling and management (? built into the application?)
While this sounds reasonable, I wonder: Are they the only requirements, or are there more? Anybody care to flesh out what they mean in practice? Are they all correct? What does #1 mean, anyway? Why is #2 just servers & storage - what about communications?Anybody care to comment?Greg Pfister
On Friday, December 16, 2011 7:10:17 PM UTC, Greg Pfister wrote:
I recently read an article on AWS success http://goo.gl/FT0up that contained a point that was minor (maybe) in the article, but struck me as interesting: To run on a cloud, applications have to be built to certain general requirements.
The article lists three things (embedded in a para, not a list like I have here):1. Simplified network model (I have no clue what this really means. Simplified compared with what?)2. Application takes responsibility for fault tolerance (neither servers nor local storage is persistent)3. Automated scaling and management (? built into the application?)