October 30, 2015
TABLE OF CONTENTS
In our introduction post, we set the stage for the modern .NET developer. The .NET ecosystem and community have changed drastically over the last 5 years and now places a heavy emphasis on open source software, true portability, and community.
In this post, we are going to explore .NET OSS frameworks and options. Anyone who has researched open source .NET has seen and likely tinkered with the Mono framework. It is an ambitious project creating an open source implementation of the .NET framework, when the framework was still closed source. It has evolved over the years and grown into a mature and robust framework. Mono filled a gap in the .NET ecosystem, that recently Microsoft is working to close. Microsoft announced at the end of last year, .NET Core – a reimagined .NET framework with a focus on high quality performance and portability. Additionally, at the beginning of this year, Microsoft announced that CoreCLR, the runtime execution engine for .NET Core, would now be available on Github.
What does this mean for Mono then? At this point, not much. .NET Core is focused on building the .NET framework across multiple platforms just like Mono, but it is not the full implementation of the .NET framework. Mono currently supports the majority of the desktop and server specification. Microsoft and Mono have collaborated frequently in the past and maintain a healthy organization relationship. Its likely they will continue to support each others efforts.
.NET Core and the CoreCLR are the future for the .NET framework. They power the new open source ASP.NET 5 (or the artist previously known as vNext) and there is currently support across OSX, Windows, and some distributions of Linux. They are even accepting contributions in many different ways, including a bug bounty. Though these core frameworks were not the first Microsoft open source projects, they will drive a lot more. Microsoft is focused, and for the first time, truly, on what developers want. Though, Microsoft has not explicitly stated it, long term this type of open source effort and portability could lead to expanding their profitable product suites into other platforms (think Microsoft SQL running on all those Linux servers).
What does all this progress mean for the modern .NET developer and the organizations they work for? It means that now all the tooling, processes, and patterns we love from other edgier development environments start to enhance our ecosystem.Your businesses and organizations will benefit greatly from these modern practices. It means faster iterations, faster deployments, higher performance code, and more high quality components available for free. It also means more, younger developers will have access to .NET, helping with recruiting efforts. The Microsoft and .NET ecosystem have changed dramatically over the last 5 years. Most of the core frameworks are now available on Github, the community can contribute, and already the toolchains are changing towards more modern development practices. In our next post we will cover these new tools and processes that are available to the modern .NET developer.
Senior Vice President, Capabilities
Eric LaForce is Levvel's Senior Vice President of Capabilities and is a seasoned technology executive focused on driving business value through digital transformation. Currently, Eric runs the services and operations team at Levvel where he coaches teams to perform their best work on complex business and technology problems, drives operational excellence, and encourages a strong organizational culture based on Levvel core values. Eric has experience in building compelling and scalable products, modernizing legacy applications, and driving large-scale digital transformation as a modern technology leader and program manager. He has direct experience in development, building products, solution engineering, program planning, operations, sales, building businesses, and transforming culture.
At the end of lunch with a mentee, I used the items on our table to express the fundamental concepts of Kubernetes. Sometime after explaining the purpose of the Kubernetes scheduler, she asked a question I spent the next several weeks thinking about.
API design is crucial, giving structure to application interaction. Given cross-functional teams and applications, development time is reduced with a clear, intuitive way to access data. API development often follows two approaches: REST and GraphQL.
As of June 2018, the state of California passed a new privacy law that could lead to more consequences for US-based companies than the European Union’s General Data Protection Regulation (GDPR). Here's what you need to know and how to be compliant.
Before your data scientists wring value out of your reams of data, it has to be accessible and, on some basic level, coherently arranged. To harness all that brainpower, you need to keep the data wrangling to a minimum. Enter the data lake.