Elasticidade (computação em nuvem)

A elasticidade na computação em nuvem é a capacidade dessa nuvem de se adaptar às necessidades do aplicativo o mais rápido possível. Existem várias definições segundo os autores, algumas considerando as noções de Escalabilidade e elasticidade como idênticas, outras como distintas. A chegada de tais sistemas distribuídos (veja Computação Distribuída ) inevitavelmente envolve problemas técnicos que devem ser regulamentados ou limitados. Economicamente, a chegada da elasticidade teve um impacto sobre os clientes e provedores de nuvem. Por exemplo, os fornecedores criaram um sistema de pagamento “  pré-pago  ” para pagar pelos recursos usados ​​sob demanda. Assim, um cliente pode alugar um servidor por um curto período de tempo e no tamanho desejado.

Muitos provedores como Amazon Web Services , Microsoft Azure ou mesmo Google App Engine criaram servidores em nuvem sob demanda. Mas cada provedor de nuvem tem suas especificidades em termos de velocidade, elasticidade, latência, etc.

Definições

Noções

É comum pensar em elasticidade e escalabilidade como sinônimos. A elasticidade na nuvem pode ser comparada à propriedade física da elasticidade de um material, que é sua capacidade de retornar à sua forma original após a deformação que sofreu. Assim, a elasticidade pode ser calculada como a relação entre a pressão que a nuvem pode sofrer e a pressão que ela sofre.

No entanto, outros como NR Herbst e Doaa M. Shawky fazem duas definições muito distintas:

Escalabilidade Escalabilidade é a capacidade de um sistema de atender aos requisitos de recursos, sem levar em conta a velocidade, o tempo, a frequência ou a granularidade de suas ações. Elasticidade Elasticidade é o grau em que um sistema é capaz de se adaptar às demandas provisionando e desprovisionando recursos automaticamente, de forma que os recursos fornecidos correspondam à demanda do sistema.

A escalabilidade é, portanto, um pré-requisito para a elasticidade. O tempo é um elo importante entre elasticidade e escalabilidade: quanto menos tempo o sistema leva para se adaptar, mais elástico ele é.

Todo o ponto de elasticidade na nuvem é responder o mais precisamente possível à demanda de recursos de um aplicativo. Para isso, os sistemas são capazes de se adaptar em poucos minutos.

Recursos

Existem duas abordagens para a elasticidade. O primeiro é chamado de elasticidade horizontal. Essa forma de elasticidade é obtida adicionando ou removendo máquinas virtuais da instância do cliente. A segunda abordagem, chamada vertical, não é mais realizada adicionando servidores, mas adicionando recursos à máquina, como RAM , CPU , etc.

Como regra geral, a elasticidade horizontal tem um custo de tempo maior do que a elasticidade vertical porque você tem que esperar a máquina virtual ser criada e inicializada. Assim, para melhor desempenho, será utilizada a elasticidade vertical. O problema é que esse tipo de abordagem é muito mais limitado do que a escalabilidade horizontal. Na verdade, a escalabilidade vertical não pode se estender por recursos fora da máquina física. Assim, é necessário definir claramente em qual máquina a máquina virtual será iniciada no início, a fim de poder escalar verticalmente o maior tempo possível.

Em seu artigo, Chien-Yu Liu define um algoritmo que, segundo ele, é o mais eficiente, combinando a escalabilidade quase infinita da elasticidade horizontal e a velocidade da elasticidade vertical: Aumentar os recursos da máquina virtual, quando a máquina virtual não por mais tempo, é necessário criar novos na mesma nuvem (elasticidade horizontal). Se uma única nuvem não pode atender às demandas de recursos, máquinas virtuais de outras nuvens devem ser adicionadas (elasticidade horizontal). Quando a nuvem não atende mais às demandas, você precisa seguir para o próximo aplicativo.

Métricas

NR Herbst, em seu artigo, nos apresenta uma maneira de calcular a elasticidade de cima para baixo e de baixo para cima, mas também a precisão de um sistema de nuvem superprovisionado e subprovisionado. Assim, a elasticidade para cima (respectivamente para baixo) é inversamente proporcional ao tempo médio gasto por um sistema subfornecido (respectivamente superfornecido) em um estado ótimo (respectivamente ) pela média da quantidade acumulada de recursos subfornecidos (respectivamente excesso de oferta) durante o período de teste (respectivamente ):

