Lições que o jogo Pokémon Go e suas falhas ensinam às empresasLançado no Japão há cerca de 30 dias, o jogo de realidade aumentada Pokémon Go tornou-se instantaneamente uma febre global 
Eduardo Saito (*) Na última semana, o jogo adicionou 26 novos países, transformando-se em uma das aplicações mais acessadas do planeta. Quer seja por causa de tantos acessos simultâneos, quer seja por ataques de negação de serviços que inundam um servidor de falsos acessos, impedindo que o portal seja acessado por usuários legítimos, os serviços do Pokémon Go têm frustrado muita gente. Diante das falhas, a Niantic Labs garante que não sofreu ataques DDoS de negação de serviços. A empresa justifica a instabilidade do sistema pelo excesso de acessos. Dois grupos de hackers – o OurMine e o DDoSers –, por outro lado, assumiram a autoria de ataques que, segundo a Niantic Labs, nunca aconteceram. Independentemente das razões por trás das falhas, o caso Pokémon Go serve de farol para prevenir problemas semelhantes enfrentados pelas corporações usuárias de TIC. Vamos investigar, inicialmente, as especificidades do caso Pokémon Go:
Jogos online são tremendamente sensíveis a problemas de latência e disponibilidade – isso faz de uma aplicação como o Pokémon Go um alvo ideal para ataques de negação de serviços. Mitigar esse tipo de ataque num servidor de jogos, ainda mais jogos de realidade aumentada, é uma tarefa bastante complexa. O ataque efetivamente consegue atingir os jogadores, que se incomodam muito com problemas de latência. Diante de qualquer problema, as redes sociais ficam imediatamente repletas de posts cheios de reclamações em diversas línguas e intensidades. Como a aplicação em questão é um jogo, parece que os hackers potencialmente envolvidos veem toda esta questão como uma brincadeira ou uma provocação. Os dois grupos de hackers que se dizem responsáveis pelos ataques contra o Pokémon Go afirmam que tudo foi feito para “ajudar a Niantic Labs a resolver seus problemas de segurança digital”. Na minha visão, esse tipo de afirmação apenas tenta esconder as verdadeiras intenções de hackers teoricamente “do bem” que, ainda assim, cobram resgates para resolver os problemas criados por eles mesmos. Hackers do bem colaboram com empresas, não expõem empresas
A verdade é que se esses hackers desejassem realmente ajudar a Niantic Labs, eles atuariam como outros pesquisadores de vulnerabilidades que, quando se deparam com um problema potencial, imediatamente avisam a empresa responsável pela aplicação Web. É comum que esses “hackers do bem” entreguem relatórios detalhados de falhas, trabalhando ombro a ombro com os desenvolvedores do sistema original para resolver todas as vulnerabilidades. Acredito que todos fariam melhor em desistir de esperar misericórdia de hackers como os grupos OurMine e DDoSers. O caminho da segurança passa pela adoção de novos parâmetros em infraestrutura de TIC e desenvolvimento de aplicações. Supondo, por exemplo, que a Niantic Labs tenha sido incapaz de fazer frente à demanda de seus usuários, isso poderia indicar um problema de planejamento de capacidade. Poucos indícios apontam nesta direção. Como esse jogo utiliza serviços na nuvem, teoricamente contaria com toda a escalabilidade de que viesse a precisar. Para que os ganhos da escalabilidade da nuvem se façam tangíveis, porém, é necessário que a aplicação Pokémon Go tenha sido construída para ser escalada de forma infinita por meio de toda a infraestrutura da nuvem. Se, por outro lado, o sistema Pokémon Go foi construído de modo tradicional, ou, então, adaptado de um sistema antigo, poderia enfrentar problemas para fazer bom uso da escalabilidade que a nuvem traz. Naturalmente a mesma lógica também se aplica às áreas de TI das empresas. Outro fator que não pode ser esquecido: a inclusão de um serviço de balanceamento de carga deve ser uma exigência em qualquer arquitetura de aplicações. Um serviço de balanceamento de carga não apenas supre a necessidade de “equipar-se para as falhas” devido ao seu inerente suporte a failover entre duas instâncias de aplicação. É importante destacar que isso é feito, sempre, de modo a preservar a qualidade do serviço oferecido ao usuário final da aplicação, independentemente do sistema ser o Pokémon Go ou um ERP como o SAP. Pode ser que o erro da Niantic Labs tenha sido não se planejar para o sucesso planetário e instantâneo do Pokémon Go. Pode ser que a empresa tenha sido alvo de ataques DDoS. De uma forma ou de outra, uma história como essa nos lembra que as mesmas métricas de qualidade de serviços exigidas por jogadores de um sistema de realidade aumentada também são valorizadas por usuários corporativos. Para evitar que sua aplicação distribuída ou Web cause frustrações é bom trabalhar a partir de três premissas básicas: preparar-se para a falha, preparar-se para escalar, na nuvem ou com recursos próprios, mais infraestrutura de rede e, finalmente, realizar o balanceamento entre diferentes elementos do sistema de modo a não interromper nem o jogo, nem os negócios. (*) É arquiteto de soluções da F5 Networks América Latina e Caribe. UpToDate ganha ainda mais praticidade e interação com funcionalidade multitarefa do iPad
AWolters Kluwer anuncia a realização de uma importante atualização na versão para iOS de seu recurso de apoio à decisão clínica UpToDate®. Com a iniciativa, uma das mais populares fontes de referência para médicos e estudantes em todo mundo, já está habilitada a interoperar com a importante funcionalidade multitarefas do iPad.
O recurso iPad MultiTasking permite que o usuário utilize o UpToDate simultaneamente com outras aplicações, como por exemplo, o prontuário eletrônico do paciente (PEP) móvel, o Safari ou o e-mail. Esta funcionalidade é especialmente útil se o médico estiver trabalhando em uma apresentação e necessita consultar algo rapidamente, ou então reportar algo via e-mail para o paciente, durante o atendimento. Além de alternar de um app para outro no dispositivo iOS, é possível voltar ao ponto em que se havia parado, o que facilita a pesquisa e a checagem de informações. A alteração entre apps pode ser feita através de gestos (para ativar ou desativar o multitarefa, basta acessar Ajustes > Geral > Multitarefa) (www.wolterskluwer.com). | C3 Tech lança teclados específicos para games
A C3 Tech lança dois modelos de teclados de alta performance feitos especificamente para garantir rapidez e melhores resultados na resposta para jogos. Os modelos KG-100BK e KGM-1000BK possuem design tecnológico, muito diferente dos convencionais, e contam com sistema avançado para os apaixonados por jogos.
As novidades possuem backlight, 26 teclas anti-ghosting (contra o efeito ghosting nas teclas – ou efeito fantasma – para comandos que precisam que mais de uma tecla seja pressionada simultaneamente), cabo em náilon, conector USB Gold e bloqueio das teclas de atalhos do Windows. Contam com sistema anti-respingo e oferecem tempo de resposta de somente 1milissegundo.
“Os modelos de teclados da C3 Tech estão inovando o mercado gamer. Ambos são grandes apostas nossas para levar os acessórios de jogos a outro patamar em questão de integração de tecnologia e design”, diz o gerente de Produtos da C3 Tech, Alexandre Oliveira.
Apesar de semelhantes, os modelos possuem diferenças técnicas. O teclado KGM-1000BK, por exemplo, possui sistema de acionamento mecânico nas teclas, garantindo, assim, desempenho e durabilidade 10 vezes maior que os modelos tradicionais que utilizam sistema de membrana. “O KGM-1000BK é o teclado gamer mais avançado. É a performance que os amantes de jogos esperam de um acessório gamer de competência”, conclui Alexandre (www.coletek.com.br). Desenvolvimento Ágil ou desenvolvimento Waterfall?Breogán Gonda (*) Desenvolvimento Ágil ou desenvolvimento Waterfall? É uma velha questão, cuja resposta eu tenho dedicado os últimos 35 anos Os fatos nos dizem que o paradigma Waterfall dominava totalmente o mundo e que, pouco a pouco, foi substituído pelo paradigma Ágil em muitas empresas, mas que seguem existindo outras, especialmente as grandes corporações, que permanecem prisioneiras do velho paradigma.
Por que quero falar agora sobre isso? Porque baixei da Amazon e li o livro: "Why Agile is Falling at Large Companies”, de Ms. Geri Schneider Winters. Meu primeiro pensamento: "outro livro que tenta provar que as coisas não pode ser feitas, que as mudanças não são possíveis". Com todo o cuidado e respeito, eu disse: ler aqueles que pensam como a mim pode ser agradável, embora provavelmente inútil, ler aqueles que pensam de forma diferente é sempre útil.
A leitura foi gratificante: o livro explora profunda e seriamente a questão. Em vez de colocar a ênfase na impossibilidade (como eu suponha ao ler o título), que nos impele a aplicar o paradigma Ágil de forma responsável, sólida, medida, tendo em conta todos os elementos necessários para o sucesso. Mas eu não vou falar mais sobre isso aqui: Sinceramente, recomendo a leitura do livro! Paradigma Waterfall
O paradigma Waterfall implica uma análise monolítica, muito profunda e detalhada do problema a ser resolvido e a resolução total do mesmo ao nível do projeto, para passar em seguida para a implementação. Será que funciona? Enfatiza a previsibilidade (custo em tempo e dinheiro) e, idealizada, tudo funciona bem, desde que o projeto inicial se ajuste a realidade, não contenha erros significativos e que essa realidade não mude muito durante o projeto.
Este paradigma foi pensado para outras circunstâncias, em que o tamanho dos sistemas e, acima de tudo, a velocidade de mudança eram muito menores do que hoje.
No início dos anos 80 começamos a ser procurados para a implementação de grandes sistemas corporativos e imediatamente enfrentamos grandes dificuldades, fomos superando com esforço, mas cada vez mais convencidos de que o paradigma que estávamos usando não era adequado.
No meu caso, em 1984, apareceu uma grande empresa brasileira que precisava de um sistema corporativo baseado em um único grande banco de dados central em torno do qual tudo precisava ser construído. Após a primeira análise se percebeu que se trataria de um banco de dados de pelo menos 500 entidades e ficou claro que enfrentá-lo com o tradicional paradigma Waterfall nos levaria ao fracasso. Também ficou claro que nós não tínhamos um paradigma alternativo, de modo que começamos a investigar, procurando novas soluções. Paradigma Ágil
Muitas pessoas tiveram, mais cedo ou mais tarde, problemas semelhantes. Todos nós fizemos, provavelmente, a mesma pergunta: Com o Waterfall priorizamos a previsibilidade de custos, mas o que ocorre com a qualidade do produto?; Como os sistemas obtidos atendemos às necessidades reais?; Como continuamos a mantê-los válidos e atualizados através do tempo? É razoável pensar que os custos (dinheiro e tempo) serão menores que em Ágil? Na prática tendem a ser muito maiores!
O paradigma Ágil tende a ser um desenvolvimento incremental. Como o caracterizamos? Por uma permanente interação, envolvimento dos usuários, prototipagem oportuna e com o nível adequado de abstração, tudo isso pode ser resumido conceitualmente em: “feedback”.
Quais os problemas fundamentais que encontramos no Paradigma Ágil? À medida que se avança, são encontradas situações que não estavam previstas. Quando devemos modificar ou adicionar processos para tratar os mesmos dados isto é feito com facilidade. Mas tudo é muito diferente quando as mudanças estruturais são necessárias no banco de dados: o nível de independência entre os dados e os programas que nos fornecem os DBMS é rudimentar e, portanto, quando há mudanças significativas nas estruturas dos dados, você precisa executar um conjunto de operações complexas, tais como, por exemplo, determinar quais os programas permanecerão corretos e quais deverão ser modificados, o que tem custos significativos no tempo, dinheiro e no risco de erros.
Não é assim no paradigma Waterfall? É também, mas Waterfall é destinada a situações de estabilidade, onde há pouca ou nenhuma alteração. A necessidade de mudanças estruturais no banco de dados
Fatalmente devemos cair neste problema? Não há nenhuma maneira de resolvê-lo automaticamente?
Foram feitas muitas tentativas: por exemplo, no final dos anos 70, ANSI-SPARC emitiu uma recomendação destinada a independência viável entre dados e programas. Então Cincom Sistemas lançou um DBMS (SUPRA), que obedecia razoavelmente a essa recomendação. Mais tarde Microsoft em sua Framework.net incluiu um mecanismo (Datasets/Dataviews) com o mesmo objetivo. Por diferentes razões, estas iniciativas não prosperaram.
Em 1985, com o resultado de investigações próprias, podemos concluir que a melhor maneira de resolver o problema foi a de aumentar o nível de abstração e passar a trabalhar com o conhecimento puro.
Ao longo do tempo temos conseguido uma boa gestão automática do conhecimento dos sistemas de negócios que nos permitem, como subprodutos, a automação de:
Projeto, geração, manutenção e reorganização do banco de dados.
Geração de projeto e manutenção de programas.
Tudo isso nós temos concretizado, principalmente, em sistemas de missão crítica para empresas de todos os tipos. RESUMO:
O paradigma Waterfall é obsoleto, mas continua existindo porque quase todos os sistemas legados utilizam.
Não é razoável enfrentar hoje sistemas novos com o paradigma Waterfall.
O paradigma Ágil oferece vantagens claras para novas aplicações.
Usando a tecnologia que permite que uma boa independência entre os dados e os programas, de modo a viabilizar um verdadeiro desenvolvimento incremental, ajuda muito. (*) É engenheiro de Computação, pesquisador, professor, consultor e presidente da GeneXus S.A., uma empresa dedicada à construção de ferramentas de software com base no tratamento automático do conhecimento. [email protected]; http://www.genexus.com. |
