The New .NET Enterprise Stack
•Download as PPTX, PDF•
1 like•2,625 views
The document introduces a new .NET enterprise stack that is designed to handle write-heavy workloads without fear. It consists of infrastructure components like Windows Azure, data stores like Cassandra and Spark Streaming, runtimes like CoreCLR or Mono/CLR, and a programming model using Akka.NET. Metrics on an initial project using this stack found the code footprint was 83% smaller, turnaround time was 6 months, and developer fun was 100,000% more. More information can be found at the listed URL.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
More from petabridge
More from petabridge (20)
Recently uploaded
Recently uploaded (20)
The New .NET Enterprise Stack
- 1. The New .NET Stack By Aaron Stannard, CTO Petabridge, Co-Founder Akka.NET
- 4. We have to do thisWe had to do this
- 5. What if we could...
- 6. Introducing the New .NET Enterprise Stack
- 7. No fear of write-heavy workloads
- 11. The Experience of Being a .NET Developer
- 13. No More Excuses
- 14. Growth vs Fixed Mindset
- 17. Data: C* for App Data
- 18. Data: Spark Streaming for Reporting
- 19. Runtime: CoreCLR or Mono/CLR
- 21. UI: NancyFX, ASP.NET vNext, SignalR
- 24. Developer Metrics Code Footprint: 83% Smaller Turnaround time: 6 months Fun: 100000% more
Editor's Notes
- .NET has been, historically, an expensive ecosystem to play in. Because to play in it, you have to do so by Microsoft’s rules. You have to buy a license for Visual Studio, or more likely, an MSDN subscription. You have to buy a license for Windows Server. You have to buy a license for Windows Server. You have to develop your web applications in a framework built by Microsoft, like ASP.NET or WCF. You have to host your web applications in IIS. And the list goes on.
- Let me tell you a little story from a point in my career with Microsoft from 2010-2011. HTML5 had become mostly standardized and most of its features were rapidly being picked up by all of the major web browsers. One of the HTML5 APIs that had developers really, really excited in early 2011 was the introduction of WebSockets – essentially persistent TCP sockets that are negotiated via HTTP before cutting over to a TCP-based protocol that allows for true server push. At the time the Internet was blowing up about a terrific whitepaper Twitter published showing some results from their performance experiemnts with WebSockets in their web client, and I think they claimed that they experienced something incredible like an 80+% drop in load on servers they switched from using HTTP long-polling to websockets. The point is, this is a technology that everyone was flipping out about including .NET developers. Only problem was – Internet Information Services, the web server built into Windows Server, had zero support for WebSockets. So even if you managed to find a websocket library for .NET, and there really weren’t any at the time, we had to wait for the next release of IIS to come out…. Which was bundled with the next release of Windows Server, 2012…. And we’d need to purchase and upgrade and roll that out to all of our servers…. In order to support an established standard that had been discussed for years. Welcome to the world of developing at the pace of Microsoft. So the choice .NET developers were faced with was: Wait for 12-18 months plus $N dollars per server and do a major systems upgrade whenever Microsoft said you could; or Switch to Node.JS, the new kid on the block at the time – and boasted fantastic support for WebSockets through its Socket.IO library, which is still immensely popular today. I witnessed droves and droves of .NET developers make the obvious choice: to abandon .NET and switch to a platform that didn’t introduce stupid tradeoffs like this. And that’s been the story of our ecosystem. Play by Microsoft’s rules… Or go somewhere else. And .NET developers have been leaving our ecosystem for years for multitudes of reasons. I nearly left it because I was tired of having to write drivers for technologies like Cassandra and tons of other OSS technologies I wanted to use with my .NET applications – just being able to use the first-party drivers in Java or Scala really appealed to me. Others have left because they wanted access to the latest front-end technologies like coffeescript, SASS, bower, and others – thing they can easily get in the Python, Ruby, or Node.JS ecosystems. In short: our ecosystem has been one where we’ve had to trade away our access to the rest of the world’s innovation in order to have Visual Studio and an integrated experience. And recently, that experience has become less and less valuable on its own. And it’s not just this example either – there’s
- The possibility I’m here to tell you about today is one where we .NET developers no longer have to do this anymore. All of those “haves” I mentioned earlier… are “hads” now. We now have the possibility of choice and having a say in our experience as developers. I want everyone in this room to leave today knowing full well that there is an entire realm available to you now that never existed before, and I’m going to give you access to choose it. All you have to do is listen closely. The state of .NET as we know it has radically changed.
- So here’s the fork in the road for us – if we could build reliable, distributed systems in pure .NET… Using Visual Studio… Running our apps on Windows Server OR Linux – it doesn’t matter which. And deploying using the latest technologies available to the rest of the industry, like Docker or Chef… Well, now we can.
- Introducing the new .NET stack. First, we start with our growth mindset. We’re not afraid of experimentation, and we treat every experiment as a growth opportunity. And as a result, we’re going to build consistently better and better experiences for our users over time. Next, we’re going to use Windows Azure as the foundation of our stack – it has a lot of offer, especially with Service Fabric coming down the rails soon. And if we’re able to take advantage of the Docker support being built into it, we can have a level of deployment agility both on the cloud and on-premise that’s never been achievable in .NET before. That’s an extraordinary breakthrough. Next, the data stack – we’re going to roll with Cassandra and Spark. Cassandra will be our durable store for our application state and it will be used exclusively for application state. Because we’re bold .NET developers, we’re going to do something with our reporting requirements – completely delegate them to Spark Streaming and whatever datastore Spark writes to. Never again will we introduce horrible performance and mismatch problems to our database by conflating reporting and app requirements ever again. Put a wall between those two and forget about them. The runtime – we’re going to rock CoreCLR / CLR / Mono. Compile on any platform, run on any platform, and forget about it. No GAC. No strong-named assemblies. We’re done with that – bin-deploy everything and be agile. At the application layer – we’re going to introduce the increasingly popular Akka.NET actor framework as an instrument for building layers of soft real-time, distributed services that can help us build “impossible” applications such as multi-player games, banking software, and more. And lastly – our front-end. We’re going to take advantage of the abundance of X-plat front-end technologies coming to .NET and use those. IIS and Windows Server are now optional.
- Picking SQL Server is a career risk Workloads are becoming increasingly write-heavy, and relational data stores are simply not designed for that.
- Write .NET where you want it, run it where you want it But around the time I was at Microsoft, I got present to the reality of what it was like being a .NET developer versus the alternatives. And the truth is, the experience of being a .NET developer has been one where we are utterly constrained in our choice of technologies and the feasibility of their cost.
- There are no more excuses for .NET developers to be the red-headed step children of web development. In terms of the technologies that are available to us now, we are free from the tyranny of Windows and SQL Server Licensing. .NET is now a viable cross-platform runtime, whether it’s with Mono 4.0 or the upcoming .NET Core PCL. On top of that, there are now mature drivers available for .NET developers for virtually every popular OSS database. With the advent of Omnisharp, Visual Studio Code, and the amazing amount of stuff Microsoft’s put into the free “Visual Studio Community” edition – our toolchain isn’t an issue either. We can develop our .NET apps on Windows, OS X, or Linux easier than we ever have before. And when it comes to our web frameworks and servers, we have an abundance of choice there too with the rise of OWIN and cross-platform web frameworks like NancyFX and ASP.NET vNext. No more being locked into IIS only. Beyond that… with the rise of projects like Orleans, DotNetty, Akka.NET, and many others – we’re starting to enjoy a real OSS ecosystem in .NET that can deliver the sort of tools we need to build distributed enterprise applications all in 100% native C# and F#. We’re out of excuses! We can take on some really big challenges now if we change our mindset, and that is exactly what I’m proposing we do.
- The first thing we have to change as .NET developers is our mindset – not our tools. I love .NET and .NET developers, but our ecosystem is especially guilty of having adopted a “fixed” mindset about the way things are and are not in our world. Some of this is due to the choices Microsoft has afforded to us historically, but all of that is now different – it’s up to us to choose how things occur for us. Here’s what I mean by a “fixed” mindset. In a fixed mindset, you have a static definition of the way you are and the way everything else is. You’re either a naturally good programmer or you’re not. You stick to what you know so no one can judge you as a failure. The outcome is the only thing that matters – if you tried something new in an implementation of a project it fails to deliver on some key metric, then you look at the effort as wasted and retreat to doing whatever you were doing before. In school children, kids who were routinely praised for their intelligence or the outcomes of their exams growing up develop a fixed mindset about who they are – “I must be naturally smart!” These are the kids who can’t cope with the dynamism of the real world once they graduate – they know how to take standardized exams like a champion, but they can’t make it through the workday without receiving some kind of validation or reward – because that’s the fixed little world they know from college. They’re debilitated and limited performers in the real-world, which is why here in Silicon Valley we have so many stereotypes about Ivy League and Stanford kids who can’t cut it here. We, .NET developers, are a lot like these kids – most of us are terrified at the thought of wondering outside of our comfort zone of SQL Server + Windows + ASP.NET + CRUD. We have a fixed view of the world that everything has to be done the way we’ve been doing it since 2001, making changes only once we’re absolutely forced to by opportunity and circumstance. I assert that the widespread pervasiveness of this fixed, complacent “if it ain’t broke, don’t fix it” attitude is more responsible for the lack of progress in our ecosystem than anything Microsoft has ever done. So let’s start with this. Instead of a fixed mentality, we need a growth mentality. A growth mentality is one where we have a dynamic view of the world – “good programmers are made through consistent effort and practice.” See the difference? Kids who are praised for the effort they put into their work in school, rather than their results, develop a growth mentality. They love being challenged – they view failure and trial and error as growth exercises that will ultimately help them master whatever it is they’re up to. This growth mindset is what we .NET developers have to do adopt in order to have a future where we have an abundance of choice. We have to rise to the challenge of running .NET on .NETCore on Linux using Docker in order to build highly available, cloud-agnostic services. We have to treat SQL Server as *an* option, not *the* option when it comes to storing our data. We need to be willing to play with new programming models, such as the actor model, to build the sorts of experiences our users demand in 2015. We have to experiment and treat project failures not as wastes of effort, but as growth exercises that help us expand our zone of effectiveness. If we as an ecosystem can accomplish this, then we will join the ranks of the JVM as unstoppable juggernauts.
- In short, what got .NET to where it is over the past 15 years – SQL Server, ASP.NET, Windows, and IIS, won’t be what takes us to whatever our future has in store for us over the next 15 years. So let’s stop asking for a “faster horse” and start asking for automobiles. You know, I had a developer who contacted us and talked about how their business is losing tens of thousands of dollars per day due to SQL Server throughput issues caused by row lock contention. In the same breath as telling me how much pain this is causing their business they excitedly told me about how moving to their SQL Server instance to a 64-core, 512GB of RAM box was going to solve all of their problems. Do you see the obvious issue here? You can’t scale your way out of a contention problem – you have to fundamentally change your relationship with your data.
- A business story about MarkedUp’s success with this stack