A precisão crescente (respectivamente decrescente) é a razão entre a quantidade acumulada dos recursos subprovisionados (respectivamente superprovisionados) (respectivamente ) e o período de teste :

Problemas e limitações

Problemas

A flexibilidade dos sistemas em nuvem cria alguns desafios para os fornecedores. A primeira é que existem várias configurações básicas, geralmente é muito difícil saber qual escolher. O objetivo é ter a melhor configuração e, ao mesmo tempo, ser o mais barato. Depois que essa etapa for concluída, o aplicativo terá solicitações mais ou menos importantes para o tempo. Como e quando provisionar / desprovisionar o sistema? Nesta etapa, o objetivo é minimizar os custos de infraestrutura (euros) e de transição (tempo).

Um dos maiores desafios na nuvem é solucionar erros em sistemas distribuídos muito grandes. Por se tratar de problemas relacionados a sistemas muito grandes, é impossível resolvê-los em sistemas menores, por isso os testes são feitos diretamente nos ambientes de produção. Usar máquinas virtuais pode ser uma solução. Na verdade, é possível capturar informações valiosas em uma VM , onde não é possível em máquinas físicas. Infelizmente, todos os fornecedores desenvolveram suas ofertas sem usar uma VM, seja porque começaram antes da era da virtualização ou porque sentiram que não podiam pagar.

Outro desafio é gerenciar a flexibilidade de armazenamento. Muitas tentativas foram feitas para responder a essa pergunta, variando na riqueza de solicitações e APIs de armazenamento, as garantias de desempenho oferecidas. A ideia é não apenas atender às expectativas dos programadores no que diz respeito à durabilidade, alta disponibilidade e capacidade de gerenciar e consultar dados, mantendo as vantagens da flexibilidade da nuvem.

Também existem desafios que ligam a elasticidade e a ecologia das nuvens . Na verdade, é importante que os aplicativos hospedados na nuvem liberem recursos não utilizados tanto quanto possível. Em primeiro lugar, porque um computador em standby consome "apenas" dois terços dos seus recursos, o que poupa muita energia, e em segundo lugar porque isso implica um impacto mais positivo no ambiente, embora o setor seja muito pobre. Visto pela opinião pública. Para isso, os provedores criaram o sistema de cobrança refinado ( pré-pago ) para incentivar os usuários a liberar recursos o mais rápido possível.

As licenças de software também são um problema. Na verdade, alguns fornecedores de software ainda não têm ofertas para a nuvem, o que implica custos astronômicos de licença de software. Para resolver esse problema, o código aberto é uma solução muito popular. Felizmente, alguns fornecedores como a Amazon ou a Microsoft estão começando a fazer ofertas de licenciamento de software “  pague conforme o uso  ”. Embora as instâncias sejam executadas em uma estrutura de software paga, continua sendo uma alternativa muito interessante para soluções de código aberto (respectivamente $ 0,15  / h contra $ 0,10  / h).

Como a elasticidade torna possível adquirir ou liberar dinamicamente recursos de computação em resposta à demanda, é importante ter monitoramento e controle dos mesmos. Os dados a serem monitorados são classificados em três dimensões: custo, qualidade e recursos. O framework como MELA para monitorar e analisar a elasticidade dos serviços em nuvem . Para o controle deste, ferramentas como SYSBL (Simple Yet Beautiful Language), permitem ter um controle em três níveis: ao nível da aplicação, ao nível do componente e ao nível da programação, e também de atender aos requisitos de elasticidade.

Outro problema a ser considerado é o tempo de inicialização das máquinas virtuais. Na verdade, eles devem estar disponíveis a tempo e prontos para serem usados ​​pelos usuários. Esse tempo de inicialização pode levar em consideração diversos fatores: hora do dia, tamanho da imagem do sistema operacional, tipo de instância, localização dos centros de dados e número de instâncias solicitadas ao mesmo tempo.

Limites

Cada sistema tem seus limites. No caso da nuvem , um dos primeiros identificáveis ​​de sua elasticidade é a quantidade de recursos disponíveis, outros limites foram encontrados.

