Cansado de pagar caro com o shinyapps.io? Nada mais de 'vendor lock-in'

foto de capa: "Free as in Reflection" by cogdogblog is licensed under CC BY 2.0

BYOD... "Bring Your Own Docker"

Com US$: 39 por mês -- aproximadamente R$: 209.39 segundo o Google enquanto esta matéria é escrita -- você pode ter:

APENAS 500 horas de serviço por mês -- quase 21 dias se você tiver apenas UMA APLICAÇÃO rodando 24h, 7 dias por semana
"Premium" E-MAIL suporte -- ou seja, nada de um chat no site deles caso sua aplicação fique fora do ar sábado às 7h AM
Vendor lock-in -- o que basicamente significa que você tem dificuldade de sair do sistema deles para outras soluções

"Snow day" by indigo_veil is licensed under CC BY-NC-ND 2.0

Antes de continuar, se você se sente confortável com tudo isto e não se sente "ultrajado" por tais termos, por favor, este texto não é para você. Alguns pontos que quero mostrar são os seguintes:

A plataforma é cara para o que entrega
Caso amanhã ou depois o sistema tenha que rodar na infra de um cliente, provavelmente terá dores de cabeça para fazer funcionar
Falta de um "analytics" avançado do sistema rodando

E só um lembrete: não conheço as pessoas que trabalham na empresa nem tenho nada contra elas e/ou a empresa em si -- não dúvido que seja um lugar incrível para seus clientes e talvez até ótimo para os funcionários --; a ideia deste texto é evitar com que você gaste dinheiro desnecessariamente, seja para fazer ele rodar quando a aplicação crescer ou até mesmo com o port dela para rodar em outro tipo de infra depois.

Assim como você pode usar muitas vezes uma chave de fenda no lugar de uma Philips, tudo bem, isto funciona... "Mas você deveria fazer isso?" R: em ambos os casos uma hora vai espanar.

Como esta palestra mostra belamente, muitos problemas ao usar o framework em si são """crônicos""" dele e não de onde você roda sua aplicação.

Se você só tem que rodar uma demo de alguns dias ou até mesmo um projeto de faculdade/pesquisa, por favor vá em frente e use sim o shinyapps (SA); do contrário, aproveite o texto.

Os tiers

"On the Level" by aaronHwarren is licensed under CC BY-ND 2.0

I. Caso o seu caso de uso seja realmente um 'hobbyista', a galera do SA possue uma oferta gratuita que te permite subir até cinco aplicações durante 25h por mês.

II. Caso as 25h não sejam o suficiente, você pode ter até 100h e 25 aplicações por US$: 9,00 --aproxiamadamente R$: 48.34 -- por mês

III. A opção citada no começo do texto te permite um número ilimitado de aplicações. Mesmo que se você rodar as 25 limitantes da úlima opção, com as 500h disponíveis, você teria menos de 9h por mês para cada aplicação ficar online

O plano Basic que é o citado no terceiro item é o que aparece em destaque na página do SA, mas ainda há dois planos "superiores" à ele.

IV. Por US$: 99 -- aproximadamente R$: 531.61 -- por mês o sistema sobe para 2 000h, o que são aproximadamente 3 dias apenas caso ainda tenha as 25 aplicações rodando por mês

V. E por US$: 299 -- aproximadamente R$: 1,605.56 -- por mês o sistema sobe para 10 000h, o que seria "meio" mês para as mesmas 25 aplicações

Um ponto importante, principalmente para quem vai colocar uma aplicação em produção, é que mesmo nas duas últimas opções o suporte ainda é por e-mail.

Seguindo a ideia de "The Good, The Bad and The Ugly":

Good: I
Bad: II
Ugly: III, IV, V

"Shared Loneliness" by Vassilena is licensed under CC BY-NC-SA 2.0

O modelo de serviço oferecido pelo SA muitas vezes lembra o modelo de "pulsos" a mais que você pagava por uso a excedente de internet no começo dos anos 2000; no final do mês você sabe -- tem certeza -- que vai acabar pagando o "extra" atrelado ao seu pacote.

A competição

Ela é inexistente

O sistema de host ofertado pelo shinyapps é "o melhor" não por mérito próprio, mas sim por falta de competição para este mercado. A ideia do pessoal do SA é um sistema "serverless" onde você só manda o código e eles fazem ele rodar. Este modelo de serviço fez e faz várias empresas crescerem no mercado assim como:

Todavia, essas empresas cresceram pensando em rodar serviços Java, Node.js, Ruby, Python e etc. Em R +Shiny basicamente só a galera do SA pega o mercado como um todo.

Docker

"Containers" by s_volenszki is licensed under CC BY-NC 2.0

Caso você parta para uma abordagem baseada em Docker, poderá ter uma tecnologia que até 2022 será a coluna vertebral de mais de 75% dos serviços em produção; maior a demanda, maior a oferta, menores preços. Alguns das grandes empresas no cenário são:

Agora, com relação as vantagens de se escolher o Docker:

A máquina do desenlvovedor, nuvem e a infra do cliente falam a mesma língua -- nada mais de "mas na minha máquina roda"
Menos consumo de recursos, menos consumo de energia, menos hardware potente... Em suma: menos gastos e, em alguns casos, por 1/3 do preço atual
Facilidade de atualizar a aplicação sem quebrar o host e vice-versa
Ao mesmo tempo que empodera o desenlvovedor, flexibliza a vida do time da infra que for rodar o sistema porque conseguem verificar, validar e executar tudo com maior nível de segurança, disponibilidade e redundância
Caso tenha que portar para outros ambientes de produção como Virtual Machines (VMs) ou até mesmo o SA, vai conseguir com facilidade pois o Docker roda baseado no Dockerfile -- um arquivo de texto com a listagem de dependências de sistema
etc

Estes provedores permitem que você tem uma granularidade, em nível de infra, muito maior e possa sim fazer análise delas mais intensas com o Kubernetes, mesmo que você só envie um Dockerfile ou um docker-compose.yml para eles, muito provavelmente eles estarão rodando um orquestrador como o citado para gerenciar todos os serviços de todos os clientes.

Kubernetes

Não é 100% do mercado, mas é a tendência

"I Remember When the Future was Unevenly Distributed" by cogdogblog is licensed under CC BY 2.0

Se você subir na nuvem ou até mesmo rodar na infra local, Kubernetes é normalmente o orquestrador de containers utilzado para poder gerir os recursos compartilhados entre as máquinas. Caso você esteja no Windows ou Mac, ele já vem com o seu Docker Desktop.

TODAVIA... Não desenhe sua aplicação pensando do zero como um "serviço que deva ou que vá rodar em Kubernetes", comento isso porque as dores de cabeça que fazer querer rodar algo no Kubernetes que não precisa ou que não """deveria""" rodar nele, pode trazer mais dores de cabeça do que respostas.

Caso queria "brincar" com Kubernetes em casa, recomendo começar com um Rancher e, coincidentemente, todos os meus textos postados aqui até então te permitem fazer isso e na ordem que foram postados. A vantagem do Rancher é que seja on cloud e/ou on premise, você consegue de gerenciar de maneira simples os seus clusters.

Baixa performance

Como já citado anteriormente, o shiny em si não é o framework potente como um express pro Node.js, HUGO pro Go, Django para o Python e etc... Mas esta não é a ideia dele, nunca foi e, pelo jeito, nunca vai ser; a ideia é permitir com que pessoas de um alto conhecimento técnico de outras áreas sem ser Ciências da Computação voltada para web como Química, Física, Engenharia e etc, consigam fazer um sistema web completo.

Caso você já tenha um projeto em shiny, rode na sua máquina -- idependente de Docker ou não -- e abra um navegador baseado em Chromium para poder ver o output do Lighthouse:

Este é o output do projeto R + Shiny + Mongo + Docker, que basicamente é um "hello, world!" dos projetos com esta stack e, mesmo assim, a performance foi baixa.

Este ponto pode não ser importante para ti, mas para muitas pessoas que vão ter que rodar tais sitemas em uma rede 3G pode ser um grande problema.

Flexibilidade

Independentemente de onde escolha rodar sua aplicação, caso a demanda aumente, sempre se lembre que normalmente há dois tipos de se aumentar a oferta para um sistema:

Scale up -- dê mais poder a cada instância
Scale out -- instancie mais recursos

