On 03/10/2014 02:58 PM, Jay Pipes wrote:
On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:
While I understand the general argument about pets versus cattle. The
question is, would you be willing to poke a few holes in the strict
"cattle" abstraction for the sake of pragmatism. Few shops are going
to make the direct transition in one move. Poking a hole in the cattle
abstraction allowing them to keep a pet VM might be very valuable to
some shops making a migration.

Poking holes in cattle aside, my experience with shops that prefer the
pets approach is that they are either:

  * Not managing their servers themselves at all and just relying on some
IT operations organization to manage everything for them, including all
aspects of backing up their data as well as failing over and balancing
servers, or,
  * Hiding behind rationales of "needing to be secure" or "needing 100%
uptime" or "needing no customer disruption" in order to avoid any change
to the status quo. This is because the incentives inside legacy IT
application development and IT operations groups are typically towards
not rocking the boat in order to satisfy unrealistic expectations and
outdated interface agreements that are forced upon them by management
chains that haven't crawled out of the waterfall project management funk
of the 1980s.

Adding pet-based features to Nova would, IMO, just perpetuate the above
scenarios and incentives.

What about the cases where it's not a "preference" but rather just the inertia of pre-existing systems and procedures?

If we can get them in the door with enough support for legacy stuff, then they might be easier to convince to do things the "cloud" way in the future.

If we stick with the hard-line cattle-only approach we run the risk of alienating them completely since redoing everything at once is generally not feasible.

Chris





_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to