Oito razões pelas quais o Microsoft Stack ainda é uma escolha viável

A vida era ótima para os desenvolvedores da Microsoft há 10 anos. As empresas ficaram satisfeitas em adotar 100% da Microsoft para seus projetos de desenvolvimento. Com ASP.NET no frontend, .NET middle-tier e SQL Server no backend, as coisas funcionaram muito bem na maior parte. Quando não o fizeram, os desenvolvedores simplesmente aceitaram isso como algo que veio com o território. A Microsoft estava praticamente comandando o show. Então, no final da década passada, o status de gorila de 800 libras da Microsoft começou a se desfazer. Talvez tenha sido devido à introdução do iPhone e a falta da Microsoft para o mobile, ou talvez pela proliferação de projetos de código aberto, mas as coisas mudaram, e hoje essas mesmas empresas precisam ser convencidas de que ir com o Microsoft Stack é uma boa ideia. Este artigo apresenta oito razões a favor de manter a pilha de software da Microsoft.

Razão #1: .NET ainda é um dos melhores

Introduzido há mais de 10 anos, o .NET Framework é rico em recursos e totalmente testado em batalha. Embora fosse comum ter que combinar desenvolvimento nativo com código gerenciado nos primeiros dias do .NET, a grande maioria das tarefas de desenvolvimento é suportada imediatamente hoje. Mesmo empresas como a Oracle lançaram componentes que são 100 por cento de código gerenciado .NET (ou seja, driver gerenciado ODP.NET) para fazer interface com seus produtos. A API .NET é consistente, bem documentada e usada por milhões.

A base de conhecimento disponível via MSDN, StackOverflow e milhares de fóruns e blogs é enorme. Em meus anos de desenvolvimento em .NET, não consigo me lembrar de uma instância em que eu ficasse preso por muito tempo em um bug de estrutura; a cada vez, alguém já havia experimentado, pesquisado e postado uma resposta, nem sempre a resposta que eu esperava, mas ainda assim algo que me fez avançar. Com a próxima versão de 2015, o .NET Core será de código aberto e estará disponível em sistemas não Windows.

Razão #2: ASP.NET evoluiu

Olhando para trás na pilha tradicional da Microsoft da web para o banco de dados de 10 anos atrás, é interessante ver quais partes sobreviveram ao teste do tempo e quais desapareceram. Enquanto o back-end da pilha da Microsoft permaneceu praticamente inalterado (ainda usamos o mesmo conjunto de padrões e componentes, como Dependency Injection, Tasks, Linq, EF ou ADO), o front-end, a peça ASP.NET, viu uma mudança fundamental de “faça do jeito da Microsoft” (ou seja, Web Forms) para “faça do seu jeito e use o ASP.NET como plataforma”. Hoje, o ASP.NET é uma estrutura baseada em MVC com infraestrutura robusta para autenticação, agrupamento e roteamento que se integra a muitas tecnologias que não são da Microsoft, como Bootstrap e AngularJS. Os sites ASP.NET ficam bem em uma ampla variedade de fatores de forma, de telefones a desktops, e seus recursos de API da Web facilitam a exposição de serviços da Web. A estrutura é de código aberto há vários anos, portanto, se você ficar preso em um problema, a fonte estará disponível no GitHub. ASP.NET mudou, e mudou para melhor.

Motivo nº 3: Simplicidade da API da Web e poder do WCF

Minha citação favorita de todos os tempos é de Alan Kay, que disse: “As coisas simples devem ser simples; coisas complexas deveriam ser possíveis”. Quando o Windows Communication Foundation (WCF) foi lançado pela primeira vez em 2006, não era nada simples; comportamentos, endpoints e ligações eram esmagadores. Assim, a Microsoft lançou a API da Web, uma estrutura fácil de usar que torna a exposição de serviços da Web HTTP muito fácil. Com algumas linhas de configuração, sua API se transforma em um serviço web seguro e “padrão do setor”.