Como sempre ressaltado pelo excelente Elemar Jr nos podcasts, vídeos e textos dele, a ideia de se utilizar a palavra "elasticidade" para representar a ideia de "escala" de uma aplicação é importante; isto porque muita pessoas pensam em escala como sendo algo apenas com um coeficiente maior que um, ou seja, como se algo apenas cresce. A palavra elasticidade neste contexto é importante para poder representar a ideia de uma aplicação que cresce também pode ser reduzida, ela é elástica.

Qualquer uma das duas abordagens são claras para quem utiliza um sistema cloud native, se você utilza apenas um container na nuvem ou se tem o seu próprio cluster Kubernetes on premise.

Onde o diabo mora?

Nos detalhes

"Crosswalk devil" by Arlette is licensed under CC BY-NC-SA 2.0

Por se tratar de um serviço com pagamento em dólar apenas eu posso infereir com certo nível de segurança que o sistema não possuí servidores no País, por isso utilizei três empresas de exemplo que possuem servidores por aqui pelos seguintes pontos:

Países
Leis
Impostos
Suporte
Eventos
etc

Voltando, se você chegou até está parte do texto e não é uma empresa, alguém que leva fazer Shiny além para aprender como rodar Shiny + Docker -- seja por prazer ou semi-profissionalmente --, não são estes pontos citados que vão te fazer sentir na pele de quem por motivos principalmente empresariais pensariam o seguinte ao ler cada um desses tópicos:

Países: "sou uma empresa local mas preciso fazer deploy para um cliente na Índia. Como vai ficar a latência se eu subir em um servidor fora de lá?..."
Leis: "devo me preocupar com LGPD/GDPR?..."
Impostos: "vou pagar os impostos do cartão de crédito apenas? Meu cliente que paga eles? Como fica?..."
Suporte: "Meu time de desenvolvedores não fala inglês, como meu ficaria se precisararmos de ajuda?..."
Eventos: "Shiny eu sei que tem uma comunidade forte. Mas existe documentação boa para o shinyapp.io? E em português?..."
etc: "quais mais coisas que ele não falou que são importantes?..."

"Não há almoço de graça"

Em suma, mais do que chegar em uma "conclusão" per se, mas sim levantar pontos como:

Existem outras possibilidades
Há como se chegar ao mesmo resultado desenhado de formas diferentes os caminhos
Levantar o aviso que com a oferta de Docker subindo, você pode salvar gastos
Evitar processos custosos como ports de aplicações
etc

Mesmo se tudo levantado não fizer sentido para ti, tudo bem, sua aplicação pode ser que não se encaixe nos moldes apresentados, só isso.

"Scales" by Hugo! is licensed under CC BY-NC-SA 2.0

Apêndice

Como sempre, procuro ser breve nos textos, mas gostaria de levantar outros pontos a serem considerados:

Não há um Service Level Agreement (SLA) facilmente encontrado na página de preços do SA, os outros serviços normalmente deixavam claro isto nela ou em outra parte do site
Não quebrei de propósito os preços de nuvem da Azure, do GCP e AWS porque muitas vezes essas empresas ofertam planos personalizados para cada cliente, ainda mais se você já as utilize atualmente -- um Office 365 ou um G Suite
ARM suporte? RISC-V suporte? -- só querendo ser babaca aqui mesmo, mas são duas coisas que eu me preocupo nas próximas duas décadas
APIs como as do Google e Azure de análise de dados, mapas, compressão de arquivos e etc
Caso queria ir a fundo em subir Shiny + Docker + Kubernetes:

I. Configurando Rancher em um ARM

II. Como distribuir código para rodar em diversas arquiteturas? R: Docker buildx

III. Nuvem de terceiros quando você pode ter a sua própria em casa com o clique de um botão?

IV. Análise de dados + Site + Banco de Dados? Tudo no isso seu PC e sem precisar instalar o R, Shiny e o Mongo
Vou colocar ums scripts para subir a demo de R + Shiny + Mongo + Docker no diferentes cloud providers citados. Se eu não fizer a tempo ou você quiser que eu faça testes em algum citado, fique a vontade para abrir um Pull Request (PR) pedindo ou fique a vontade para você mesmo subir ele :)
Não foi citado porque ainda pretendo escrever sobr Integração Contínua e Entrega Contínua com a stack RSMD mais para frente. Este é um ponto importante ainda mais por multi-stage buildings