De acordo com os testes de Doaa M. Shawky, quanto mais máquinas você aloca por vez, menos elástico é o sistema. De fato, durante um experimento, ele comparou dois sistemas com os mesmos valores de estresse, um aumentando o número de máquinas por pacote em 10, o segundo em lotes em 20. Descobriu-se que o tempo médio d A extensão dos dois experimentos é 4427,2 segundos e 6334,4 segundos, respectivamente. Ao mesmo tempo, a elasticidade média foi de 0,0036 e 0,0028, respectivamente. No caso em que a elasticidade do sistema é feita horizontalmente, a elasticidade também diminui à medida que aumenta o número de máquinas alocadas. Isso ocorre porque o tempo de extensão aumenta. Esse limite é ainda mais verdadeiro para a elasticidade horizontal porque é necessário aguardar a inicialização e o início de cada máquina virtual para instanciar.

Economia

Devido à elasticidade da nuvem , os sistemas fornecedores têm uma taxa de utilização de seus sistemas entre 5% e 20%. Como resultado, sempre há recursos disponíveis caso uma forte demanda por recursos chegue de um ou mais clientes.

Fornecedores

Os fornecedores se permitem variar seus preços por meio de variações nos custos de nuvem : estes incluem a aquisição e manutenção de hardware, como processadores, memória, disco rígido e rede. O tamanho da memória, o tamanho do espaço em disco utilizado e o custo de transmissão de dados também são levados em consideração na locação pelo cliente.

O Amazon EC2 oferece dois modelos de negócios para seus clientes:

  1. o primeiro, denominado “Instâncias sob demanda”, é o modelo econômico mais comum, “  uso sob demanda  ”. Ao escolher esta oferta, os clientes não têm compromisso e têm liberdade para planear.
  2. a segunda é chamada de instâncias pontuais . Esta opção permite que a Amazon jogue com os preços de acordo com o uso de sua nuvem. Quanto menos for usado, mais baixos serão os preços, mas o inverso também é verdadeiro.

Graças à oferta de instâncias pontuais , a Amazon incentiva seus clientes a usar sua nuvem durante os períodos fora de pico, eventualmente a empresa deseja nivelar a curva de uso de sua nuvem, o que reduzirá os custos de manutenção.

Clientes

Cloud-server.png

O uso da nuvem pode, devido à sua elasticidade, trazer várias vantagens para o cliente:

Por exemplo, uma start-up que precisasse fazer grandes cálculos pagaria o mesmo preço para usar 1000 máquinas Amazon EC2 por uma hora que 1 máquina por 1000h.

Da mesma forma, no caso de um uso que varia muito ao longo do tempo, é interessante usar a nuvem. Graças à elasticidade da oferta “pré-pago” que muitos fornecedores oferecem, o cliente paga apenas pelo que usa. Por exemplo, no caso de um cliente que usa 500 servidores durante os horários de pico, mas apenas 100 durante os períodos de pico, com uma média de 300 servidores durante o dia. Sem a nuvem, o cliente teria que ter 500 servidores, ou 500 x 24 = 12.000 servidores por hora. Graças à nuvem e sua elasticidade, ele usa apenas 300 x 24 = 7.200 horas de servidor.

Mas esta análise não leva em conta o fato de que a nuvem permite uma adaptação rápida a uma demanda por um recurso incomum, por exemplo, sites de vendas online em dezembro. O impacto aqui é mínimo, ao passo que se o próprio cliente hospedasse seu site, o pedido e a instalação de novos servidores poderia levar várias semanas, sem mencionar o fato de que, depois que os feriados passaram, seus servidores não teriam 'teria sido mais útil .

Comparação de fornecedores

Em 2010, foi feita uma comparação entre os provedores de nuvem pública: Amazon AWS, Azure, AppEngine e CloudServers. Esses provedores foram avaliados em torno de 4 critérios: elasticidade do cluster , armazenamento persistente, rede intra-nuvem e grandes redes.

Por motivos legais, a identidade dos provedores de nuvem pública é anônima nos resultados e é designada de C1 a C4.