Se o seu caso de uso não se encaixa no molde “padrão” e você precisa de controle total sobre como sua API é exposta na rede, você sempre pode recorrer ao WCF. Com uma infinidade de opções de configuração e ganchos, o WCF permite serializar seus dados de forma personalizada, registrar, interceptar, rotear mensagens, usar peer-to-peer e enfileiramento e muito, muito mais. A API da Web, juntamente com o WCF, atende a ambos os princípios da citação de Kay: se você precisar de um serviço da Web simples, você terá concluído em minutos com a API da Web; se seus requisitos de serviço forem complexos, “tudo” será possível com o WCF. Essas duas tecnologias fornecem uma cobertura abrangente de cenários de serviço e vêm pré-empacotadas com a estrutura .NET.

Motivo nº 4: o SQL Server está tão sólido quanto sempre

Por muitos anos, parecia que o maremoto de novas linguagens, estruturas e padrões de desenvolvimento passava pelas camadas frontal e intermediária e poupava o back-end do banco de dados. Afinal, o bom e velho “SELECT” ainda está em uso hoje como há 20 anos. Suponho que isso se deva ao fato de que muitas empresas veem seus dados como o núcleo de seus negócios, e manter a integridade desse núcleo supera em muito a emoção de tentar “algo novo” na camada de banco de dados.

O SQL Server se destaca em sua função principal de guardião de dados com uma infinidade de recursos para transações, integridade referencial, backups, espelhamento e replicação, mas o que diferencia o SQL Server da concorrência é o quão bem ele se integra ao restante da pilha da Microsoft. Para o desenvolvimento rápido, existe o Entity Framework, atualmente na versão 6, que passou da adolescência e cumpre bem sua promessa de agilizar o acesso aos dados. Se você precisar de poder de computação, o .NET Framework é carregado no processo com o SQL Server, o que significa que você pode incorporar código .NET como procedimentos armazenados, funções ou agregados sem sacrificar o desempenho. Combine isso com o fato de que o SQL Server 2014 vem com tabelas na memória, e você pode criar algumas soluções em tempo real bastante espertas que não poderiam ser rápidas o suficiente apenas com SQL e tabelas regulares. Depois de anos na indústria, o SQL Server ainda está no topo da minha lista de RDBMSs.

Razão nº 5: é facilmente testável

Tantas vezes, trabalhando em TI corporativa, vi software se transformando nessas caixas pretas intocáveis ​​porque não havia testes, e ninguém queria mexer no código por medo de “quebrar outra coisa”. Então, trabalhei em sistemas que tinham milhares de testes, e foi uma ótima sensação poder dizer às empresas que “sim, podemos fazer essas mudanças”, anos após o lançamento do software. A pilha da Microsoft foi projetada com a testabilidade em mente. A ASP.NET MVC possui ganchos para injeção de dependência e, na versão 5, a injeção de dependência será incluída na própria estrutura. Na camada intermediária, é uma história semelhante: usamos injeção de dependência para desassociar a implementação da interface, o que nos permite trocar tipos de produção por mocks em tempo de teste. Mesmo no lado do banco de dados, existem SQL Server Data Tools que vêm com modelos para teste na camada de procedimento armazenado. O teste é uma parte inseparável do processo de desenvolvimento de software hoje, e a pilha da Microsoft vem bem equipada para essa nova realidade.

Razão #6: Elaborar o Ecossistema de Apoio

Quando se trata de suporte, é bom ter uma variedade de opções, começando com fóruns da comunidade e terminando com um ser humano real trabalhando no local em seu servidor. O ecossistema online para produtos da Microsoft é um dos maiores do setor. Afinal, a Microsoft foi iniciada por Bill Gates, ele próprio um desenvolvedor de software, que viu a ampla adoção pelos desenvolvedores como a chave para a proliferação dos produtos da Microsoft. Isso significava fornecer a esses desenvolvedores muito e muito suporte.

