Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Whitepaper-Custos

775 views

Published on

Whitepaper-Custos

  1. 1. Whitepaper: Insights sobre Custos Associados à Manutenção Corretiva, Perfectiva e Evolutiva de Software Marcio Marchini - https://br.linkedin.com/in/marciomarchini Setembro de 2016 1) Contexto: 44% dos Custos em Adaptações ............................................................................... 1 2) Esforço além de LOC (Lines of Code) ........................................................................................... 3 3) Defeitos e o Custo da Qualidade ..................................................................................................... 5 4) Infraestrutura para Evolução com Qualidade ....................................................................... 10 5) Customização = Complexidade = Custo Extra ....................................................................... 11 6) Inovação: Pesquisa, Insucessos e Pivotagem ........................................................................ 15 7) Escalabilidade: A Inovação Inevitável ...................................................................................... 16 8) Conclusão .............................................................................................................................................. 23 1) Contexto: 44% dos Custos em Adaptações Quando se pensa em fazer um software imagina-se sempre o contexto de um novo produto sendo codificado e que será entregue ao cliente e pronto. Mas o fato é que a grande maioria dos softwares é escrita mas precisa evoluir constantemente ao longo do tempo, após a entrega inicial. Em alguns casos isso ocorre por necessidade de adaptá-lo a novos processos ou formas de operação do cliente; em outros casos por mudança de legislação ou evolução tecnológica e obsolescência de hardware, sistemas operacionais e bibliotecas de terceiros. O fato é que o custo relativo de manter um software e gerenciar sua evolução em alguns casos já atinge mais de 90% de seu custo total, conforme pode ser visto na tabela abaixo (originalmente de https://wiki.uef.fi/download/attachments/38669960/SMCOSTS.pdf?version=2&m odificationDate=1430404596000&api=v2):
  2. 2. A tendência é clara com o passar dos anos1: Segundo o estudo do Departamento de Defesa americano (DoD/USA) em http://www.stsc.hill.af.mil/resources/tech_docs/gsam3/appenf.pdf2 , 67% dos custos de desenvolvimento de software podem ser classificados como manutenção: 1 http://www.slideshare.net/meijerandre/whitepaper-omnext 2 Também disponível em http://structure101.com/static- content/pages/resources/documents/mitre-architecture-report.pdf
  3. 3. Se fizermos um drill-down dessa fatia de manutenção, 67% podem ser enquadrados em melhorias para novas necessidades (evolução do produto): Isso equivale a cerca de 44.89% de esforço total (67% de 67%) focados em adaptação do sistema original frente a novas necessidades. E isso é sem nem levar em conta o esforço em arrumar defeitos ao longo do caminho – 21% do gráfico acima (ou seja, outros 14% do esforço total; 21% de 67%) e os testes (15% do total, demonstrado no primeiro gráfico). 2) Esforço além de LOC (Lines of Code) Embora a primeira imagem que se tenha da atividade de software é do programador codificando as features e algoritmos necessários, o fato é que quanto maior o sistema, maior é o esforço necessário em atividades complementares como teste e arquitetura. Segundo dados compilados por Steve McConnel em seu livro de Software Estimation3, dependendo do tamanho do sistema os esforços com testes 3 https://www.amazon.com/Software-Estimation-Demystifying-Developer- Practices-ebook/dp/B00JDMPOVQ/
  4. 4. chegam a ocupar 37% do esforço total, e outros 19% com Arquitetura, conforme a tabela 21-1 a seguir. O fenômeno acima se deve ao que é conhecido como “diseconomy of scale” – o aumento do gasto de forma superior a linear com o aumento do output. Na área de software, os estudos Cocomo II demonstram essa “diseconomy of scale” em termos de esforço total versus o tamanho do sistema: Vale salientar que a manutenção evolutiva (44% de esforço, visto anteriormente) demanda um constante trabalho de re-arquitetura, o que significa que esses custos
  5. 5. não somem ao longo do tempo. Similarmente, novas perturbações na base de código necessitam atenção dobrada quanto à qualidade e testes, e por isso o alto investimento necessário nesses testes. Vale salientar também que os dados acima terminam em um sistema com 500 mil linhas de código (500 KLOC). No caso de sistemas modernos com milhões de linhas de código a tendência é aumentar mais ainda o esforço com arquitetura e testes, seguindo a tendência da tabela. 3) Defeitos e o Custo da Qualidade Mas e qual é o custo esperado para detectar e remover os defeitos? Já vimos que cerca de 14% do esforço se dá corrigindo esses defeitos. Vimos também que cerca de 37% de esforço é o previsto com testes no caso de sistemas com 500KLOC. Isso ocorre devido à densidade de defeitos esperada, conforme médias da nossa indústria na tabela a seguir: Segundo o estudo acima, em novos sistemas com 500KLOC a taxa de defeitos a ser encontrada após a codificação pode variar de 4 a 100 defeitos a cada mil linhas de código (ou seja, podemos chegar a 50.000 defeitos em um sistema com 500KLOC!!!). No caso de novas funcionalidades, medidas por ponto de função, a taxa de defeitos da indústria4 é: 4 Segundo estudo de Capers Jones, compilado no livro Software Estimation de Steve McConnel.
  6. 6. Ou seja: em uma entrega de 200 pontos de função, esperam-se 1.000 defeitos! Um erro comum é assumir que essa taxa seja constante (numDefeitos = 5*numPF), independentemente do tamanho do sistema. Capers Jones recomenda5 usar um expoente de 1.25 para que a fórmula reflita a não-linearidade da complexidade com o tamanho dos sistemas, o que gera a fórmula: numDefeitos = numPF ˆ 1.25. Isso significa que o fator 5:1 da tabela 21-10 na verdade sobe muito, conforme exemplos abaixo: Total de Pontos de Função Número de Defeitos Esperados (PFˆ1.25) Fator (defeitos:PF) 1.000 5.623 5.6 : 1 5.000 42.044 8.4 : 1 15.000 16.6002 11 : 1 50.000 747.674 14.95 : 1 Em outras palavras: a taxa de defeitos por PF cresce exponencialmente (e não linearmente), atingindo taxas 3X maiores em sistemas grandes quando comparado a sistemas menores (14.95 é aproximadamente 3 X 5). O que pode ser feito para combater essa diminuição exponencial da qualidade com o tamanho do projeto greenfield6? Obviamente há técnicas variadas de redução e detecção de defeitos, e a adoção das mesmas envolve custos. Dentre as principais técnicas e efetividade correspondente, destacam-se: 5 http://rbcs-us.com/site/assets/files/1337/measuring-defect-potentials-and- defect-removal-efficiency.pdf 6 Greenfield pois se aplica a um novo projeto sendo feito do zero. Para projetos de manutenção sobre uma base de código já existente sabe-se que o problema aumenta mais ainda, embora não tenhamos localizado na bibliografia uma quantificação precisa.
  7. 7. Esses esforços confirmam o custo da qualidade. O tempo extra investido com testes unitários, code reviews, code inspections, testes de integração etc é necessário a cada Sprint, a cada Release; é um custo recorrente. Por exemplo, para remover 84% dos defeitos7, tal investimento se desdobraria tipicamente da seguinte forma: 7 Para ilustrar: em 2008 a média de remoção de defeitos da indústria dos EUA era de 85% segundo Capers Jones em http://rbcs- us.com/site/assets/files/1337/measuring-defect-potentials-and-defect-removal- efficiency.pdf
  8. 8. Note que, ainda assim, teríamos 792 defeitos nesse conjunto de 1.000 pontos de função. Para aumentar ainda mais a qualidade e remover 95% dos defeitos, teríamos a necessidade de investir mais esforço ainda e distribuir o nosso investimento da seguinte forma: Note que, ainda assim, teríamos 226 defeitos nesses 1.000 pontos de função, mesmo com todo o esforço extra investido. Na nossa indústria almeja-se o “defeito zero”,
  9. 9. mas o fato é que ainda estamos longe desse sonho, mesmo com bastante esforço investido. Mas como quantificar a quantidade de testes necessários? Segundo Capers Jones8, o número de test cases recomendado é exponencialmente proporcional ao número de pontos de função de um sistema, seguindo a fórmula: numTestCases = numPF ^1.2. Exemplo: Total de Pontos de Função Número de Test Cases (PFˆ1.2) Fator (test cases:PF) 1.000 3.981 3.9 : 1 5.000 27.464 5.49 : 1 15.000 102.638 6.84 : 1 50.000 435.275 8.7 : 1 Em outras palavras: a quantidade de test cases recomendada por PF cresce exponencialmente (e não linearmente) com o tamanho do sistema, atingindo taxas 2X maiores em sistemas grandes quando comparado a sistemas menores (8.7 é aproximadamente 2 X 3.9). Para aumentar a taxa de detecção de erros de 95% para 99%, segundo Capers Jones9 seria necessário inspecionar manualmente 100% dos itens e aumentar os test cases em mais 20%. É preciso frisar também que à medida que sistemas são disponibilizados a um maior número de usuários – principalmente com a democratização do acesso a Internet e a migração dos sistemas para tecnologias Web e Cloud em geral – esses ficam sob um maior escrutínio de usuários. Aumenta a quantidade de problemas constatados, mas não por um aumento de defeitos, e sim por uma maior probabilidade de executar combinações de dados ou use cases nunca antes exercitados. A necessidade de escalabilidade também traz a necessidade de mais tecnologias – mais complexidade – para lidar com performance, tais como servidores de cache (Redis, memcache), réplicas de bases de dados, sincronizações de bases federadas, servidores redundantes e diversas práticas necessárias para alta disponibilidade e escalabilidade, que abordaremos mais adiante. É inevitável: com a popularidade vem a complexidade e aumento de custos. Um caso extremo sendo o Facebook, que atualmente conta não apenas com diversas máquinas em Cloud, mas na verdade com diversos datacenters espalhados pelo mundo10. 8 http://rbcs-us.com/site/assets/files/1337/measuring-defect-potentials-and- defect-removal-efficiency.pdf 9 http://rbcs-us.com/site/assets/files/1337/measuring-defect-potentials-and- defect-removal-efficiency.pdf 10 http://www.datacenterknowledge.com/the-facebook-data-center-faq/
  10. 10. Ou seja, além do investimento com pessoas realizando atividades que reduzem os defeitos do produto, o fato é que há toda uma infraestrutura de hardware e software por trás, necessária para dar suporte às atividades de redução de defeitos elencadas acima. Essa infraestrutura, claro, é administrada por pessoas (SysAdmins, DevOps, DBAs, etc) que disponibilizam toda uma plataforma 24/7 para manter isso em operação. 4) Infraestrutura para Evolução com Qualidade Se olharmos a estrutura de times defendida por uma framework Ágil de Larga Escala como o SAFe, podemos verificar a presença do System Team: http://www.scaledagileframework.com/system-team/ . É um reconhecimento de que manter a cadência de entregas de Releases particionadas em Sprints e mantendo os defeitos sob controle requer todo um investimento em time e infraestrutura. Tal time é responsável não somente pelas atividades de testes - já abordada anteriormente - mas também um conjunto de atividades conhecida como Release Engineering11 (por vezes abreviada como RelEng). Podemos elencar as seguintes necessidades de investimento: • Máquinas virtuais disponíveis numa estrutura de cloud interna, permitindo que desenvolvedores possam instanciar ambientes Sandbox de DEV ou STAGING para rodar seus testes unitários e de aceitação antes de efetuar commit. • DevOps para administrar essa plataforma - como por exemplo OpenShift e/ou OpenStack – dando suporte aos desenvolvedores operarem no modo self-serve, provisionando novas instâncias de bancos de dados, servlet containers, servidores de build contínuo como Jenkins e similares, etc. • Hardware robusto – por exemplo, Blades – capazes de sustentar toda essa operação com CPU, I/O e Storage adequados e o respectivo suporte de NO- BREAKs industriais. • Sysadmins responsáveis pela configuração e manutenção das Blades, roteadores CISCO, Storage, back-ups, VPNs e demais infraestrutura que dá suporte aos DevOps se preocuparem exclusivamente em atender às necessidades dos desenvolvedores. • Licenciamento de sistemas operacionais e bancos de dados consomem uma boa fatia de investimento. Por exemplo, um sistema federado com 5 máquinas Windows diferentes e 3 bancos de dados para rodar uma bateria de testes de integração de um changeset – essencial para detecção de problemas conforme vimos anteriormente – requer múltiplas licenças válidas para os vários sistemas operacionais e os bancos de dados a serem levantados. Multiplique isso pelo número de desenvolvedores codificando e testando concorrentemente, cada qual com um sandbox, e o investimento em 11 https://en.wikipedia.org/wiki/Release_engineering
  11. 11. licenciamento e hardware torna-se bastante elevado. No caso de testes de regressão de performance necessita-se instanciar máquinas com um número de processadores e RAM similar aos de produção, o que encarece o licenciamento e a plataforma de hardware necessária (mais lâminas na Blade, mais storage, mais RAM, mais processadores, etc). • Ferramentas de controle de qualidade de software. Por exemplo, SciTools Understand12 para controle de métricas, Structure 10113 para controle de arquitetura. Essas ferramentas possuem licenciamento por máquina e requerem updates anuais e contratos de manutenção. No caso de disponibilização das mesmas não só no servidor de build quanto nas máquinas dos arquitetos, isso requer investimento extra substancial. Mas é o uso das mesmas que permite controlar a entropia do software, impedindo a descaracterização da arquitetura original a qual elevaria a taxa de defeitos. • Treinamentos dos profissionais envolvidos requer um investimento recorrente. Cursos e certificações nas diversas ferramentas, sistemas operacionais, bancos de dados, hardware etc são fundamentais para fornecer uma infraestrutura de alta disponibilidade e eficiência. Vale lembrar que em muitos casos uma cloud terceirizada como Microsoft Azure ou Amazon AWS não é viável por conta de legislação e/ou privacidade dos dados. Mas mesmo quando são viáveis, diversos dos custos acima ainda assim se aplicam. 5) Customização = Complexidade = Custo Extra Os fatores já apresentados aqui se aplicam tanto a softwares “de prateleira” (shrink- wrap) como Word, Excel, Waze etc quanto a softwares customizados para clientes específicos (CRMs customizados, ERPs customizados, etc). Porém, há de se mencionar que o impacto (e consequentemente custo) dessas customizações para clientes diferentes é incrivelmente alto. Mas por que isso ocorre? Embora uma visão superficial possa sugerir que a grande maioria do software customizado é a mesma, com “apenas alguns ifs em lugares estratégicos, com rotinas específicas para as features customizadas”, o fato é que software não é linear como uma parede onde se coloca apenas mais um tijolo, sem efeito colateral na parede existente. Cada if extra inserido para comportar um caso especial para o cliente A ou B abre no mínimo duas possibilidades distintas de execução (entrando no if ou não entrando no if). Um programa com 1 if tem duas rotas possíveis de execução. Um programa com 2 ifs possui 4 rotas de execução, e assim por diante. Isso significa que 12 https://scitools.com 13 http://structure101.com
  12. 12. um programa com apenas 32 ifs teria mais de 4 bilhões14 de rotas diferentes de execução, necessitando 4 bilhões de testes para exercitar todas as possíveis combinações desses fluxos de execução15. Hoje sabemos da forte correlação entre essa quantidade de ifs e a taxa de bugs e custos de manutenção e testes: Complexidade Ciclomática ou McCabe16. Essa medida tem sido usada em nossa indústria como principal indicador de dificuldade de manutenção de software17. Sabe-se que essas “condições especiais” (customizações) contribuem em muito à diminuição de produtividade por consequência do aumento de ifs em sistemas com alto grau de customização para clientes diferentes, conforme a tabela abaixo: 14 2ˆ32 = 4.294.967.296 15 Isso sem considerar variações nos dados de entrada, o que aumentaria em muito esses números de testes necessários. 16 McCabe,Tom, 1976. “A Complexity Measure,” IEEE Transactions on Software Engineering, Volume SE-2, Number 12 (December 1976), pp. 308–320. 17 Ward,WilliamT., 1989b. “Software Defect Prevention Using McCabe’s Complexity Metric,” Hewlett Packard Journal, April 1989, pp. 64–68.
  13. 13. Podemos ver que, por exemplo, para “Internet Systems (public)”, a produtividade de 1.500LOC/mês/pessoa em um sistema de 10KLOC (sistema pequeno) cai para 200LOC/mês/pessoa em um sistema de 250KLOC – e a tendência é piorar ainda mais em sistemas com milhões de linhas de código. No caso de aplicações de missão crítica, pode-se notar um custo maior ainda. Na tabela 5-2 acima, contraste “Command and Control” (missão crítica) com “Internet Systems (public)”18: constata-se uma produtividade de cerca de 3 vezes menos! Esse 18 Mais recentemente, devido a alta escalabilidade, até mesmo sistemas de internet têm-se considerado de missão crítica: uma pausa de 15mins no Groupon significa
  14. 14. é o reflexo de todo o overhead necessário para se especificar, codificar, inspecionar e testar com muito maior rigidez conforme demandam tais aplicações de missão crítica. Veja que no caso extremo de “Avionics”, chega-se a um custo de 5...7 vezes maior que “Internet Systems (public)”, com uma produtividade de apenas 40LOC/mês/pessoa em sistemas de 250KLOC. Nos sistemas Avionics modernos com milhões de linhas de código, a tendência é só diminuir essa produtividade. Conforme disse Ray Ozzie, ex Microsoft Chief Architect, “Complexity Kills”: Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity makes products difficult to plan, build, test and use. Complexity introduces security challenges. Complexity causes administrator frustration. And as time goes on and as software products mature – even with the best of intent – complexity is inescapable.19 A mensagem é clara: menos customizações permitem maior simplicidade (menos ifs) e maior foco. Nota-se que esta é a abordagem da Apple com seu OS/X, o qual precisa rodar corretamente apenas nos hardwares fabricados pela própria empresa. Em contrapartida temos o problema do Windows com sua necessidade de suportar milhares de configurações de hardware distintas, aumentando em muito a probabilidade de inserção de defeitos e a necessidade de investimento muito alto para controle de qualidade – ou deixar passar mais bugs, resultando nas infames telas azuis (“Blue Screen of Death”) nos casos de crash, que tanto denegriram a imagem de qualidade da Microsoft. Com softwares customizados o problema é exacerbado pois não se tratam de customizações periféricas com drivers externos ao sistema principal; tratam-se de customizações no cerne dos sistemas em si. Como se o Windows não apenas precisasse rodar em equipamentos HP e IBM, mas que o Internet Explorer se comportasse de forma substancialmente diferente na NASA ou no MIT ou na GE, por customizações feitas para essas corporações. Na prática teríamos, compilados monoliticamente em apenas 1 Internet Explorer, 3 IEs diferentes: 1 para a NASA, 1 para o MIT e 1 para a GE – com o agravante da complexidade extra e dos efeitos colaterais deles entre si, coexistindo numa mesma base de código fonte e em runtime. Vale então ressaltar que a economia pela comunalidade de código é aparente – cada variação do software customizado vai requerer mais profissionais, muito mais code uma perda de faturamento de US$175.000,00 segundo https://engineering.groupon.com/2016/misc/processing-payments-at-scale/ 19 http://www.zdnet.com/article/complexity-kills-can-microsoft-and-all-of-it- simplify/
  15. 15. reviews, mais infraestrutura de build20 e mais testes pois aumenta exponencialmente o risco, conforme vimos anteriormente (McCabe). 6) Inovação: Pesquisa, Insucessos e Pivotagem Com a maior disseminação de práticas Lean e seu processo de PDCA aplicado no nicho de start-ups, tem-se hoje uma maior consciência da necessidade de investir em pesquisa, experimentos e pivotar no caso de experimentos falhos devido a hipóteses que não se concretizam21. Esse tipo de prática se aplica também a empresas maiores – as chamadas Lean Enterprises22. Tais experimentos falhos agregam custos na operação das empresas de software. Exemplo: seria melhor continuar usando Oracle ou trocar para MongoDB para uma maior escalabilidade? Somente experimentos com carga elevada e nas use cases reais poderão ajudar a elucidar indagações como esta, e esses experimentos têm alto custo de realização. Alguns deles chegam a necessitar toda uma implementação (codificação) para serem realizados, que pode ou não virar parte do produto. Em grande parte dos casos tais inovações podem inclusive resultar em ZERO pontos de função sob uma ótica de features observáveis pelos clientes. Certamente esse tipo de investimento precisa ser diluído no custo da solução em si. Toda empresa passa por isso mais cedo ou mais tarde. Facebook, por exemplo, chegou a produzir o próprio compilador PHP para aumentar a performance de sua plataforma web23. No caso da Intuit, por exemplo, os investimentos em inovação se desdobram da seguinte forma24: 20 Exemplo: o cliente A roda em Oracle e o cliente B roda em SQL SERVER. Isso requer refazer scripts de migração, repensar índices, rodar todos os testes contra os 2 bancos, etc. Todo o código existente – comum ou não – precisa ser avaliado do zero, como se faz em um novo sistema individual não customizado. 21 http://theleanstartup.com/book 22 https://www.amazon.com/Lean-Enterprise-Performance-Organizations- Innovate/dp/1449368425 23 https://www.facebook.com/notes/facebook-engineering/the-hiphop-virtual- machine/10150415177928920/ 24 Fonte: livro Lean Enterprise
  16. 16. A mensagem é clara: investir em inovação é inevitável para empresas que se mantêm relevantes e competitivas no mercado. Em alguns casos, investimentos da ordem de 40% precisam ser efetuados. 7) Escalabilidade: A Inovação Inevitável Dentre as inovações que as empresas de software precisam incorporar mais cedo ou mais tarde é o suporte à escalabilidade. Com a digitalização da sociedade aumentando, o número de usuários que acessam os sistemas chega a crescer várias ordens de grandeza. Um exemplo extremo já citado aqui é o Facebook, em 2016 com 1.71 bilhões de usuários ativos por mês25. Conforme já mencionamos, essa escalabilidade vem com um custo – até mesmo datacenters próprios. Mas e que outros custos (além de hardware) são de se esperar com a escalabilidade? Destacamos os principais: • Arquiteto de escalabilidade. Esse tipo de profissional é indispensável em times com sistemas escaláveis26, sempre antevendo os impactos de performance no sistema. Performance com escalabilidade é tipicamente um requisito não funcional, que não conta como ponto de função, mas cuja ausência pode significar o colapso da solução de software. Conforme Abbott27, esse profissional deve lançar mão de técnicas de “Fault Isolative Architecture Structures” dentre tantas outras (capítulo 21). • Desenvolvedores Sênior em maior densidade, uma vez que algoritmos e queries precisam ser muito bem projetados para que novas features na manutenção adaptativa não impactem negativamente a performance do sistema rodando28. Em outros casos, soluções precisam ser re-arquitetadas diversas vezes para acompanhar as demandas de escalabilidade, conforme casos do Twitter, Facebook, Instagram, Pinterest e outros. • Infra Extra e Profissionais Extra de Teste de Escalabilidade. Conforme já mencionamos, a infraestrutura para testes em STAGING tem que ser capaz de 25 https://www.statista.com/statistics/264810/number-of-monthly-active- facebook-users-worldwide/ 26 https://www.amazon.com/Scalability-Rules-Principles-Scaling- Sites/dp/0321753887/ 27 https://www.amazon.com/Art-Scalability-Architecture-Organizations- Enterprise/dp/0134032802 28 Caso real: algo tão simples como adicionar um campo DATE no Oracle pode praticamente parar um sistema devido à baixa performance de buscas no caso do campo permitir NULL. Esse campo jamais será indexado no Oracle, necessitando Sequential Table Scans. Um professional junior ou pleno raramente possui esse tipo de conhecimento.
  17. 17. emular o setup escalável de PRODUCTION. Isso significa o mesmo número de máquinas, bases de dados, memória etc em testes de carga. Há necessidade de profissionais capazes de levantar todo esse setup e exercitar os testes de aceitação e regressão. Mais usuários significa maior probabilidade de achar bugs, e consequentemente maior necessidade de testes e testadores. Achar 84% dos erros é menos custoso do que de achar 95% dos erros, e assim por diante (99% dos erros necessitando um esforço muito além, conforme visto aqui). Tais profissionais precisam ter fluência com ferramentas de teste de escalabilidade como JMeter29, tsung30, locust31 dentre outros, com conhecimento de probabilidade e estatística para saberem montar experimentos representativos e interpretar os resultados. • DBAs de Escalabilidade. Com o aumento da carga nos sistemas surge a necessidade de termos estratégias de maior performance com bancos de dados. Uma delas é a eliminação de locks nas consultas através da utilização de réplicas read-only (ou followers na nomenclatura Heroku32). Outra técnica importante é o uso de sharding de bancos, muito bem explicada pelos engenheiros da Pinterest33 - os quais chegaram a usar 88 bancos de dados MySQL em 201334. Esse tipo de know-how não é fácil de encontrar nos DBAs regulares no mercado. • Engenheiros de Monitoramento de Escalabilidade. Através do uso de APMs35 tais como New Relic, esse perfil de profissional precisa estar familiarizado com termos como apdex36 dentre outros, observando a performance dos sistemas não só na média mas também nos percentis 95% e 99%. Por exemplo, um profissional menos capacitado pode considerar o gráfico de APM abaixo como perfeitamente tranquilo: 29 http://jmeter.apache.org 30 http://tsung.erlang-projects.org 31 http://locust.io 32 https://devcenter.heroku.com/articles/heroku-postgres-follower-databases 33 https://engineering.pinterest.com/blog/sharding-pinterest-how-we-scaled-our- mysql-fleet 34 http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of- billions-of-page-views-a.html 35 https://en.wikipedia.org/wiki/Application_performance_management 36 https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measuring- user-satisfaction
  18. 18. Porém, um profissional diferenciado (mais caro) saberá que precisa observar não apenas a média (115ms), mas estará atento às inconsistências de performance segundo os percentis, como no gráfico abaixo: O gráfico acima mostra que embora a média de resposta desse servidor esteja em 115ms, há muita variação de performance, chegando a 1000ms em alguns casos, o que afeta a satisfação dos usuários. Isso se reflete na oscilação apdex, abaixo: Apenas profissionais diferenciados serão capazes de perceber esse tipo de anomalia e articular com o time de Desenvolvimento e os Product Owners para incorporar mudanças de arquitetura para um melhor apdex e
  19. 19. consequentemente maior escalabilidade - sabendo-se que não há como converter esse esforço em pontos de função; são requisitos não funcionais. Em alguns casos extremos, frameworks e utilitários precisam ser codificados e implantados para capturar todo esse trace. O Twitter, por exemplo, precisou investir esforço em zipkin37 para rastrear os gargalos de performance38. Outras empresas precisam investir em soluções SaaS para logs e crashes, como Splunk39, Sentry40 , Logentries41 e outros. • Gestão e Processos para Escalabilidade. Conforme Abbott42, escalabilidade requer uma mudança de cultura e gestão nas empresas (o que demanda custos com a mudança dessa cultura), de acordo com a matriz RASCI43 abaixo: A própria maturidade e complexidade dos processos sobe para lidar com a qualidade frente à escalabilidade, conforme Abbott no diagrama a seguir44: 37 https://github.com/openzipkin/zipkin 38 http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal- with-150m-active-users.html 39 https://www.splunk.com 40 https://sentry.io 41 https://logentries.com 42 https://www.amazon.com/Art-Scalability-Architecture-Organizations- Enterprise/dp/0134032802 43 Responsible, Accountable, Supportive, Consulted, Informed. 44 Capítulo 7, “Why Processes are Critical to Scale”.
  20. 20. Com esse aumento de complexidade, sobem os custos recorrentes. A essência do problema é simples: com uma maior operação, maior suporte à escalabilidade é necessário, de forma evolutiva. O desafio para empresas competitivas é escalar a operação de forma não linear com o crescimento de usuários, ou os custos seriam proibitivos. Conforme Raymond Blum, da Google: “[you can’t] scale effort with capacity”45. Ou seja, embora os custos adicionais com um maior número de usuários precise ser repassado ao cliente, o fato é que um aumento em 100X no número de usuários não pode acarretar em aumento de custo operacional de 100X, ou a operação não será economicamente viável. É preciso atingir uma operação onde o custo da escalabilidade seja, por exemplo, log(N) em relação ao número de usuários ou transações, com modelos de cobrança que sejam intuitivos para os clientes e de melhor aceitação. Alguns exemplos da indústria: • Unidades de armazenamento: Sentry, dentre outros, utiliza o número de eventos por dia como unidade de escalabilidade relativa ao número de usuários e o plano correspondente, com limite também na duração da retenção46: • Unidades de processamento: Empresas como Oracle cobram por cores usados no servidor47, conforme a fórmula: (number of cores)*(multi-core factor). Os fatores são diferentes conforme a capacidade da máquina, de tal forma a tornar o pagamento proporcional ao maior uso e consequentemente 45 http://highscalability.com/blog/2014/6/4/the-secret-of-scaling-you-cant- linearly-scale-effort-with-ca.html 46 https://sentry.io/pricing/ 47 http://www.orafaq.com/wiki/Oracle_licensing
  21. 21. à maior demanda sobre a operação de inovação e qualidade da Oracle para atender àquele perfil de cliente (maior exigência). É um rateio dos custos recorrentes sobre a estrutura da Oracle para se ter software de alta escalabilidade com qualidade. • Mix: Empresas como New Relic utilizam o conceito de Compute Unit48, combinando CPU e RAM: (CPU cores + GB of RAM) x number of hours used = CU. O preço é calculado pelo valor do final em CU, conforme o screenshot a seguir: • Usuários e/ou Conexões: Empresas como a Microsoft possuem planos que cobram por número de conexões aos seus sistemas, as chamadas CAL49 (Client Access License) – não só para servidores Windows mas também para seu banco SQL Server50. É uma alternativa aos planos por CPU. É preciso salientar que em diversos sistemas existe uma “deseconomia de escala”: o ponto em que o aumento de escalabilidade aumenta em muito os custos, e os sistemas passam a não ser mais lucrativos na forma atual51: 48 https://newrelic.com/application-monitoring/pricing 49 https://www.microsoft.com/en-us/licensing/product-licensing/client-access- license.aspx , https://blogs.technet.microsoft.com/volume- licensing/2014/03/10/licensing-how-to-when-do-i-need-a-client-access-license- cal/ 50 http://serverfault.com/questions/120276/how-are-sql-server-cals-counted , http://download.microsoft.com/download/6/F/8/6F84A9FE-1E5C-44CC-87BB- C236BFCBA4DF/SQLServer2008_LicensingGuide.pdf 51 http://www.investopedia.com/terms/d/diseconomiesofscale.asp
  22. 22. Nesse ponto uma re-arquitetura precisa ser feita para tornar a plataforma novamente escalável economicamente para o próximo patamar de uso previsto. Essa é a estória recorrente de empresas como Twitter, Facebook, Pinterest conforme já relatado aqui. Mas quais são os principais fatores que influenciam essa curva? No estudo “Which Factors Affect Software Projects Maintenance Cost More?”52, alguns fatores estão atrelados à escalabilidade e disponibilidade53: Row Indexes Related to the Information of Cost Factors 1 Product Characteristics 2 Required Software Reliability 3 Database Size 4 Complexity Product 5 Computer Characteristics 6 Execution Time Constraint Os principais fatores são justamente a robustez e performance frente ao número de usuários54, balizados pela complexidade do produto: Indexes Related to the Information of Cost Factors Very Little Little Normal Much Very Much Product Characteristics Required Software Reliability 7.5 7.5 57.5 27.5 0 Database Size 40 30 20 10 0 Product Complexity 0 2.5 10 40 47.5 Computer Characteristics Execution Time Constraint 0 0 2.5 30 67.5 52 http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/ , http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/pdf/AIM-21-1-15.pdf 53 A tabela completa se encontra em http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/table/table001/ 54 A tabela complete pode ser encontrada em http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/table/table002/
  23. 23. Por conta disso, segundo Cocomo II, devem-se utilizar os seguintes “scaling factors” em relação aos custos: Note os coeficientes para “Product Complexity”, “Time Constraint” e “Required Software Availability” – todos atrelados à disponibilidade e escalabilidade da solução. Em suma: Estabeleça se sua plataforma é CPU-bound, IO-bound, storage-bound ou uma combinação, definindo planos de cobrança condizentes com a expectativa de disponibilidade e escalabilidade frente aos seus custos recorrentes para uma manutenção corretiva, perfectiva e adaptativa com a qualidade esperada pelos seus clientes. 8) Conclusão Sistemas de software precisam evoluir e se adaptar e essas constantes mudanças abalam a integridade da arquitetura original. Para conter essa tendência natural à decadência, todo um investimento em boas práticas, ferramentas e profissionais capacitados precisa ser feito, de forma recorrente, com inovação constante. No caso de softwares customizados, a tendência é o aumento exponencial do risco. Com a escalabilidade, aumentam ainda mais os custos operacionais e aumenta a exposição ao risco de mais defeitos serem detectados por uma maior base de usuários. Mas a
  24. 24. escalabilidade é apenas um dentre tantos requisitos não funcionais55, não computáveis com pontos de função56, mas cuja existência e esforço fica evidente nas bibliotecas Open Source criadas por empresas enquanto implementavam os seus requisitos funcionais57. Toda essa base de código para requisitos não funcionais aumenta o custo por pontos de função observáveis em softwares de larga escala. Cobrimos aqui alguns números da indústria e onde investimentos precisam ser feitos, e sua ordem de grandeza. O fato é que não há nada de “soft” em “software” – principalmente de larga escala - e qualquer aumento de qualidade requer investimento substancial e não linear (geralmente exponencial, conforme vimos aqui) com o aumento dessa base de código e de usuários. Mas o aumento da complexidade nas soluções de software é inevitável - afinal, “Software is eating the World”58. 55 http://www-di.inf.puc-rio.br/~julio/nfr-chung-leite.pdf , http://v3.scaledagileframework.com/nonfunctional-requirements/ 56 Alternativas incluem SNAP Points (http://fattocs.com/pt/cursos/nossos- cursos/snap.html), Use Case Points (https://www.researchgate.net/publication/4200526_Effort_estimation_of_use_cas es_for_incremental_large-scale_software_development) e outros. 57 http://uber.github.io, https://netflix.github.io , https://code.facebook.com/projects/ por exemplo. 58 http://www.wsj.com/articles/SB100014240531119034809045765122509156294 60

×