Comparação de custos Amazon EC2, nuvem privada
Tamanho do servidor configuração Custo / h custo / núcleo
Amazon EC2
pequeno 1 ECU, 1,7 GB de RAM, 160 GB de espaço em disco $ 0,085  $ 0,085 
alta 4 ECU, 7,4 GB de RAM, 850 GB de espaço em disco $ 0,34  $ 0,085 
médio - rápido 5 ECU, 1,7 GB de RAM, 350 GB de espaço em disco $ 0,17  $ 0,034 
XL 8 ECU, 15 GB de RAM, 1,7 TB de espaço em disco $ 0,68  $ 0,085 
XL- rápido 20 ECU, 7 GB de RAM, 1,7 TB de espaço em disco $ 0,68  $ 0,034 
Nuvem privada
pequeno 1 núcleo, 2,8  GHz , 1 GB de RAM, 36 GB de espaço em disco $ 0,11  $ 0,11 
caminho 2 núcleos, 3,2  GHz , 2 GB de RAM, 146 GB de espaço em disco $ 0,17  $ 0,085 
alta 4 núcleos, 2  GHz , 4 GB de RAM, 250 GB de espaço em disco $ 0,25  $ 0,063 
Rápido 4 núcleos, 3  GHz , 4 GB de RAM, 600 GB de espaço em disco $ 0,53  $ 0,133 
XL 8 núcleos, 2 GHz, 8 GB de RAM, 1 TB de espaço em disco $ 0,60  $ 0,075 
Informações sobre instâncias de nuvem testadas
Fornecedor Tipo de instância Número de núcleos Preço
C1 C1.1 1 $ 0,085  / h
C1.2 2 $ 0,34  / h
C1.3 4 0,68  $ / h
C2 C2.1 4 $ 0,015  / h
C2.2 4 $ 0,03  / h
C2.3 4 $ 0,06  / h
C2.4 4 $ 0,12  / h
C3 por padrão N / D $ 0,10  / hora de CPU
C4 C4.1 1 $ 0,12  / h
C4.2 2 $ 0,24  / h
C4.3 4 0,48  $ / h
C4.4 8 $ 0,96  / h

Aglomerado elástico

Um cluster de servidores é carregado para cada uso. Existem dois tipos de modelos de carga entre os provedores: IaaS (AWS, Azure e CloudServers) uma carga baseada no tempo restante alocado, esteja a instância totalmente utilizada ou não; PaaS (AppEngine), carregue com base no consumo de CPU em excesso do aplicativo do usuário por dia.

Os clusters de servidor também são "elásticos" no sentido de que um usuário pode aumentar ou diminuir dinamicamente o número de instâncias usadas. O AppEngine realiza essa mudança de forma transparente, ao contrário do AWS, Azure e CloudServer, que oferece suporte a “dimensionamento opaco”.

Para avaliar a elasticidade dos clusters , foram realizados 3 testes:

Tempo de execução do benchmark semelhante às arquiteturas tradicionais de Benchmarking, pois mede o tempo de execução das tarefas de benchmark. As tarefas de benchmark realizam um teste de estresse em todos os recursos da máquina ( CPU , memória e disco) Custo custo para realizar cada tarefa de benchmark Latência de "escalonamento" este é o tempo decorrido entre o cliente solicitar o recurso e alocar uma nova instância. A latência de "dimensionamento" pode afetar o desempenho e o custo de implantação de um aplicativo.

Para os testes, os desempenhos dos clusters são comparados ( benchmark , custo por benchmark e latência de escala ).

Operações de serviço de armazenamento
Serviço Cirurgia
Mesa obter, colocar, consultar
Blob download, upload
Cauda enviar receber

Os serviços de armazenamento mantêm o estado e os dados de um aplicativo e são acessíveis a instâncias por meio de chamadas de API. Existem 2 modelos econômicos para operações de armazenamento. Os serviços oferecidos pela Amazon AWS e Google AppEngine são baseados nos ciclos de CPU consumidos para realizar uma operação de armazenamento, o que torna as solicitações complexas mais caras. Azure e CloudServers têm um custo fixo por operação, independentemente da complexidade da solicitação.

Para comparar os fornecedores em termos de armazenamento, foram realizados 3 testes:

tempo de resposta das operações mede o tempo de execução de uma operação de armazenamento. As operações realizadas são apoiadas por todos os fornecedores e frequentemente utilizadas pelos clientes. Essas são operações simples de leitura / gravação, consultas SQL para testar o desempenho dos bancos de dados.


