.NET Core: O Futuro da Plataforma de Desenvolvimento da Microsoft

Prévia do material em texto

Por que o .NET Core e o futuro da 
plataforma de desenvolvimento da 
Microsoft 
Tim Anderson 
Tradução: José Cassiano Grassi Gunji 
Texto original: 
https://www.theregister.co.uk/2015/11/20/microsoft_net_core_developm
ent_platform_fork/?page=1 
 
A Microsoft está apostando em uma variante de código aberto do Framework .NET 
para atrair clientes. 
Análise. Faz apenas um ano desde que a Microsoft anunciou a abertura do código do 
.NET Core, uma variante multiplataforma de seu Framework .NET para Windows. 
O Framework .NET não está desaparecendo, mas está ficando claro que a companhia 
está focando no .NET Core como o futuro de sua plataforma de desenvolvimento. O 
Framework .NET da Microsoft já possui uma longa história, tendo sido anunciada 
primeiramente na TechEd da Europa em 2000. 
Naquele momento, aquilo foi um movimento defensivo contra o Java da Sun, que 
ameaçava o Windows graças às suas capacidades multiplataforma combinadas com uma 
linguagem de programação que era mais fácil e produtiva do que o C ou o C++. 
O C# da Microsoft, a principal linguagem .NET, não se distanciou do Java, mas provou 
ser popular para o desenvolvimento de aplicativos empresariais. 
A companhia também evoluiu a linguagem mais rapidamente do que a Sun foi capaz 
com o Java, mostrando o que um time interno e competente pode conseguir frente a um 
processo orientado à comunidade que é mais burocrático. 
O ASP.NET, criado conjuntamente por Scott Guthrie da Microsoft, foi um grande 
avanço sobre o velho ASP (Active Server Pages) como um framework para aplicativos web. 
Por que, então, a Microsoft resolveu criar uma variante do Framework .NET, com 
todos os riscos e confusão que isso significa, e embarcar no código aberto e na 
multiplataforma? Há várias razões. 
https://www.theregister.co.uk/2015/11/20/microsoft_net_core_development_platform_fork/?page=1
https://www.theregister.co.uk/2015/11/20/microsoft_net_core_development_platform_fork/?page=1
A primeira é que o Framework .NET era monolítico e suas dependências internas 
muito complicadas para que a Microsoft desse prosseguimento a certos projetos. Em 
particular, a companhia queria compilar o .NET para código realmente nativo, sem precisar de 
um runtime instalado. 
Os benefícios seriam um carregamento mais rápido, melhor desempenho em alguns 
cenários, mas sobre tudo, uma implantação bem mais limpa e simples. Se os aplicativos 
dependem de um runtime de um sistema operacional, então há sempre o risco de que uma 
atualização do sistema operacional pode quebrar o aplicativo. 
O fardo da compatibilidade também tende a atrasar o desenvolvimento de um 
runtime. 
A solução da Microsoft foi refatorar o Framework .NET em um sistema novo e 
modular, mantendo ainda a versão existente para garantir a compatibilidade. Esta versão nova 
é o .NET Core. 
Ela foi inicialmente usada para aplicativos da loja do Windows 8, que é a razão para 
que o projeto .NET Native inicialmente visasse apenas aplicativos da loja e agora tenha 
evoluído na Universal Windows Platform (UWP) para o Windows 10. 
No evento Connect em Nova Iorque nesta semana [20 a 26 de novembro de 2015], a 
Microsoft exibiu o próximo estágio do .NET Native: direcionando o .NET Core para Linux, Mac e 
Windows. Houve uma demonstração de código compilado .NET Core para código nativo 
Ubuntu, embora este recurso ainda não esteja presente na versão pública. 
.NET Core – Otimizado para DevOps? 
Quer seja usado ou não o .NET Native, liberar os aplicativos .NET de um runtime de 
sistema operacional é uma estratégia que se adapta melhor às tendências de desenvolvimento 
de hoje, para aplicativos organizados em contêineres e microsserviços, aplicativos distribuídos 
construídos de componentes que podem ser mantidos e atualizados separadamente. 
A versão Nano Server “pelada” do Windows Server roda o .NET Core mas não o 
Framework .NET; mais uma vez, isso é tudo uma parte de um movimento para uma 
organização em contêineres e DevOps, implantação contínua e automatizada de aplicativos. 
Note que, exceto aplicativos UWP, o .NET Core é para aplicativos servidores, não 
para aplicativos desktop com uma GUI. A Microsoft não está portando frameworks como o 
Windows Forms ou o Windows Presentation Foundation para o .NET Core. Entretanto, ele é 
código aberto, então sempre será possível que a comunidade desenvolva frameworks GUI. 
Também há um relacionamento entre o .NET Core e Mono, a implementação 
independente e de código aberto do .NET fundada por Miguel de Icaza em 2001. Mono 
suporta aplicativos desktop. Hoje de Icasa está no corpo de diretores da Fundação .NET, com a 
tarefa de supervisionar o .NET Core. Falando no evento dotnetConf em Março de 2015, de 
Icasa disse que o Mono vai, eventualmente, ser apenas um núcleo runtime, emprestando 
tanto o compilador “Roslyn” e as bibliotecas CoreFX Foundation do .NET Core. 
A próxima questão então: por que multiplataforma e código aberto? A verdade é que 
estas duas questões estão relacionadas. Na dotnetConf, o Gerente de Programa Immo 
Landwerth descreveu código aberto como sendo “a maneira mais sustentável de construir 
uma estrutura multiplataforma”. A razão dada para ser multiplataforma é atrair mais clientes 
para o .NET e construir um ecossistema mais forte, tais como bibliotecas de terceiros e 
aplicativos possam rodar no .NET. 
Há riscos óbvios para a companhia tanto na multiplataforma quanto no código 
aberto. A Microsoft está abrindo mão da propriedade intelectual assim como permitindo que 
clientes rodem aplicativos .NET em sistemas não Windows, sem lucro advindo de licenças. 
Internamente à Microsoft, o caso de negócio para o .NET Core ainda deve se 
estabelecer. Conversando com o pessoal da .NET Foundation eu tenho a impressão de que isso 
tudo se deve ao Azure, a plataforma cloud da Microsoft. Azure suporta Linux assim como 
Windows e, se você implanta no Azure, a Microsoft recebe dinheiro seja lá qual for o sistema 
operacional que você esteja usando. 
Uma parceria com a Red Hat recentemente anunciada não teria sido possível sem 
essa estratégia de código aberto e multiplataforma. O Linux Red Hat Enterprise agora é 
suportado no Azure, e é o “sistema operacional de referência para o .NET Core no Linux”, de 
acordo com o anúncio à imprensa. 
Outro fator é que através do .NET Core, a Microsoft espera estimular o uso de suas 
linguagens, incluindo C# e F#, uma linguagem de programação funcional. Se você codifica 
nestas linguagens, a Microsoft possui uma quantidade enorme de bibliotecas que o atrairão 
para o SharePoint ou o Office 365, por exemplo, permitindo que a companhia lucre com 
licenças por este caminho. 
Quão séria a Microsoft está sobre o .NET Core? 
Quão séria a Microsoft está sobre o .NET Core? Até onde qualquer um pode ver, 
muito séria – é claro, ela estava muito séria sobre o Silverlight alguns anos atrás, que era um 
plugin para browser agora abandonado. Assim, essas coisas podem mudar. Na dotnetConf, o 
Gerente de Programa Richard Lander disse que de 100 a 200 pessoas estão trabalhando no 
.NET Core, excluindo equipes relacionadas, como aqueles para o Visual Studio e o ASP.NET. É 
um “investimento bem notável”, ele disse. 
Outra pista vem de Martin Woodward da Microsoft, Diretor Executivo da .NET 
Foundation e, segundo ele, o único membro de tempo integral presente. Ele se apresentou no 
evento recente Future Decoded em Londres e esteve disponível na feira do evento. Falando 
sobre a relação entre o Framework .NET e o .NET Core, ele disse que “trabalho em novos 
recursos acontece mais no .NET Core hoje em dia”, e este código é então trazido para o 
Framework .NET para dar suporte lá. 
Na Connect, a Microsoft anunciou que o .NET Core está no estágio de Release 
Candidate, completo com uma licença “go-live” de modo que a produção de aplicativos está 
suportada. Você vai encarar? 
Provavelmente ainda não. Um problema com o .NET Core é que ele é um parente“pelado” do Framework .NET completo, e aplicativos existentes provavelmente não irão 
funcionar sem muito trabalho antes. “.NET Core v1 não é usável para muitos apps”, afirmou o 
desenvolvedor Frans Bouma no Twitter. Se o seu aplicativo usa DataTable, por exemplo, que é 
uma parte da biblioteca ADO.NET, ele não irá funcionar no .NET Core, já que ela não foi 
portada. 
A Microsoft portou a sua biblioteca de mapeamento objeto-relacional, o Entity 
Framework para o .NET Core, mas alguns desenvolvedores a evitam por aspectos relacionados 
ao desempenho. O Entity Framework 7 (EF7) RC1 foi lançado recentemente, e em seu anúncio, 
Rowan Miller da Microsoft nota que “devido às mudanças fundamentais no EF7 nós não 
recomendamos tentar mover um aplicativo EF6.x para o EF7 nesta etapa”. 
O EF7 também é mais lento que o EF6 neste release, embora Miller tenha dito que 
ele será mais rápido quando ele for definitivamente lançado. 
Existe um gigantesco ecossistema criado no Framework .NET, e portá-lo para o .NET 
Core não é trivial. Dado que o Framework .NET ainda está aqui, não está claro se os 
desenvolvedores irão desejar investir o tempo e a energia na migração. 
Como é o desempenho do .NET Core contra o Framework .NET em geral? A versão 
oficial é a de que ele é similar, embora como .NET Core é otimizado para processamento 
concorrente, ele deve desempenhar melhor em alguns cenários, assim como o Framework 
.NET maduro irá desempenhar melhor em outros. 
Apesar de alguns aspectos difíceis, essa é uma iniciativa corajosa da Microsoft e uma 
que se encaixa muito bem com DevOps e computação em nuvem. Também está claro que a 
companhia enxerga isso como o futuro da plataforma .NET – note que ela é para o UWP assim 
como para aplicativos de servidores – Assim, aqueles trabalhando com .NET devem ficar 
atentos, mesmo que seja muito cedo para usá-lo para trabalho real.