A Microsoft foi uma das primeiras a incentivar seus funcionários a blogarem sobre a tecnologia em que estavam trabalhando e, embora o resto do setor certamente tenha alcançado, a quantidade e a qualidade dos vídeos instrutivos, guias e artigos vindos diretamente da Microsoft hoje ainda são muito impressionante. Essa camada de conteúdo online de qualidade é complementada por um grande número de ecossistemas de suporte baseados na comunidade, como StackOverflow, que não são tão consistentes quando se trata de qualidade de conteúdo, mas são, no entanto, muito mais úteis do que não.

Por fim, sempre há a opção de pegar o telefone e ligar para o suporte da Microsoft. Eu raramente tinha que usá-lo, mas havia um punhado de emergências de produção quando os desenvolvedores da Microsoft analisavam os dumps principais e salvavam o dia. A variedade de opções de suporte é claramente um fator a favor de seguir a pilha da Microsoft.

Razão nº 7: a Microsoft mantém seus produtos

Alguns anos atrás, escolher o Microsoft Silverlight como front-end para um aplicativo parecia uma escolha válida, mas não é mais o caso. Com a tendência móvel em pleno andamento e as estruturas JavaScript dominando o espaço de front-end, o Silverlight não é mais uma opção viável; no entanto, ainda é suportado pela Microsoft até 2021. A Microsoft mantém suas armas, o que é bom para aqueles de nós que precisam fazer escolhas tecnológicas sem ter uma bola oito mágica para nos dizer qual tendência tecnológica dominará o cenário de software no futuro. A adoção da pilha da Microsoft garante que tempo e dinheiro sejam investidos em tecnologia que será suportada mesmo que caia em desuso no setor.

Razão #8: Guarda-chuva do Visual Studio

Há uma década, eu passava cerca de 50% do meu tempo trabalhando no Visual Studio e cerca de 50% em outras ferramentas. Hoje, a divisão é predominantemente a favor do Visual Studio. A visão da Microsoft de que o Visual Studio seja uma solução completa para hospedar IDEs está se concretizando com muitos produtos da Microsoft e não Microsoft que oferecem algum nível de integração com o Visual Studio. Desde o desenvolvimento de banco de dados com o SQL Server Data Tools até a escrita de aplicativos para iPad e Android com Xamarin, o Visual Studio oferece uma experiência de desenvolvedor familiar com uma interface de usuário consistente. O mesmo pode ser dito sobre trabalhar com o Microsoft Azure, uma plataforma em nuvem que abrange uma variedade de serviços, desde hospedagem de banco de dados até serviços móveis.

O Visual Studio ofuscou as complexidades da infraestrutura de nuvem distribuída, tornando a experiência de desenvolvimento de aplicativos em nuvem consistente com a de desenvolver aplicativos não hospedados na nuvem. Todas as peças parecem se encaixar perfeitamente sob o guarda-chuva do Visual Studio, tornando o processo geral de desenvolvimento muito eficiente.

Microsoft Stack - O melhor dos dois mundos

Hoje, há muito mais opções para escrever software de qualidade em comparação com 10 anos atrás. Isso é certamente uma coisa boa porque a concorrência força grandes players, como Google, Apple, Amazon e Microsoft, a continuar inovando e não se acomodando. Embora a Microsoft tenha sido empurrada do topo da montanha pela evolução tecnológica da última década, a empresa mostrou que está disposta a se adaptar e está sintonizada com as realidades das tendências tecnológicas atuais. O ASP.NET abraçou outras tecnologias e metodologias, muitas delas de código aberto, com os Web Forms originais desaparecendo na história. A estrutura .NET continua a evoluir, rompendo novas fronteiras com bibliotecas para computação multi-threading e de muitos núcleos. Com o lançamento iminente de 2015, o núcleo da estrutura será de código aberto e portátil para plataformas não Windows, o que é um passo na direção de inclusão e transparência.

Essas melhorias bem-vindas vêm de uma empresa que tem processos estabelecidos há muito tempo para liberar software testado, documentado e suportado. A escolha da pilha da Microsoft traz a emoção de trabalhar com linguagens e estruturas modernas, além da estabilidade de ser apoiada por uma gigante de software com décadas de experiência no setor de desenvolvimento. É por isso que estou recomendando a pilha da Microsoft hoje.