a consistência dos dados mede o tempo entre a gravação de um dado e quando as leituras dele retornam um resultado válido. Essas informações são importantes para os clientes, que desejam que seus dados estejam disponíveis imediatamente. custo por operação Custo por operação nas tabelas (mili-centavos)
Fornecedor obter colocar inquerir
C1 0,13 0,31 1,47
C3 0,02 0,23 0,29
C4 0,10 0,10 0,10
Taxa de transferência máxima de uma instância (Mbps)
Fornecedor instância menor maior instância
C1 773,4 782,3
C2 235,5 265,7
C4 327,2 763,3

Rede

Para comparar o desempenho dos provedores ao nível da rede, foram realizados testes na rede intra-nuvem e em redes de longa distância.

A rede intra-nuvem conecta as instâncias de um cliente entre si e os serviços compartilhados por uma nuvem . Para comparar o desempenho de uma rede intra-nuvem , são feitas medições sobre a capacidade e latência do caminho .

A rede de longa distância conecta centros de dados em uma nuvem uns com os outros e hosts externos na Internet. Os fornecedores oferecem várias zonas para hospedar os aplicativos do cliente para reduzir a latência. A AppEngine oferece serviço DNS para escolher automaticamente um data center próximo mediante solicitação, enquanto outros provedores exigem configuração manual. A latência ótima para uma rede de longa distância é definida pela latência mínima entre uma posição ideal e qualquer data center de um fornecedor. O critério para comparar os testes será, portanto, o número de centros de dados disponíveis em um ponto ideal.

Notas e referências

Referências

  1. Merino 2011 , p.  2
  2. Brebner 2012 , p.  1
  3. Doaa 2012 , p.  2
  4. Herbst 2013 , p.  3
  5. Herbst 2013 , p.  2
  6. Doaa 2012 , p.  3
  7. Herbst 2013 , p.  3
  8. Agrawal 2011 , p.  2
  9. Liu 2014 , p.  1
  10. Sedaghat 2013 , p.  1
  11. IBM 2012
  12. Liu 2014 , p.  1
  13. Sedaghat 2013 , p.  1
  14. IBM 2012
  15. Liu 2014 , p.  4
  16. Liu 2014 , p.  0
  17. Liu 2014 , p.  2
  18. Herbst 2013 , p.  0
  19. Herbst 2013 , p.  4
  20. Herbst 2013 , p.  4
  21. Herbst 2013 , p.  4
  22. Sharma 2011 , p.  1
  23. Sharma 2011 , p.  2
  24. Sharma 2011 , p.  3
  25. Sharma 2011 , p.  3
  26. Sharma 2011 , p.  3
  27. Sharma 2011 , p.  3
  28. Sharma 2011 , p.  3
  29. Fox 2010 , p.  8
  30. Fox 2010 , p.  8
  31. Fox 2010 , p.  8
  32. Fox 2010 , p.  8
  33. Fox 2010 , p.  8
  34. Fox 2010 , p.  8
  35. Fox 2010 , p.  8
  36. Fox 2010 , p.  8
  37. Fox 2010 , p.  8
  38. Moldavo 2013 , p.  1
  39. Copil 2013 , p.  1
  40. Mao 2012 , p.  1
  41. Coutinho 2013 , p.  6
  42. Doaa 2012 , p.  0
  43. Doaa 2012 , p.  3
  44. Doaa 2012 , p.  3
  45. Doaa 2012 , p.  3
  46. Doaa 2012 , p.  2
  47. Schahram 2011 , p.  2
  48. Schahram 2011 , p.  2
  49. Fox 2010 , p.  3
  50. Schahram 2011 , p.  3
  51. Fox 2010 , p.  3
  52. Fox 2010 , p.  4
  53. Fox 2010 , p.  4
  54. Fox 2010 , p.  4
  55. Fox 2010 , p.  4
  56. . Li , 2010 , p.  3
  57. Li , 2010 , p.  6
  58. Li , 2010 , p.  6
  59. Li , 2010 , p.  6
  60. Li , 2010 , p.  6
  61. Li , 2010 , p.  3
  62. Li , 2010 , p.  3
  63. Li , 2010 , p.  5
  64. Li , 2010 , p.  4
  65. Li , 2010 , p.  4
  66. Li 2010 , p.  4
  67. Li , 2010 , p.  8
  68. Li , 2010 , p.  9
  69. Li , 2010 , p.  11
  70. Li , 2010 , p.  11
  71. Li 2010 , p.  5

