Here are some high level use cases to get us discussing the boundaries of libcloud. There are some things in here which may or may not be part of libcloud, and the anbiguity should be good to help drive the boundaries.
Actor:
Jerome the Application Deployer: Owns an applications, responsible for the SLA of the application
Use Case: Enroll with the Cloud ------------------------------- Jerome chooses to use CloudCo as his cloud provider. Jerome enrolls with CloudCo providing them his credentials and his billing information. Jerome is provided with an additional set of credentials which he must use when authenticating with CloudCo.
Use Case: Test Application ---------------------------- Jerome bundles an application with Fedora to create his test image. He loads the image into the cloud. His application is database intensive, so he launches the image and associates a data disk to the instance where DB files are to be located. He sets an FQDN for the instance, and uses this FQDN to do testing. Jerome finds an issue with the image, so he updates the image in the cloud as well as his internal gold copy. Once testing is complete, Jerome generates a new gold image and reloads a second version of the image. He then performs another round of testing. Once satisfied, Jerome leaves the instance running for 1 week for his users to sanity test the application.
Use Case: Simple Deployment -------------------- Jerome is satisfied with the gold copy of the instance. Jerome clones the image to create a new image for production, and assigns a new FQDN. Jerome associates new storage with the production image for the production database. Jerome configures automated backup of the database, and sets up monitoring to inform him when the image stops working.
Note: Not dealing with multi-tier applications with firewalls or clustering.
Use Case: Reporting ----------------------- Jerome is required to maintain a 3 nines uptime. On the first of each month, Jerome queries for the uptime of the image in order to generate his statistics. Jerome also queries disk, bandwidth, and memory usage in order to generate his chargeback reports.
Use Case: Decommissioning ------------------------ CloudCo has only allowed Jerome to achieve a 95% uptime for 3 months. Jerome decides to go with iCloud instead of CloudCo. Jerome has enrolled with iCloud,and exports his image and data files from CloudCo and loads them into iCloud.
Other Ideas Not covered here ---------------------------- - granting access to images. - firewalls, LANS, - clustering - Recovery
-- bk
I'll add mine, involving multiple tiers and publishers/consumers. This is the model we've been working with in JBoss-Cloud, for the most part.
Use Case: Integrator publishes a multi-tier application portfolio of images for use by others (SaaS) -------------------------------- Ivan the Integrator has bundled an application on top of Fedora, along with another image of a DB on top of Fedora. He expects them to be used in tandem. After enrolling in the cloud, he registers them with the cloud library. He adjusts permissions so that everyone can use these images.
Use Case: Consumer uses a pre-published set of images (SaaS) -------------------------------- Clyde the Consumer sees the set of images provided by Ivan, and desires to use them. He launches an instance of the DB image and an instance of the application image. They don't work without some configuration, informing the application image about the location of the DB image (IP, FQDN, whatever). Clyde does 1 of: 1) manually SSH's to the application image and configures it to find the DB, 2) launches DB first, and passes that IP to the application when launching it second
Use Case: Integration publishes a multi-tier platform portfolio of images for use by others (PaaS) -------------------------------- Ivan the Integrator has bundled an application *platform* on top of Fedora (ie, JBossAS), along with other images such as the DB-on-Fedora noted above. After registering with the cloud image library, he adjust permissions to make them visible to everyone.
Use Case: Consumer uses a pre-published set of platform images to build further upon (PaaS -> SaaS) --------------------------------- Clyde the Consumer finds a pre-published *platform* so he can deploy his WAR-based application upon it. He launches an instance of the application platform image and the DB image. He deploys his WAR to the application platform, adjust datasources within his application to work with the DB. A lot more initial manual configuration is required. Once satisfied with the cooperation between his app, the platform image, and the DB image, he re-bundles the whole set in a derivative image portfolio. He constrains access control to prevent others from using his modified versions (creative commons be damned!). Clyde has become an in-house integrator similar to Ivan case #1 now.
Use Case: Consumer wants to dynamically apply security updates to his derivative images ------------------------------- Clyde's rebundled application images based upon Ivan's published platform images get tagged for security updates. While Ivan has rebuilt newer platform images to include the latest security updates, Clyde does not want to have to rebuild and redeploy his images. Instead, he uses onboard facilities (yum, JON, etc) to push/pull updates to the running systems. Since new instances of his now out-of- date images may be brought up at any time, Clyde ensures that these updates occur for every image at boot time, automatically. Once enough updates are required to be annoying at each boot, he can rebundle an up-to-date (for now) version to use for future deployments. Basically, he makes a snapshot, and replaces the older images with the newer ones for use moving forward.
Use Case: Integrator sells access to his images through cloud providers who offer cost-based images. --------------------------------- Ivan decides he doesn't like free. So he assigns a cost-per-hour to the use of his images (and derivatives of his images). The provider handles all billing, and sends him a fat check each month representing 60% of the cost billed to the end-user. The provider keeps 40% for their troubles.
Use Case: Integrator sells access to his images through cloud providers who do not offer cost-based images ---------------------------------- Ivan decides to support other cloud providers who do not have a native reseller cost-based image offering. Ivan publishes his images with this provider, and locks them down tight. After executing a paper contract with Clyde the Consumer, he manually adjusts permissions on the image to add Clyde to the access list.
Use Case: Integrator publishes his images on multiple cloud providers -------------------------------- Ivan the Integrator, successful with selling a JBoss stack on EC2, decides to enlarge his market by supporting other public cloud providers. He defines the images abstractly (perhaps via kickstarts or something even more abstract). He feeds them to $something, which ingests the abstract definition, churns, and registers concrete images with every cloud provider he's enrolled with.
Use Case: Integrator publishes and sells access to his images on multiple cloud providers -------------------------------- As above, integrator's abstract definitions are ingested, and concrete images are registered everywhere that Ivan has enrolled. For providers supporting reseller cost-based images, the cost model is applied. For providers not supporting such, permissions are adjusted to limit access until paper contracts are faxed around.
-Bob
On Jul 8, 2009, at 10:56 AM, Bryan Kearney wrote:
Here are some high level use cases to get us discussing the boundaries of libcloud. There are some things in here which may or may not be part of libcloud, and the anbiguity should be good to help drive the boundaries.
Actor:
Jerome the Application Deployer: Owns an applications, responsible for the SLA of the application
Use Case: Enroll with the Cloud
Jerome chooses to use CloudCo as his cloud provider. Jerome enrolls with CloudCo providing them his credentials and his billing information. Jerome is provided with an additional set of credentials which he must use when authenticating with CloudCo.
Use Case: Test Application
Jerome bundles an application with Fedora to create his test image. He loads the image into the cloud. His application is database intensive, so he launches the image and associates a data disk to the instance where DB files are to be located. He sets an FQDN for the instance, and uses this FQDN to do testing. Jerome finds an issue with the image, so he updates the image in the cloud as well as his internal gold copy. Once testing is complete, Jerome generates a new gold image and reloads a second version of the image. He then performs another round of testing. Once satisfied, Jerome leaves the instance running for 1 week for his users to sanity test the application.
Use Case: Simple Deployment
Jerome is satisfied with the gold copy of the instance. Jerome clones the image to create a new image for production, and assigns a new FQDN. Jerome associates new storage with the production image for the production database. Jerome configures automated backup of the database, and sets up monitoring to inform him when the image stops working.
Note: Not dealing with multi-tier applications with firewalls or clustering.
Use Case: Reporting
Jerome is required to maintain a 3 nines uptime. On the first of each month, Jerome queries for the uptime of the image in order to generate his statistics. Jerome also queries disk, bandwidth, and memory usage in order to generate his chargeback reports.
Use Case: Decommissioning
CloudCo has only allowed Jerome to achieve a 95% uptime for 3 months. Jerome decides to go with iCloud instead of CloudCo. Jerome has enrolled with iCloud,and exports his image and data files from CloudCo and loads them into iCloud.
Other Ideas Not covered here
- granting access to images.
- firewalls, LANS,
- clustering
- Recovery
-- bk
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
Crikey... does this mean I have to change my actor to Albert the Application Owner??
-- bk
Bob McWhirter wrote:
I'll add mine, involving multiple tiers and publishers/consumers. This is the model we've been working with in JBoss-Cloud, for the most part.
Use Case: Integrator publishes a multi-tier application portfolio of images for use by others (SaaS)
Ivan the Integrator has bundled an application on top of Fedora, along with another image of a DB on top of Fedora. He expects them to be used in tandem. After enrolling in the cloud, he registers them with the cloud library. He adjusts permissions so that everyone can use these images.
Use Case: Consumer uses a pre-published set of images (SaaS)
Clyde the Consumer sees the set of images provided by Ivan, and desires to use them. He launches an instance of the DB image and an instance of the application image. They don't work without some configuration, informing the application image about the location of the DB image (IP, FQDN, whatever). Clyde does 1 of: 1) manually SSH's to the application image and configures it to find the DB, 2) launches DB first, and passes that IP to the application when launching it second
Use Case: Integration publishes a multi-tier platform portfolio of images for use by others (PaaS)
Ivan the Integrator has bundled an application *platform* on top of Fedora (ie, JBossAS), along with other images such as the DB-on-Fedora noted above. After registering with the cloud image library, he adjust permissions to make them visible to everyone.
Use Case: Consumer uses a pre-published set of platform images to build further upon (PaaS -> SaaS)
Clyde the Consumer finds a pre-published *platform* so he can deploy his WAR-based application upon it. He launches an instance of the application platform image and the DB image. He deploys his WAR to the application platform, adjust datasources within his application to work with the DB. A lot more initial manual configuration is required. Once satisfied with the cooperation between his app, the platform image, and the DB image, he re-bundles the whole set in a derivative image portfolio. He constrains access control to prevent others from using his modified versions (creative commons be damned!). Clyde has become an in-house integrator similar to Ivan case #1 now.
Use Case: Consumer wants to dynamically apply security updates to his derivative images
Clyde's rebundled application images based upon Ivan's published platform images get tagged for security updates. While Ivan has rebuilt newer platform images to include the latest security updates, Clyde does not want to have to rebuild and redeploy his images. Instead, he uses onboard facilities (yum, JON, etc) to push/pull updates to the running systems. Since new instances of his now out-of-date images may be brought up at any time, Clyde ensures that these updates occur for every image at boot time, automatically. Once enough updates are required to be annoying at each boot, he can rebundle an up-to-date (for now) version to use for future deployments. Basically, he makes a snapshot, and replaces the older images with the newer ones for use moving forward.
Use Case: Integrator sells access to his images through cloud providers who offer cost-based images.
Ivan decides he doesn't like free. So he assigns a cost-per-hour to the use of his images (and derivatives of his images). The provider handles all billing, and sends him a fat check each month representing 60% of the cost billed to the end-user. The provider keeps 40% for their troubles.
Use Case: Integrator sells access to his images through cloud providers who do not offer cost-based images
Ivan decides to support other cloud providers who do not have a native reseller cost-based image offering. Ivan publishes his images with this provider, and locks them down tight. After executing a paper contract with Clyde the Consumer, he manually adjusts permissions on the image to add Clyde to the access list.
Use Case: Integrator publishes his images on multiple cloud providers
Ivan the Integrator, successful with selling a JBoss stack on EC2, decides to enlarge his market by supporting other public cloud providers. He defines the images abstractly (perhaps via kickstarts or something even more abstract). He feeds them to $something, which ingests the abstract definition, churns, and registers concrete images with every cloud provider he's enrolled with.
Use Case: Integrator publishes and sells access to his images on multiple cloud providers
As above, integrator's abstract definitions are ingested, and concrete images are registered everywhere that Ivan has enrolled. For providers supporting reseller cost-based images, the cost model is applied. For providers not supporting such, permissions are adjusted to limit access until paper contracts are faxed around.
-BobOn Jul 8, 2009, at 10:56 AM, Bryan Kearney wrote:
Here are some high level use cases to get us discussing the boundaries of libcloud. There are some things in here which may or may not be part of libcloud, and the anbiguity should be good to help drive the boundaries.
Actor:
Jerome the Application Deployer: Owns an applications, responsible for the SLA of the application
Use Case: Enroll with the Cloud
Jerome chooses to use CloudCo as his cloud provider. Jerome enrolls with CloudCo providing them his credentials and his billing information. Jerome is provided with an additional set of credentials which he must use when authenticating with CloudCo.
Use Case: Test Application
Jerome bundles an application with Fedora to create his test image. He loads the image into the cloud. His application is database intensive, so he launches the image and associates a data disk to the instance where DB files are to be located. He sets an FQDN for the instance, and uses this FQDN to do testing. Jerome finds an issue with the image, so he updates the image in the cloud as well as his internal gold copy. Once testing is complete, Jerome generates a new gold image and reloads a second version of the image. He then performs another round of testing. Once satisfied, Jerome leaves the instance running for 1 week for his users to sanity test the application.
Use Case: Simple Deployment
Jerome is satisfied with the gold copy of the instance. Jerome clones the image to create a new image for production, and assigns a new FQDN. Jerome associates new storage with the production image for the production database. Jerome configures automated backup of the database, and sets up monitoring to inform him when the image stops working.
Note: Not dealing with multi-tier applications with firewalls or clustering.
Use Case: Reporting
Jerome is required to maintain a 3 nines uptime. On the first of each month, Jerome queries for the uptime of the image in order to generate his statistics. Jerome also queries disk, bandwidth, and memory usage in order to generate his chargeback reports.
Use Case: Decommissioning
CloudCo has only allowed Jerome to achieve a 95% uptime for 3 months. Jerome decides to go with iCloud instead of CloudCo. Jerome has enrolled with iCloud,and exports his image and data files from CloudCo and loads them into iCloud.
Other Ideas Not covered here
- granting access to images.
- firewalls, LANS,
- clustering
- Recovery
-- bk
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
Bob McWhirter wrote:
I'll add mine, involving multiple tiers and publishers/consumers. This is the model we've been working with in JBoss-Cloud, for the most part.
Use Case: Integrator publishes a multi-tier application portfolio of images for use by others (SaaS)
Ivan the Integrator has bundled an application on top of Fedora, along with another image of a DB on top of Fedora. He expects them to be used in tandem. After enrolling in the cloud, he registers them with the cloud library. He adjusts permissions so that everyone can use these images.
For me to know, you expect the cloud to keep a record of the relationship?
Use Case: Consumer uses a pre-published set of images (SaaS)
Clyde the Consumer sees the set of images provided by Ivan, and desires to use them. He launches an instance of the DB image and an instance of the application image. They don't work without some configuration, informing the application image about the location of the DB image (IP, FQDN, whatever). Clyde does 1 of: 1) manually SSH's to the application image and configures it to find the DB, 2) launches DB first, and passes that IP to the application when launching it second
Use Case: Integration publishes a multi-tier platform portfolio of images for use by others (PaaS)
Ivan the Integrator has bundled an application *platform* on top of Fedora (ie, JBossAS), along with other images such as the DB-on-Fedora noted above. After registering with the cloud image library, he adjust permissions to make them visible to everyone.
Not having looked at PaaS too much. THis seems to be a model of multi tenancy as many single tenant platform instances. Is that how Google Apps and others approach the issue? Or, do they support multi-tenant containers?
Use Case: Consumer uses a pre-published set of platform images to build further upon (PaaS -> SaaS)
Clyde the Consumer finds a pre-published *platform* so he can deploy his WAR-based application upon it. He launches an instance of the application platform image and the DB image. He deploys his WAR to the application platform, adjust datasources within his application to work with the DB. A lot more initial manual configuration is required. Once satisfied with the cooperation between his app, the platform image, and the DB image, he re-bundles the whole set in a derivative image portfolio. He constrains access control to prevent others from using his modified versions (creative commons be damned!). Clyde has become an in-house integrator similar to Ivan case #1 now.
Use Case: Consumer wants to dynamically apply security updates to his derivative images
Clyde's rebundled application images based upon Ivan's published platform images get tagged for security updates. While Ivan has rebuilt newer platform images to include the latest security updates, Clyde does not want to have to rebuild and redeploy his images. Instead, he uses onboard facilities (yum, JON, etc) to push/pull updates to the running systems. Since new instances of his now out-of-date images may be brought up at any time, Clyde ensures that these updates occur for every image at boot time, automatically. Once enough updates are required to be annoying at each boot, he can rebundle an up-to-date (for now) version to use for future deployments. Basically, he makes a snapshot, and replaces the older images with the newer ones for use moving forward.
Rebundling here seems very EC2/Stateless oriented. Is that the model we want to address?
Use Case: Integrator sells access to his images through cloud providers who offer cost-based images.
Ivan decides he doesn't like free. So he assigns a cost-per-hour to the use of his images (and derivatives of his images). The provider handles all billing, and sends him a fat check each month representing 60% of the cost billed to the end-user. The provider keeps 40% for their troubles.
Use Case: Integrator sells access to his images through cloud providers who do not offer cost-based images
Ivan decides to support other cloud providers who do not have a native reseller cost-based image offering. Ivan publishes his images with this provider, and locks them down tight. After executing a paper contract with Clyde the Consumer, he manually adjusts permissions on the image to add Clyde to the access list.
Use Case: Integrator publishes his images on multiple cloud providers
Ivan the Integrator, successful with selling a JBoss stack on EC2, decides to enlarge his market by supporting other public cloud providers. He defines the images abstractly (perhaps via kickstarts or something even more abstract). He feeds them to $something, which ingests the abstract definition, churns, and registers concrete images with every cloud provider he's enrolled with.
Use Case: Integrator publishes and sells access to his images on multiple cloud providers
As above, integrator's abstract definitions are ingested, and concrete images are registered everywhere that Ivan has enrolled. For providers supporting reseller cost-based images, the cost model is applied. For providers not supporting such, permissions are adjusted to limit access until paper contracts are faxed around.
-BobOn Jul 8, 2009, at 10:56 AM, Bryan Kearney wrote:
Here are some high level use cases to get us discussing the boundaries of libcloud. There are some things in here which may or may not be part of libcloud, and the anbiguity should be good to help drive the boundaries.
Actor:
Jerome the Application Deployer: Owns an applications, responsible for the SLA of the application
Use Case: Enroll with the Cloud
Jerome chooses to use CloudCo as his cloud provider. Jerome enrolls with CloudCo providing them his credentials and his billing information. Jerome is provided with an additional set of credentials which he must use when authenticating with CloudCo.
Use Case: Test Application
Jerome bundles an application with Fedora to create his test image. He loads the image into the cloud. His application is database intensive, so he launches the image and associates a data disk to the instance where DB files are to be located. He sets an FQDN for the instance, and uses this FQDN to do testing. Jerome finds an issue with the image, so he updates the image in the cloud as well as his internal gold copy. Once testing is complete, Jerome generates a new gold image and reloads a second version of the image. He then performs another round of testing. Once satisfied, Jerome leaves the instance running for 1 week for his users to sanity test the application.
Use Case: Simple Deployment
Jerome is satisfied with the gold copy of the instance. Jerome clones the image to create a new image for production, and assigns a new FQDN. Jerome associates new storage with the production image for the production database. Jerome configures automated backup of the database, and sets up monitoring to inform him when the image stops working.
Note: Not dealing with multi-tier applications with firewalls or clustering.
Use Case: Reporting
Jerome is required to maintain a 3 nines uptime. On the first of each month, Jerome queries for the uptime of the image in order to generate his statistics. Jerome also queries disk, bandwidth, and memory usage in order to generate his chargeback reports.
Use Case: Decommissioning
CloudCo has only allowed Jerome to achieve a 95% uptime for 3 months. Jerome decides to go with iCloud instead of CloudCo. Jerome has enrolled with iCloud,and exports his image and data files from CloudCo and loads them into iCloud.
Other Ideas Not covered here
- granting access to images.
- firewalls, LANS,
- clustering
- Recovery
-- bk
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
For me to know, you expect the cloud to keep a record of the relationship?
It would be great if so, but so far in experience, that's really out- of-band information kept in HTML/PDF somewhere.
Not having looked at PaaS too much. THis seems to be a model of multi tenancy as many single tenant platform instances. Is that how Google Apps and others approach the issue? Or, do they support multi- tenant containers?
I think true PaaS is like Google AppEngine, Facebook Apps, where it's a singular instance of "the platform", and you write a small chunk for your portion of it.
I'm calling JBossAS a PaaS, also, though. Even though it's an application, it's fairly useless as-is. When the chunk you've written in a .war/.ear, you just want a j2ee platform to deploy it upon. That could be any one-of-many. So, trying to make it easy to launch a JEE platform, based upon JBoss of course.
Rebundling here seems very EC2/Stateless oriented. Is that the model we want to address?
If I'm building a derivative work from some previously published thing, I want to be able to snapshot my combined resulting product. Imaging taking the RHT CSB, adding a few apps for your department/ group, and then republishing that for use by new hires. That's the sort of additive use-case I'm aiming for. Trying to minimize the steps (manual or otherwise) from 0-to-Go. "Boot up CSB+ThincrustDev image" is easier than "boot up CSB, install these X packages, configure per instructions.html".
Though, could be a bad use-case. Just throwing it out there.
-Bob
deltacloud-devel@lists.fedorahosted.org
-
Bob McWhirter -
Bryan Kearney