BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Desafios no desenvolvimento de APIs e IoT no mundo programável

Desafios no desenvolvimento de APIs e IoT no mundo programável

Favoritos

O mundo está gradualmente se tornando mais programável e a gama de soluções técnicas que temos à nossa disposição para criar essa mudança cresce a uma velocidade vertiginosa. O potencial do mundo programável , a empresa programável e até mesmo o humano programável é espetacular. Contudo, talvez precisemos voltar um passo atrás, e refletir sobre o que o comportamento da indústria.

Este é o tema da palestra que Steven Willmott, diretor sênior e head de infraestrutura de API Red Hat e ex-CEO da 3scale Inc, apresentou no último APIdays na Austrália e é resumida neste artigo.

Dentre os temas abordados, é discutido como APIs e os recentes avanços tecnológicos estão contribuindo para o mundo programável. É realizada uma reflexão sobre quais são os nossos objetivos com este avanço e por fim, são compartilhadas quais são as melhores práticas para sucesso nesta área.

Steven abre a palestra afirmando que estamos vivendo uma época sem precedentes, onde é possível construir praticamente qualquer ideia de negócio de forma simples, rápida e com pouco recursos. Ele afirma que toda a infraestrutura das empresas devem se basear em três pilares: integração, containers e APIs.

As APIs permitem que você crie ilhas de estabilidade em torno da sua empresa, para que você possa construir seu negócio sobre cada componente do seu sistema. E que containers se tornaram a maneira padrão de escalar o deploy da sua aplicação.

Integração entre diversos sistemas sempre foi tema central do mundo de TI, mas esta área está sofrendo uma importante mudança de paradigma. Do antigo cenário onde se integrava toda a arquitetura em um único ponto central, a integração evoluiu e vem sendo realizada de forma distribuída, ou seja, em todos os pontos da sua arquitetura.

Em seguida, Willmott demonstra como a tecnologia que nós utilizamos diariamente, não existiam há 10 anos atrás. Como exemplo, o AirBnb que transformou o modo que pensamos em hospedagem, tecnologias eletrônicas de fechadura, que mudaram a forma que acessamos nossos lares e tecnologias como Amazon Echo e Alexa que mudaram a forma que nos comunicamos com a nossa casa.

Trazendo estas inovações para perspectiva de software, Steven aponta exemplos como a Stripe, que possibilita que uma aplicação aceite pagamentos com apenas duas linhas de código e ainda analise as métricas de negócio da empresa, tornando simples criar um negócio com recursos limitados, e a Fitbit, plataforma de tracking de dados de saúde que recebe mais de 400 bilhões de chamadas por mês em sua API e que possibilita ao usuário criar dashboards de monitoramento da sua saúde e atividade física, e ainda compartilhar estes dados de saúde com hospitais e clínicas.

Na perspectiva de hardware, ele afirma que dispositivos com tamanho reduzido, gps de baixo custo, RFIDs minúsculos e tecnologias como hololens da Microsoft revolucionarão a forma como vivenciamos o mundo. Como exemplo, ele afirma que estes dispositivos transformarão a vida de portadores de deficiência visual ou auditiva.

Contudo, toda esta funcionalidade torna a disponibilidade de nossos dispositivos e dados um fator crítico ao usuários, pois cada vez mais a população torna-se dependente destas tecnologias. E Steven faz a seguinte pergunta:

E o que estamos fazendo com toda esta responsabilidade e dependência das nossas tecnologias?

Ele afirma que são quatro áreas principais que devemos nos preocupar em relação ao nosso software e hardware: segurança, comportamento inesperado, deficiência tecnológica e impacto social.

São apresentadas alguns exemplos de brechas de segurança preocupantes, por exemplo, como um passageiro invadiu o sistema de entretenimento de um avião da United e enviou comandos para os motores da aeronave, como pesquisadores conseguiram desligar o motor, acionar o volante e sistemas de freios de um Jeep e do recente ataque do dyndns, realizado através da invasão de 10 milhões de dispositivos como câmeras e outros dispositivos de segurança.

O palestrante ainda aponta que nós, como engenheiros, devemos nos preocupar com o impacto que as nossas tecnologias terão na sociedade, principalmente em relação a qualidade de vida da população. Como exemplo, ele apresenta uma imagem de uma cafeteria totalmente automatizada, tornando todo o processo desumanizado. Ele faz uma importante reflexão da diferença entre tecnologias que automatizam 100% da produção, de tecnologias que tornam a população mais produtiva.

Nós estamos criando tecnologia que levam as pessoas a serem consumidores ao invés de usuários e geradores de valor. Isto terá um impacto direto na economia e talvez este processo nos desumanize, pois perderemos as interações humanas.

Ele ainda afirma que o sentimento geral da comunidade de software é que pouco pode ser feito em relação a este assunto. Contudo, segundo Steven, nós devemos parar e refletir nos porquês desta realidade.

Para entender os porquês desta realidade, ele apresenta o conceito da TED talk de Simon Sinek "How great leaders inspire action" (Como grandes líderes inspiram ação), que segundo Steven, entender o porquê das ações que você realiza é o que causa impacto na forma que você lidera um time e até nas suas atitudes.