Bibliografia

Documento usado para escrever o artigo : documento usado como fonte para este artigo.

  1. (pt) Doaa M. Shawky e Ahmed F. Ali, "  Definindo uma medida da elasticidade da computação em nuvem  " , Sistemas e Ciência da Computação (ICSCS), 1ª Conferência Internacional de 2012 sobre ,29-31 08 2012, p.  1-5 ( ISBN  978-1-4673-0672-0 , DOI  10.1109 / IConSCS.2012.6502449 , leia online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  2. (pt) Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica e Matei Zahariacomputing, “  A view of cloud  ” , Communications of the ACM Volume 53 Edição 4 ,abril de 2010, p.  50-58 ( DOI  10.1145 / 1721654.1721672 , ler online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  3. (en) Gandhi Anshul, Dube Parijat, Karve Alexei, Kochut Andrzej e Zhang Li, "  Modeling the Impact of Workload on Cloud Resource Scaling  " , Computer Architecture and High Performance Computing (SBAC-PAD), 2014 IEEE 26th International Symposium on ,22-24 10 2014, p.  310-317 ( DOI  10.1145 / 1721654.1721672 , ler online )
  4. (pt) Emanuel Ferreira Coutinho, Danielo Gonçalves Gomes e Jose Neuman de Souza, “  Uma análise da elasticidade em ambientes de computação em nuvem com base na alocação de tempo e recursos  ” , Cloud Computing and Communications (LatinCloud), 2º IEEE Latin American Conference on ,12/09/2013, p.  7-12 ( DOI  10.1109 / LatinCloud.2013.6842214 , ler online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  5. (en) NR Herbst, S. Kounev e R. Reussner, “  Elasticity in cloud computing: What it is, and what it is  ” , Proceedings of the 10th International Conference on Autonomic Computing (ICAC 2013), San Jose, CA. USENIX, 2013, pp. 23-27 ,24-28 06 2013( leia online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  6. (pt) Edwin Schouten, "  Rapid elasticity and the cloud  " , em http://thoughtsoncloud.com/ ,18 de setembro de 2012Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  7. (en) Chien-Yu Liu, Meng-Ru Shie, Yi-Fang Lee, Yu-Chun Lin e Kuan-Chou Lai, “  Vertical / Horizontal Resource Scaling Mechanism for Federated Clouds  ” , Information Science and Applications (ICISA), 2014 International Conferência em ,6-9 05 2014, p.  1-4 ( ISBN  978-1-4799-4443-9 , DOI  10.1109 / ICISA.2014.6847479 , ler online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  8. (pt) Mina Sedaghat, Francisco Hernandez-Rodriguez e Erik Elmroth, “  A Virtual Machine Re-packing Approach to the Horizontal vs. Troca de elasticidade vertical para escalonamento automático em nuvem  ” , CAC '13 Proceedings of the 2013 ACM Cloud and Autonomic Computing Conference ,2013( ISBN  978-1-4503-2172-3 , DOI  10.1145 / 2494621.2494628 , leia online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  9. (pt) Luis Rodero-Merino, Luis M. Vaquero e Rajkumar Buyya, “  Dimensionando Aplicativos Dinamicamente na Nuvem  ” , ACM SIGCOMM Computer Communication Review Arquivo de índice Volume 41 Edição 1 ,janeiro de 2011, p.  45-52 ( ISSN  0146-4833 , DOI  10.1145 / 1925861.1925869 , ler online )
  10. (pt) Sadeka Islam, Kevin Lee, Alan Fekete e Anna Liu, “  How a consumer pode medir elasticidade para plataformas de nuvem  ” , ICPE '12 Proceedings of the 3rd ACM / SPEC International Conference on Performance Engineering ,2012, p.  85-96 ( ISBN  978-1-4503-1202-8 , DOI  10.1145 / 2188286.2188301 , leia online )
  11. (pt) Schahram, Dustdar, Yike Guo, Benjamin Satzger e Hong-Linh Truong (2011)., “  Principles of Elastic Processes.  ” , IEEE Internet Computing, vol. 15, não. 5, pp. 66-71 , setembro / outubro de 2011. ( DOI  doi: 10.1109 / MIC.2011.121 , ler online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  12. (pt) Chen-Fang Weng e Kuochen Wang, "  Dynamic resource alocação para MMOGs em ambientes de computação em nuvem  " , Wireless Communications and Mobile Computing Conference (IWCMC), 2012 8th International ,27-31 08 2012, p.  142-146 ( ISBN  978-1-4577-1378-1 , DOI  10.1109 / IWCMC.2012.6314192 , ler online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  13. (pt) Kranas, Pavlos (2012)., “  ElaaS: An Innovative Elasticity as a Service Framework para Dynamic Management across the Cloud Stack Layers.  » , Anais da Sexta Conferência Internacional sobre Sistemas Complexos, Inteligentes e Intensivos de Software (CISIS) (IEEE) , 4-6 de julho de 2012. ( DOI  doi: 10.1109 / CISIS.2012.117 , ler online )
  14. (pt) Georgiana Copil, Daniel Moldovan, Hong-Linh Truong e Schahram Dustdar., “  Multi-level Elasticity Control of Cloud Services.  » , 11ª Conferência Internacional, ICSOC 2013, Berlim, Alemanha, p429-436 , 2-5 de dezembro de 2013. ( DOI  doi: 10.1007 / 978-3-642-45005-1_31 , ler online )
  15. (pt) Daniel Moldovan, Georgiana Copil, Hong-Linh Truong e Schahram Dustdar., “  MELA: Monitoring and Analyzing Elasticity of Cloud Services.  » , IEEE International Conference on Cloud Computing Technology and Science 2013, Bristol, p80-87 , 2-5 de dezembro de 2013. ( DOI  doi: 10.1109 / CloudCom.2013.18 , leia online )
  16. (pt) Ming Mao e Marty Humphrey., “  A Performance Study on the VM Startup Time in the Cloud  ” , Cloud Computing (CLOUD), 2012 IEEE 5th International Conference on Honolulu, HI, p423-430 , 24-29 de junho de 2012. ( DOI  10.1109 / CLOUD.2012.103 , leia online )
  17. (pt) P. Brebner , "  Is your cloud elastic enough?: performance modeling the elasticity of Infrastructure as a Service (IaaS) Cloud Applications  " , Proceeding ICPE '12 Proceedings of the 3rd ACM / SPEC International Conference on Performance Engineering ,2012, p.  263-266 ( ISBN  978-1-4503-1202-8 , DOI  10.1145 / 2188286.2188334 , leia online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.
  18. (pt) U. Sharma , "  A Cost-Aware Elasticity Provisioning System for the cloud  " , Distributed Computing Systems (ICDCS), 2011 31ª Conferência Internacional sobre ,2011, p.  559-570 ( ISSN  1063-6927 , DOI  10,1109 / ICDCS.2011.59 , lido online )
  19. (pt) A. Eldin , “  Um controlador de elasticidade híbrido adaptativo para infraestruturas em nuvem  ” , Network Operations and Management Symposium (NOMS), 2012 IEEE ,2012, p.  204-212 ( ISSN  1542-1201 , DOI  10,1109 / NOMS.2012.6211900 , lido online )
  20. (en) D. Agrawal , "  Database Scalability, Elasticity, and Autonomy in the Cloud  " , 16ª Conferência Internacional, DASFAA 2011, Hong Kong, China, 22 a 25 de abril de 2011, Proceedings, Parte I ,2011, p.  2-15 ( ISBN  978-3-642-20148-6 , DOI  10.1007 / 978-3-642-20149-3_2 , ler online )
  21. (pt) Hong-Linh Truong, Daniel Moldovan, Georgiana Copil e Schahram Dustdar., “  SYBL: An Extensible Language for Controlling Elasticity in Cloud Applications.  » , 13º Simpósio Internacional IEEE / ACM, 2013, Deft, p112-119 , 13-16 de maio de 2013. ( DOI  doi: 10.1109 / CCGrid.2013.42 , ler online )
  22. (pt) Ang Li, Xiaowei Yang, Srikanth Kandula e Ming Zhang., “  CloudCmp: comparing public cloud supplies.  » , IMC '10 Proceedings of the 10th ACM SIGCOMM conference on Internet Measurements, 2010, p1-14 , 2010. ( ISBN  978-1-4503-0483-2 , DOI  10.1145 / 1879141.1879143 , leia online )Documento usado para escrever o artigo : documento usado como fonte para este artigo.