Tens sorte que estou com paciência para responder, porque precisas mesmo é de estudar um pouco os recursos que existem sobre a cloud. Há muita coisa disponível na net, mas precisas de largar alguns preconceitos e estar interessado em aprender.
A programação tem custos. O teu tempo (que a empresa paga), a manutenção daquilo que fizeres (que consome tempo, que a empresa paga), os bugs que vais criar, porque ninguém é perfeito (que consomem tempo, que a empresa paga, e que podem causar estragos, que a empresa paga).
O teu trabalho não é programar, é resolver problemas. Às vezes, isso significa que tens de programar. Muitas vezes não. Aliás, a seguinte máxima é capaz de te surpreender:
O teu chefe não quer saber se tu programaste muito ou pouco. Quer saber se lhe conseguiste resolver um problema mais ou menos depressa. É por isso que usamos bibliotecas: para não reinventar a roda.
Quanto à parte da humildade: fizeste bem em fazer a pergunta, mas tens de estar preparado para não receberes a resposta que esperavas. Não te fica bem pôr em causa as competências dos teus colegas de fórum só porque não concordas com eles, especialmente se considerares que eles perderam algum do seu tempo para te tentar ajudar.
Já todos nós passámos por isso, e é por isso que conseguimos perceber facilmente que não estás nesta indústria há muito tempo.
Eu se fosse a ti não fazia apostas dessas. Estás a assumir que a próxima pessoa que pegar no teu código é igual ou mais inteligente que tu. Nem sempre isso acontece
No início de carreira somos todos inocentes, todos iguais. O nosso código é sempre muito bom, o do gajo anterior é sempre pior que o nosso, o próximo gajo vai sempre perceber o que nós fizemos, e reescrever o que já existe é sempre mais divertido do que mantê-lo.
Quando daqui a alguns meses voltares a olhar para o código que escreveres hoje, das duas uma: ou vais concluir que o podias ter feito melhor, ou vais concluir que mais valia teres usado outra coisa para resolver o problema.
Continuas a separar o mundo em "
ser competente e escrever o próprio código" vs "
não ser competente ("só sei dar cliques no rato tou feito ao bife") e usar ferramentas externas".
Não foste tu a criar o sistema operativo que estás a usar.
Não foste tu a criar o IDE que usas para programar.
Não foste tu a criar o compilador que usas para compilar.
Não foste tu a criar a standard library que usas nos teus programas - programaste o protocolo HTTP à mão, ou estás a usar as APIs que o C# já te oferece?
Porque é que traças a linha aqui, e de repente parece-te mal continuar a construir por cima do trabalho que outras pessoas já fizeram? Nós chamamos a isso de "
Not Invented Here syndrome", e não te iludas, isso é praticamente sempre uma abordagem errada.
Recomendo que leias a história da AWS (e do cloud computing em geral), porque não é num post que te consigo explicar isso.
Se o Azure existisse na altura em que a Amazon precisava de escalar, se calhar a Amazon até teria usado Azure e não se tinha metido em aventuras. Talvez.
No entanto, naquela altura não existia nada do género. Portanto, a Amazon construiu o seu próprio serviço de infrastructure-as-a-service (IaaS), a Amazon Web Services (AWS). Não só suportou a sua própria infraestrutura, como conseguiu monetizar essa infraestrutura como um serviço. Se não estou em erro, foi o primeiro serviço desse género, e os outros nasceram para lhe fazer frente.
Se quiseres criar um concorrente à AWS ou ao Azure, sim, justifica-se construíres os teus datacenters, comprares os teus servidores, etc. Mas prepara-te, porque o euromilhões só te paga uma parte da entrada.
Na maioria dos casos, tu não estás a construir um concorrente à AWS. Apenas precisas de espaço de armazenamento, bases de dados, e servidores aplicacionais. Tanto faz se usas os teus servidores, ou se alugas servidores a um fornecedor.
Podes nem precisar de ir para uma AWS. Se só precisares de uma plataforma, o
Heroku pode ser suficiente. Não suporta C#, mas suporta Docker, pelo que podes fazer deploy disso com o Mono.
Não consegues ver a ironia naquilo que escreves?
A tua empresa tinha de pagar pela manutenção de servidores
porque tinha servidores que precisavam de ser mantidos. Esse é o tipo de dinheiro que poupas quando usas serviços na cloud. E se mesmo assim achas que a cloud é assim tão cara, lembra-te que essa manutenção não inclui a substituição de peças. Esses servidores têm um tempo de vida limitado e têm de ser trocados de tempos a tempos.
500€ por dia é um valor perfeitamente normal em trabalho de consultoria externa. Se a tua empresa preferisse pagar salários decentes aos funcionários e fosse para a cloud, se calhar ia gastar o mesmo dinheiro, mas tinha um serviço melhor e sem precisar de vos escravizar. São escolhas que se fazem. E, já agora, quando a equipa é muito pequena, é muito mais fácil manter uma infraestrutura na cloud do que num datacenter. Acredita no que te digo - já passei pelas duas situações. Adivinha em qual delas é que eu recebia SMSs de madrugada?
Eu nunca usei Mulesoft. Para mim, o Mulesoft é só mais uma ferramenta que as empresas usam e que faz coisas que as empresas não querem ter de manter. Que coisas são essas, não sei, nem me interessa, porque na prática vai dar ao mesmo: as empresas precisam de resolver problemas, e essa ferramenta existe para resolver um desses problemas.
Quando pesquiso por "Why Mulesoft", encontro
esta página. Integrações não são triviais de fazer. Parece que é isso que o Mulesoft faz, e portanto parece-me ser isso que estás a propôr-te a fazer com uma REST API escrita em C#.
Se a tua empresa apenas usa
uma das integrações que o Mulesoft fornece, se calhar até não se justifica pagar por isso e podes ter razão em querer integrar directamente com a plataforma final.
Mas se usar mais de uma, o valor que o Mulesoft te acrescenta é teres de lidar apenas com um fornecedor (o Mulesoft), que de preferência procura manter uma interface estável para vocês, em vez de teres de lidar com várias outras APIs e garantir a sua manutenção individualmente. Pesquisei por um tipo de problema que poderias encontrar se escrevesses a tua própria integração, e
encontrei isto para te servir de exemplo.
Mas mais uma vez, a decisão de negócio não é tua, é do teu chefe. Ele conhece melhor do que tu ou eu as necessidades do negócio.
Tal como tudo na vida, a reputação é importante. É mais provável uma empresa de vão-de-escada desaparecer do que a Amazon, a Microsoft, a Google, ou a IBM. Também cheguei a considerar há uns anos (2012/2013) pagar por um serviço chamado
Bitcasa. Ainda bem que não o fiz.
Vê também o outro lado da moeda: quantas pessoas não perderam as suas bitcoins porque perderam os discos, ou os discos onde as chaves estavam guardadas avariaram e a informação deixou de ser recuperável?
Também te consigo arranjar exemplos disso.
Sim, compara-se, mas depende de vários factores.
Se a tua ligação à Internet é lenta, é claro que vai ser sempre mau, mesmo que a rede interna seja rápida.
Se tiveres uma ligação minimamente estável, não deves dar muito pela diferença.
Se tens um servidor aplicacional no escritório, mas a base de dados está noutro país, e o servidor aplicacional faz vários pedidos à base de dados para responder a um único pedido, é péssimo.
Se tens uma ligação à net estável, e tens o servidor aplicacional
e a base de dados noutro país (digamos, a Alemanha), os ~20ms de latência extra mal se vão notar. Em breve vais começar a ver pessoas a usar o
Starlink para se ligarem à Internet por satélite. A latência mínima do serviço é maior do que isso.
Portanto sim, compara-se, e não vais sentir a lentidão que descreves. Precisas é de arquitectar isso como deve ser.
Sim, tens razão. Mas...
Quantos discos tiveste de comprar para fazer isso, e quanto custaram?
Quantas máquinas (servidores ou NAS) tiveste de comprar para ligar esses discos (que suponho que têm de estar acessíveis)?
Justifica-se gastar as portas de rede para ligar esse NAS? Vou assumir que já tens switch para isso, mas se não tiveres portas livres é mais uma coisa que tens de comprar.
Quanto tempo perdeste a configurar o RAID da primeira vez?
Quanto tempo perdeste a manter o RAID (i.e. confirmar que estás a fazer background scrubbings periódicos, e ver os logs deles e do SMART)? Estás a pensar monitorizar a saúde e ocupação dele?
Já alguma vez tiveste de lidar com problemas num RAID? Seja porque o disco deu timeout uma vez, ou porque o disco falhou e precisaste de ir buscar um spare (para não falar da desgraça que é se só tens um spare e ele afinal veio DoA e tens de comprar outro - antes que o resto do RAID falhe).
Também vale a pena referir o momento em que o RAID está a fazer rebuild e cruzas os dedos durante um ou dois dias para que não falhe um segundo disco durante o rebuild.
Podes ainda ter problemas de performance no storage (por exemplo, porque usaste discos rígidos e RAID5 quando até precisavas de optimizar IOPS), e começas a precisar de pessoal muito mais especializado para te ajudar a resolvê-los. Costuma passar por comprares mais hardware e pagares 500€/dia pela consultoria.
Finalmente, caso faças backups off-line e/ou off-site, estás a pensar testar os discos de tempos a tempos, comparar a informação dos discos com o esperado, e trocá-los à medida que ficam velhos? Não te esqueças:
Um plano de Disaster Recovery é complicado, porque tem de ter muito mais do que estas situações em conta.
Aqui até estou de acordo. Algumas empresas são melhores que outras nisso. A AWS, por exemplo, raramente admite quando tem problemas, só o fazendo
quando são graves (e que eu saiba nem houve perda de dados neste caso). Mas as empresas levam os SLAs muito a sério, e em casos de falha mais graves, normalmente há consequências.
A procura é maior do que a oferta. Há muito emprego, e há muitas empresas a pagar bem. Mais do que pessoas qualificadas.
Não precisas de criar mais emprego, ele já existe. E em infraestruturas, a falta de pessoal qualificado é extraordinária.
Eu pessoalmente tenho dificuldades em aceitar a analogia das pizzas, precisamente porque no mundo real não tens a "elasticidade" que tens na cloud a não ser que tenhas "pseudo-restaurantes" que conseguem fazer qualquer receita on-demand.
No mundo real precisas de capacidade extra (e estás sempre a pagar por ela). A vantagem da cloud é que podes apenas escalar quando precisas, e desligar quando deixas de precisar, pagando apenas o que usas.
Ou seja, se tens um serviço que só é usado ao fim de semana (por exemplo, servidores de jogos para malta que trabalha durante a semana), podes não pagar nada (ou apenas 1 servidor) durante a semana, e ao fim de semana levantas 100 servidores. É muito melhor do que comprares 100 servidores e só os usares dois dias por semana. Mas é óbvio que isto só funciona se o teu serviço for escalável - não te serve de nada levantares 100 servidores se depois só és capaz de usar um de cada vez.
Quando fazes as coisas bem, não "dás cliques". Existe uma coisa chamada
Infrastructure as Code, e se achas que isto é fácil, experimenta.
Se calhar até és capaz de gostar: em vez de programares um site, o teu programa arranca ou desliga máquinas virtuais que correm sites. É giro.
Se alguma vez quiseres experimentar arrancar máquinas virtuais na AWS através de código, consulta os tutoriais do
Terraform. Até podes usar o Free Tier da AWS, e não pagas nada para experimentar. O Azure oferece uma versão bastardizada disso, mas também funciona. Idem para o GCP e o IBM Cloud.
- Convém perceberes se é de facto "um dinheirão". Provavelmente sai mais barato à empresa do que contratar as pessoas.
- Convém perceberes que às vezes é melhor comprares uma solução feita hoje do que esperares que uma equipa de 5 pessoas que acabaste de contratar demore 6 meses a desenvolver a funcionalidade que precisas (com potencial para atrasos ou simplesmente não acontecer). Entretanto já o cliente se foi embora, ou o teu concorrente passou-te à frente.
- O Windows, Office, etc, na minha opinião, são mais caros do que valem, especialmente tendo em conta o que existe de gratuito. E não tens suporte durante anos - só se pagares, portanto voltamos ao mesmo.
Nota que eu não te estou a tentar convencer que a cloud é a melhor cena de sempre. Há vantagens e desvantagens em teres os teus servidores e em ires para cloud providers.
Precisas é de te libertar dos preconceitos que tens, porque são muito limitantes naquilo que podes vir a fazer no futuro, e a tendência está a ser as empresas migrarem para cloud providers, sendo cada vez mais raras aquelas com datacenter próprio (e a maioria nem lhe pode chamar de datacenter, quando é pouco mais que um bastidor numa sala mal preparada para ele). A cloud também costuma pagar melhores salários
Para terminar ainda dentro do tópico: as empresas que conseguem avançar mais depressa costumam ser aquelas que subcontratam praticamente tudo o que podem. Gastam mais dinheiro a curto prazo (mas não muito curto - servidores são
caros), mas podem fazer muito mais, com menos compromissos, e fazem mais dinheiro a longo prazo.
..