Ele afirma que a grande maioria das pessoas entende o que está sendo feito, provavelmente sabe como está fazendo, mas possui apenas uma vaga ideia do porquê das iniciativas.

Isto é ainda mais claro no mundo corporativo, pois grande parte das empresas apenas se preocupa com o que está sendo desenvolvido (um dispositivo com uma API inteligente) e fala sobre como está fazendo (alta escalabilidade, UX, API), mas normalmente esquece de comunicar o porquê do desenvolvimento.

E Steven afirma que isto é um risco, pois ele acredita que todo criador de um produto ou tecnologia no fundo sabe o porquê que criou a sua empresa, mas falha na comunicação ao cliente e sua equipe. Ele afirma que entender e comunicar claramente o porquê por trás da sua tecnologia ou produto é um fator crucial ao sucesso da sua iniciativa.

E isto ainda é mais claro em iniciativas de IoT, "programmable world" e smart devices (dispositivos inteligentes). Ele afirma que raramente explicamos o porquê de nossas iniciativas para a população, que ainda assim consome nossos produtos sem saber ao certo a razão da existência destas tecnologias.

Os riscos desta falha de comunicação fica claro quando temos que justificar ao grande público eventuais falhas nestes dispositivos, como exemplo quando ocorre um acidente em um carro autônomo. Será que se a maioria da população conhecesse os porquês do desenvolvimento destas tecnologias, não facilitaria a aceitação de eventualidades?

Steven, segue tentando entender o porquê queremos tornar o mundo mais programável. Ele elenca quatro justificativas:

  • Melhorar o futuro da humanidade;
  • Melhorar a vida humana;
  • Melhoria sócio-econômica;
  • Criar pequenas melhorias diárias;

E ele convida o público (e o leitor), a pensar no seu próprio porquê.

Uma vez definido o seu porquê (Why), Steven afirma que é o momento de definir o seu "o que"(What) e o seu "como" (How). Ele fala que não pode ajudar o público com o "o que", pois depende do domínio de trabalho de cada um, mas pode compartilhar o que ele acredita serem os princípios para o "How" (como).

O princípio para o "como" devemos desenvolver nossos produtos, deve inevitavelmente passar por algum tipo de código ético. Fundamentalmente, todas as profissões que afetam a vida das pessoas possuem um código de ética, como exemplo o direito, medicina e educação possuem um código de ética rigoroso e caso um profissional viole este código, ele é excluído da profissão.

Mas isto não ocorre para o desenvolvimento de software, o que é até positivo em alguns cenários. Contudo, Steven acredita que os profissionais devem se "auto regular", pois as tecnologias cada vez mais fazem parte da vida das pessoas e as afeta diretamente e profundamente.

Além disto, é apresentado quatro pilares para o mundo programável Continuous Improvement (melhoria contínua), Graceful Degradation (capacidade de um sistema de se manter funcionando com funcionalidades reduzidas mesmo em situações adversas), Radical Distribution (distribuição em larga escala) e Componentes (não somente soluções).

Continuous Improvement é muito importante no mundo das APIs. Suas APIs não devem quebrar de uma versão para outra do seu sistema. Se isto for necessário, deve se realizar todo um planejando e utilizar alguma estratégia, por exemplo versionamento. Ele ilustra este conceito falando sobre a API do Stribe, onde cada cliente é atrelado a uma versão específica da plataforma e só faz o upgrade se o cliente decidir.

Em relação ao Graceful Degradation, Steven afirma que APIs ainda possuem um contrato rígido. Como exemplo, se sua API consome quatro serviços de backend e somente um deles falha, devemos retornar um erro 500 ou os dados parciais para o cliente? Segundo Steven, devemos retornar dados parciais de forma sistemática e como exemplo, ele cita o exemplo do Netflix e o chaos monkey.

Steven também afirma que devemos distribuir nossos sistemas em microservices e devemos ter em mente a distribuição de times, data centers e qualquer tipo de recurso essencial aos nossos sistemas. Neste cenário o projeto de uma boa API é fundamental para o sucesso deste modelo arquitetural.

O quarto pilar para o mundo programável é que devemos construir componentes e não somente soluções fechadas. Embora seja natural disponibilizarmos software empacotado para uma melhor experiência para nossos clientes finais, no mundo de IoT isto impossibilita que este usuário crie as suas próprias soluções através da composição de componentes.

Entregar ao usuário final uma solução fechada e pronta, exclui o cliente do desenvolvimento da solução e ignora as particularidades de cada cliente, aplicando uma solução genérica a um problema específico.

Segundo Steven, APIs e IoT devem se preocupar em serem o mais abertas e componentizáveis possíveis, tornando simples a conexão com outros dispositivos, se adaptando a realidade do cliente e aumentando o valor da solução final. O desenvolvedor de um dispositivo de IoT deve se preocupar em participar da solução final de seu cliente e não ver seu cliente como consumidor de uma solução fechada.

Steven conclui afirmando que é importante que cada desenvolvedor de IoT e APIs tenha coragem e tenha orgulho das soluções que desenvolve. Ele afirma que estes desenvolvedores são pioneiros nesta área e devem tomar para si a responsabilidade do software que constroem.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT