![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
O alinhamento de recursos de TI com seus respectivos custos pode determinar a rentabilidade e a alocação de custo por departamento ou usuário. Se uma organização não consegue identificar os custos de recursos de TI antes e após o uso junto com o que ou quem está consumindo estes recursos, a entidade correta pode não estar pagando pelo suporte contínuo para manter os serviços disponíveis e em manutenção. Por exemplo, se um novo serviço é colocado on-line com um banco de dados comum, será impossível determinar quem pagará pelo espaço do banco de dados ou servidor, ou pelo planejamento de capacidade a longo prazo — uma falha que pode afetar os clientes da organização.
A computação em nuvem em si não ajudará uma organização a determinar quem pagará por um recurso, mas ela pode ajudar a fornecer uma plataforma para uma infraestrutura de design que estabeleça um modelo de estorno para medição e faturamento. Este artigo descreve as opções de medições e de faturamento disponíveis para modelos de computação em nuvem bem-estabelecidos, assim como modelos oferecidos pela tecnologia em desenvolvimento.
Impactos do faturamento da computação em nuvem
Cada modelo de nuvem disponível possui uma maneira específica pela qual a alocação de recurso é determinada, e essa maneira é diferente dos modelos de negócios de TI tradicionais em termos de acessibilidade e de despesa do modelo em uso. O baixo custo e a alocação melhorada de recursos de TI por serviço muda de gasto de capital com o departamento de TI comum para despesa operacional com o serviço e o usuário. Por exemplo, o número da fila de mensagens GET e PUT das atualizações das operações por solicitação pode fornecer uma estrutura de custo por cada cliente que possa, em retorno, ser acumulado para um custo total por transação e, em última instância, por cliente e por mês (similar a uma conta de telefone celular).
Contabilidade para alocação de custo em nuvem em seu código
Se a medição for baseada em transações e na alavancagem do modelo de alocação de custo de computação em nuvem, certifique-se de incluir padrões de design de custo específico em seu código de aplicativo. Arquiteturas de aplicativo projetadas sem padrões de desenvolvimento para usar o custo por uso dos recursos de aplicativo não fornecerão a infraestrutura correta para a sua organização implementar a última geração de opções de medição e faturamento de computação em nuvem. Por exemplo, desenvolvendo uma plataforma orientada a serviço de última geração e alavancando a computação em nuvem pode fornecer uma maneira nova e econômica de fornecer computação, porém essa plataforma pode perder a oportunidade de fornecer soluções inovadoras que se escalem de acordo com as demandas.
Configure uma meta de rastreamento de transação para cada solicitação de HTTP ou SOAP submetidas e seu custo associado para seu aplicativo com base em nuvem. Devido ao fato de os recursos — serem os servidores de hardware, uma solicitação do banco de dados, de fila de mensagens ou os serviços de monitoramento — são cobrados com base no uso real, portanto, você deve incluir o ID de consumo da transação em cada etapa e chamada de recurso. Por exemplo, se você chamar um serviço externo para obter dados de um banco de dados, a solicitação de HTTP associada deve incluir o ID de transação, assim como o ID de consumidor para a posterior correlação destas métricas. Claro, você deve ter um encadeamento adicional no aplicativo para capturar dados de correlação da transação, para que nem o desempenho principal da transação ou o tempo de resposta seja afetado.
Figura 1 mostra um exemplo de uma transação de um fabricante de hambúrguer que inclui os diferentes serviços de SOA e que usa o ID de transação. Os agentes são implementados em todos os nós para capturar os dados de cada transação.
Aqui, t1234 é o ID de transação que identifica a transação e cada serviço vincula o tempo decorrido de CPU ao ID de transação para medição e faturamento posterior.
Figura 1. Exemplo de transação usando serviços de SOA e IDs de transação
A operação de medição e faturamento de computação em nuvem é fornecida em algumas infraestruturas (que é a infraestrutura pública) e ainda é requisitada em nuvens privadas construídas em infraestruturas de servidor de aplicativo corporativo. As principais diferenças são as solicitações de segurança, uma vez que muitas medições e faturamentos específicos de aplicativos são similares para computação em nuvem públicas e privadas. Alguns itens de infraestrutura operacional adicionais são solicitados para medição e faturamento, como serviços de mensagens para capturar o uso de dados. Basicamente, itens de infraestrutura adicionais são implementados para gerenciar o uso e o custo de recursos de medição e faturamento de computação em nuvem.
Modelos de serviços estabelecidos
Alguns modelos de serviço foram inicialmente pensados mais como inovadores do que funcionais. Entretanto, eles são estabelecidos e considerados como utilizáveis em infraestruturas de medição e faturamento de computação em nuvem. É importante notar quais modelos foram estabelecidos —, por exemplo, faturamento de servidor em US$0,10 por hora ao invés de grandes custos de compra iniciais.
Infraestrutura como Serviço e serviços de medição e faturamento
Historicamente, o alto custo dos servidores de fornecimento e infraestrutura limitava a capacidade de desenvolver aplicativos de Software como Serviço (SaaS). Por exemplo, demoraria semanas, senão meses, para planejar, ordenar, enviar e instalar um novo hardware de servidor no datacenter. Atualmente, os novos modelos de medição e faturamento permitem a compra de hardware e sistemas operacionais — conhecidos como Infrastructure as a Service (IaaS) — em questão de minutos (veja a Figura 2).
Figura 2. Atividade de conta mensal para uma plataforma de IaaS
Os conceitos primários de IaaS incluem:
- Servidores por hora servindo como modelo sob demanda
- Servidores reservados para melhor planejamento
- Unidades de recurso de cálculo maiores e menores com base no desempenho de aplicativo
- Medição com base no volume do número de instâncias consumidas
- Recursos de infraestrutura pré-pagos e reservados
- Recursos de servidor de cluster
O faturamento para a maioria destes elementos é realizado com base em cada mês, em que cada servidor é desatribuído e retornado dentro de alguns minutos, como inicialmente fornecido. As taxas de faturamento acumuladas durante todo o mês incluem instâncias de servidores sendo executados durante todos os 30 dias, assim como servidores sendo executados apenas por um minuto. Cada ciclo de cálculo é cobrado por uma hora completa, sem considerar se ele foi executado por um minuto ou uma hora.
A medição e o planejamento avançados com instâncias reservadas permitem custos mensais e por hora mais baixos, para fazer modelos de recurso de cálculo com padrões de uso conhecidos e linhas de base disponíveis de acordo com a necessidade. Em um modelo em que os servidores são reservados previamente, um investimento inicial é necessário para garantir servidores específicos em certas áreas, a fim de minimizar o uso por hora de máquinas virtuais (VMs). Em alguns casos, o investimento inicial pode reduzir o preço por hora em até 50 por cento.
Na maioria dos casos, o ajuste de escala de instâncias durante horários que não são de pico e durante horários ou estações de pico ajudam a melhorar a disponibilidade e o tempo de resposta. Em geral, se os aplicativos estão sendo executados de forma correta, você obtém uma taxa de transação por segundo que pode ser escalada horizontalmente com o número de servidores adicionados à infraestrutura de cálculo em nuvem. A única preocupação são os recursos de terceiros que não são escalados com a infraestrutura de maneira exponencial — por exemplo, o banco de dados, os serviços de autenticação e outros serviços acessados pela infraestrutura escalável.
Com um certo número de servidores inicializados, um desconto ocorre por causa do grande volume de servidores virtuais sendo executados — por exemplo, quando você reserva 100 VMs. Este desconto em massa ajuda o fornecedor de computação em nuvem a planejar as demandas de capacidade e, portanto, minimizam o custo e o risco de instâncias sob demanda. Similarmente, instâncias pré-pagas ajudam o fornecedor de computação em nuvem a estimar a capacidade e a minimizar o risco sob demanda ficar sem recursos ou de manter muitas instâncias não utilizadas. Os descontos e o uso geralmente expiram se os recursos não são consumidos dentro de um período específico de tempo. Por exemplo, instâncias pré-pagas poderiam ser usadas como recurso de cálculo de linha de base (um servidor da Web para a intranet corporativa orientada para o exterior).
Em implementações maiores, iniciar e pausar instâncias e ser cobrado pela utilização em cluster consolida o custo e o gerenciamento de IaaS. Como o gerenciamento de servidores únicos e a utilização de recursos aumentam com os aplicativos corporativos, o faturamento por cluster — possivelmente incluindo recursos customizados como roteadores e outros dispositivos e serviços — ajuda a reduzir o custo do gerenciamento.
Platform as a Service e serviços de medição e faturamento
A medição e o faturamento da Platform as a Service (PaaS) são determinados pelo uso real, uma vez que plataformas se diferem em medidas de uso agregadas e de nível de instância. O faturamento por uso real permite que os fornecedores de PaaS executem códigos de aplicativo de vários arrendatários no mesmo conjunto de hardware, dependendo da granularidade do monitoramento de uso. Por exemplo, a largura da banda da rede, a utilização de CPU, e o uso de disco por transação ou aplicativo podem determinar o custo de uma PaaS.
Os conceitos primários da medição e do faturamento da PaaS incluem:
- Largura da banda da rede de entrada e de saída
- Tempo de CPU por hora
- Dados armazenados
- Alta disponibilidade
- Cobrança de serviço mensal
A largura da banda de tráfego de entrada e saída de rede determina o uso por usuário, e cria uma métrica para faturamento e medição. A métrica de largura da banda é útil, pois os aplicativos da Web podem ser maiores, dependendo do seu conteúdo. Por exemplo, para a maioria dos serviços da Web que retornam cargas úteis WSDL e RESTful simples, o número de linhas pode não ser significativo se comparado às transações que incluem figuras, vídeos e mídias de áudio.
A transação e a medição de solicitação de HTTP com base em tempo de CPU por hora, minuto ou segundo é o modelo de medição e de faturamento mais preciso, pois cada transação pode ser medida pelo custo total. Como não é possível determinar qual usuário de transação está consumindo uma certa quantidade de recursos de CPU por solicitação, é difícil alocar recursos em um nível de usuário. Portanto, uma medida simples e efetiva para faturamento e medição é determinar a quantidade de dados armazenados que o usuário está consumindo. Fazer isso ajuda no planejamento de capacidade, no faturamento, e na medição para serviços como armazenamento como serviço, em que dados são armazenados em grandes quantidades em servidores por toda a infraestrutura. Nesse caso, um modelo de faturamento com base nos gigabytes usados determina o custo do serviço por mês.
Como em qualquer aplicativo corporativo, a qualidade do serviço dobra (na maioria dos casos) o investimento e o preço da implementação. — muitas vezes mais que o dobro, pois a infraestrutura é replicada e inclui itens de infraestrutura adicionais para suportar a grande disponibilidade. A alta disponibilidade do faturamento e da medição permite uma qualidade melhorada do serviço com base na demanda real em casos em que a demanda pode ser antecipada.
Plataformas avançadas que possuem uma capacidade de nível de instância limitada para fornecer faturamento e medição geralmente optam por fornecer modelos de faturamento generalizados, nos quais há uma taxa única para executar o código de aplicativo. Tais plataformas geralmente incluem requisitos para código seguro que não possuem transação de longa execução e de grande consumo de CPU, assim como outras medidas de seguranças integradas para limitar a utilização na infraestrutura — por exemplo, uma plataforma na qual o código de aplicativo é implementado como um arquivo e o tempo de execução subjacente é fornecido com medidas de segurança e escalabilidade aprimoradas como um provedor de serviços pela plataforma.
Serviços de faturamento e medição e SaaS
O conceito tradicional de faturamento e medição de aplicativos de SaaS é um custo fixo mensal. Em alguns casos, dependendo da quantidade de dados ou número de "lugares", o faturamento e o preço são otimizados. O número de usuários é determinado pelo número de usuários que a organização permite acessar os aplicativos de SaaS, o que aumenta o preço da taxa mensal. Em alguns casos, se um certo volume é obtido, há um desconto. Por exemplo, o software de vendas fornecido como um serviço custaria US$50 por mês e por agente de vendas para uma empresa que utilizasse o aplicativo.
Os conceitos primários da medição e do faturamento da SaaS incluem:
- Taxas de assinatura mensais
- Taxas por usuário mensais
A taxa de assinatura mensal é uma cobrança de preço fixo por mês, geralmente por um mínimo de duração de contrato de um ano. O modelo de faturamento por mês altera o alto investimento inicial de um custo de capital de software para uma despesa operacional mensal. Este modelo é especialmente atraente para organizações de pequeno e médio porte, para ajudar no começo com o software necessário para suas iniciativas comerciais. Escalabilidade, ou modelos de pagamento contínuo, são úteis para organizações que começam com um investimento inicial pequeno e alguns usuários, e que crescem de acordo com a demanda. Em alguns casos, estas organizações podem ser escaladas enquanto fornecem acesso aos mesmos dados.
Modelos de serviços promissores
Modelos de serviço secundários estão em andamento, e podem ter modelos de faturamento e de medição padronizados que ganham aceitação em todos os níveis de negócios. Como a SaaS está ganhando aceitação, é possível que esses modelos promissores melhorem também a adoção. Por exemplo, o Database as a Service (DaaS) e o Monitoring as a Service (MaaS) estão sendo alavancados por fornecedores de SaaS e obtendo progressão para as empresas de computação em nuvem e SaaS focadas em TI.
Serviços de faturamento e medição e DaaS
A diferença entre as infraestruturas de banco de dados corporativas tradicionais e as infraestruturas de software é a escalabilidade e o faturamento integrados para o que você realmente usa. As infraestruturas de DaaS empregam os seguintes conceitos:
- Instâncias de servidores de banco de dados
- Serviços de banco de dados de computação em nuvem escaláveis
As instâncias de banco de dados que existem atualmente em grandes infraestruturas corporativas começaram como uma infraestrutura como plataforma de serviço usando contratos de licença que já existiam. Esta base ajuda na implementação de contratos de licença de software em modelos de DaaS. Por exemplo, os clientes com licenças já existentes podem executar as mesmas instâncias de banco de dados por núcleo em uma infraestrutura de computação em nuvem.
Os bancos de dados construídos para alavancar a escalabilidade da computação em nuvem estão disponíveis e são cobrados pelo uso real, geralmente com base no número de solicitações executadas no servidor. Este modelo ajuda a determinar o uso real de software de infraestruturas para bancos de dados. Às vezes, fornecedores de DaaS poderão cobrar pela utilização de bancos de dados ao incluir o tempo de CPU decorrido a partir da solicitação que mais utilizou tempo de CPU. Por exemplo, uma transação de seguro de grande execução pode incluir centenas de milissegundos de tempo de resposta, com milhares de linhas inseridas, em que as transações financeiras de pagamento podem utilizar menos, tendo tempos de resposta completos em um intervalo de 200 milissegundos.
Serviços de faturamento e medição e MaaS
Inserir MaaS a uma infraestrutura de monitoramento existente alinha-se com requisitos de disponibilidade para serviços de infraestrutura. MaaS empregam estes conceitos:
- Monitoramento externo de serviço
- Instâncias de infraestrutura de monitoramento
- Tempo de CPU decorrido
O monitoramento por meio do uso de serviços externos ficou disponível por um tempo, fornecendo verificação de disponibilidade para recursos de cálculo de TI por meio de ping ou transações sintéticas a partir de datacenters de desenvolvedores de software. Este serviço geralmente é faturado mensalmente e com base no uso real, assim como intervalos que os monitores executam a transação e ciclos nos quais os dados são coletados. Por exemplo, quando uma transação é monitorada no Web site de negócios, cada solicitação de HTTP é adicionada ao fornecedor de infraestrutura de monitoramento e cobrada como um pacote completo de 200 URLs. Esta solução não requer que as organizações tenham administradores na equipe para gerenciarem a infraestrutura de monitoramento e é cobrada em uma base mensal.
Infraestruturas mais complexas para o monitoramento da infraestrutura completa, como um serviço de software mantido pelo cliente, podem ser fornecidas como um serviço oferecido pelo fornecedor ou pelo parceiro de desenvolvimento de software, cobrado e medido em uma base de necessidade. Esta administração necessária da infraestrutura de monitoramento na camada de software e de sistema operacional inclui também o hardware e o software. Para o faturamento, os clientes podem pagar uma taxa mensal ou reutilizar as licenças corporativas existentes.
O MaaS com base no tempo decorrido de CPU determina o uso real de cada solicitação e é consolidado ao final de cada mês. Sem determinar o uso exato, é difícil fornecer soluções escaláveis para clientes de pequeno e médio porte, uma vez que os usuários podem diferir. Por exemplo, no gerenciamento de eventos, em que filtros para cada evento são processados para cada solicitação de transação, a tabela de medição é um acúmulo dos serviços de transação de composição para o tempo de CPU decorrido.
O recurso de Medição e faturamento para SaaS adiciona modelos de ofertas que se alinham com objetivos comerciais, fornecendo os requisitos de conta detalhados para as unidades de negócios em grandes organizações, assim como investimentos iniciais mais baixos para empresas iniciantes e negócios pequenos. O grande investimento inicial e a compra de software com SaaS estão mudando para se ajustarem ao que realmente é utilizado, e estão permitindo que novos projetos alavanquem softwares de classe corporativa para a qual um orçamento pode não ter sido disponibilizado anteriormente. Além disso, a escalabilidade para grandes volumes de carga de transação não está mais disponível apenas para empresas.
Similarmente, a mudança de gasto de capital para despesa operacional permite o uso de modelos de faturamento e medição mais precisos que atendam os requisitos contábeis com base no uso departamental. Por exemplo, o departamento de vendas agora pode adicionar novos usuários com base no uso real, sem aumentar a complexidade e o custo com a aquisição de novos hardwares, softwares e recursos administrativos.
Aprender
-
O artigo do developerWorks Ajuste de desempenho do IBM WebSphere e IBM Tivoli Monitoring (Jason Meiers, dezembro de
2010) demonstra o ajuste de tempo de CPU decorrido para melhorar o custo de aplicativos de SaaS.
-
Explore a Computação em nuvem no developerWorks, na qual você encontrará discussões de valor da comunidade e aprenderá sobre novos recursos técnicos relacionados à nuvem.
-
Em IBM Smart Business Cloud Computing, obtenha orientação de negócios de valor para aprimorar o desempenho e eficiência na nuvem.
-
Siga o developerWorks no Twitter.
-
Acompanhe as demos on demand no developerWorks que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.
-
O artigo de Grace Walker no developerWorks, Aspectos fundamentais da computação em nuvem, oferece uma boa introdução à computação em nuvem.
Discutir
-
Participe da
comunidade do developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
Jason Meiers é engenheiro senior de planejamento de sistemas na VISA em Silicon Valley, Califórnia, e trabalha na próxima geração de sistemas on-line de pagamento e de fraude da VISA. Ele é autor de um IBM RedBook e de vários artigos para revistas científicas. Jason é bacharel em sistemas de informações pela Fachhochschule Karlsruhe na Alemanha.
