dido:public:ra:1.4_req:2_nonfunc:08_elasticity
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:08_elasticity [2020/11/20 21:24] nick |
dido:public:ra:1.4_req:2_nonfunc:08_elasticity [2021/07/26 12:40] (current) murphy [About] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4.2.7 Elasticity ====== | + | ====== 4.3.9 Elasticity ====== |
| [[dido:public:ra:1.4_req:2_nonfunc| Return to Non-Functional Requirements]] | [[dido:public:ra:1.4_req:2_nonfunc| Return to Non-Functional Requirements]] | ||
| - | |||
| - | * **<color #FF0000><todo @char>Please Review</todo></color>** | ||
| ===== About ===== | ===== About ===== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc:05_elasticity | Return to Top]] | + | [[dido:public:ra:xapend:xapend.a_glossary:c:cloudelasticity]] also known as Elasticity "is the degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible."(( |
| - | + | ||
| - | [[dido:public:ra:xapend:xapend.a_glossary:c:cloudelasticity]] also known just Elasticity "is the degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available re-sources match the current demand as closely as possible."(( | + | |
| Nikolas Roman Herbst, Samuel Kounev and Ralf Reussner, | Nikolas Roman Herbst, Samuel Kounev and Ralf Reussner, | ||
| __Elasticity in Cloud Computing: What It Is, and What It Is Not__, | __Elasticity in Cloud Computing: What It Is, and What It Is Not__, | ||
| Line 20: | Line 17: | ||
| )). | )). | ||
| - | * **Cost-aware criteria** the default is to assume that there is a firm fixed price for IaaS providers, however, some providers allow for spot pricing schemes (i.e., Amazon) which can allow users to tap into IaaS excess capacity. This excess capacity is there so that the IaaS provider can meet the Service Level Agreements (SLAs) guaranteed to all customers. | + | The following are the various strategies used to achieve elasticity: |
| - | * **Power-aware cost function**. There are also benefits be reaped when using the off-peak power consumption only use the power required to meet the application's needs and little more. | + | * **Cost-aware criteria**: The default is to assume that there is a firm fixed price for IaaS providers, however, some providers allow for spot pricing schemes (i.e., Amazon) which can allow users to tap into IaaS excess capacity. This excess capacity is there so that the IaaS provider can meet the Service Level Agreements (SLAs) guaranteed to all customers. |
| - | * **Multiple classes of requests**. This allows an applications to be segmented into categories based on the need for service. For example, customers requests for service from the application cn be divided into three categories: High Priority for performing financial transactions; Medium Priority for those making product enquirers; Low priority for this browsing. | + | * **Power-aware cost function**: Using the power required to meet the [[dido:public:ra:xapend:xapend.a_glossary:a:application|application's]] needs and little more, i.e., using off-peak power consumption only. |
| - | * **Other types of applications** | + | * **Multiple classes of requests**: Allow applications to be segmented into categories based on the need for service. For example, customers' requests for service from the application can be divided into three categories: High Priority for performing financial transactions; Medium Priority for those making product inquiries; Low priority for simple browsing. |
| - | * **Scaling multiple applications**. This allows for an application to be broken up into smaller applications whose functionality and services are orchestrated. | + | * **Scaling multiple applications**: Allow an application to be broken up into smaller applications whose functionality and services are orchestrated. |
| - | + | ||
| - | + | ||
| - | ===== DDS Specifics ===== | + | ===== DIDO Specifics ===== |
| - | [[dido:public:ra:1.4_req:2_nonfunc:05_elasticity | Return to Top]] | + | [[dido:public:ra:1.4_req:2_nonfunc:08_elasticity| Return to Top]] |
| - | [[dido:public:ra:xapend:xapend.a_glossary:d:dds]] is generally implemented as a [[dido:public:ra:xapend:xapend.a_glossary:p:p2p]] and uses the [[dido:public:ra:xapend:xapend.a_glossary:p:publish-subscribe]] model rather than the [[dido:public:ra:xapend:xapend.a_glossary:c:client-server]] model. Therefore, there is little need for elasticity is unless the [[ddsf:private:cookbook:06_append:02_quality_of_service:durability]] is used and then only the [[dido:public:ra:xapend:xapend.a_glossary:d:ddsnode]] responsible for keeping the messages needs to worry about Elasticity. | + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> |
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.4_req/2_nonfunc/08_elasticity.1605925480.txt.gz · Last modified: 2020/11/20 21:24 by nick
