Dot Net Architecture Guide
Dot Net Architecture Guide
Editors:
Maira Wenzel
Action links
This e-book is also available in a PDF format (English version only) Download
Clone/Fork the reference application eShopOnWeb on GitHub
Introduction
.NET 5 and ASP.NET Core offer several advantages over traditional .NET development. You should use .NET 5 for
your server applications if some or all of the following are important to your application's success:
Cross-platform support.
Use of microservices.
Use of Docker containers.
High performance and scalability requirements.
Side-by-side versioning of .NET versions by application on the same server.
Traditional .NET applications can and do support many of these requirements, but ASP.NET Core and .NET 5 have
been optimized to offer improved support for the above scenarios.
More and more organizations are choosing to host their web applications in the cloud using services like
Microsoft Azure. You should consider hosting your application in the cloud if the following are important to your
application or organization:
Reduced investment in data center costs (hardware, software, space, utilities, server management, etc.)
Flexible pricing (pay based on usage, not for idle capacity).
Extreme reliability.
Improved app mobility; easily change where and how your app is deployed.
Flexible capacity; scale up or down based on actual needs.
Building web applications with ASP.NET Core, hosted in Azure, offers many competitive advantages over
traditional alternatives. ASP.NET Core is optimized for modern web application development practices and cloud
hosting scenarios. In this guide, you'll learn how to architect your ASP.NET Core applications to best take
advantage of these capabilities.
Version
This guide has been revised to cover .NET 5.0 version along with many additional updates related to the same
"wave" of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET
5.0 release. That's why the book version has also been updated to version 5.0 .
Purpose
This guide provides end-to-end guidance on building monolithic web applications using ASP.NET Core and
Azure. In this context, "monolithic" refers to the fact that these applications are deployed as a single unit, not as a
collection of interacting services and applications.
This guide is complementary to ".NET Microservices. Architecture for Containerized .NET Applications", which
focuses more on Docker, microservices, and deployment of containers to host enterprise applications.
.NET Microservices. Architecture for Containerized .NET Applications
e-book
https://aka.ms/MicroservicesEbook
Sample Application
https://aka.ms/microservicesarchitecture
References
Choosing between .NET 5 and .NET Framework for ser ver apps
https://docs.microsoft.com/dotnet/standard/choosing-core-framework-server
NE XT
Architecting Cloud Native .NET Applications for
Azure
3/6/2021 • 2 minutes to read • Edit Online
EDITION v1.0.2
Refer changelog for the book updates and community contributions.
PUBLISHED BY
Microsoft Developer Division, .NET, and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
Authors:
Editors:
Version
This guide has been written to cover .NET 5 version along with many additional updates related to the same
“wave” of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET 5
release.
NE XT
ASP.NET Core gRPC for WCF Developers
3/6/2021 • 2 minutes to read • Edit Online
Editor:
Introduction
gRPC is a modern framework for building networked services and distributed applications. Imagine the
performance of Windows Communication Foundation (WCF) NetTCP bindings, combined with the cross-
platform interoperability of SOAP. gRPC builds on HTTP/2 and the Protobuf message-encoding protocol to
provide high performance, low-bandwidth communication between applications and services. It supports server
and client code generation across most popular programming languages and platforms, including .NET, Java,
Python, Node.js, Go, and C++. With the first-class support for gRPC in ASP.NET Core 5.0, alongside the existing
gRPC tools and libraries for .NET Framework 4.x, it's an excellent alternative to WCF for development teams
looking to adopt .NET in their organizations.
References
gRPC website https://grpc.io
Choosing between .NET 5 and .NET Framework for ser ver apps /dotnet/standard/choosing-core-
framework-server
NE XT
Blazor for ASP.NET Web Forms Developers
3/6/2021 • 4 minutes to read • Edit Online
EDITION v1.0
Refer changelog for the book updates and community contributions.
PUBLISHED BY
Microsoft Developer Division, .NET, and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
All other marks and logos are property of their respective owners.
Authors:
Steve "ardalis" Smith , Software Architect and Trainer, Ardalis Services LLC
Introduction
.NET has long supported web app development through ASP.NET, a comprehensive set of frameworks and tools
for building any kind of web app. ASP.NET has its own lineage of web frameworks and technologies starting all
the way back with classic Active Server Pages (ASP). Frameworks like ASP.NET Web Forms, ASP.NET MVC,
ASP.NET Web Pages, and more recently ASP.NET Core, provide a productive and powerful way to build server-
rendered web apps, where UI content is dynamically generated on the server in response to HTTP requests. Each
ASP.NET framework caters to a different audience and app building philosophy. ASP.NET Web Forms shipped
with the original release of the .NET Framework and enabled web development using many of the patterns
familiar to desktop developers, like reusable UI controls with simple event handling. However, none of the
ASP.NET offerings provide a way to run code that executed in the user's browser. To do that requires writing
JavaScript and using any of the many JavaScript frameworks and tools that have phased in and out of
popularity over the years: jQuery, Knockout, Angular, React, and so on.
Blazor is a new web framework that changes what is possible when building web apps with .NET. Blazor is a
client-side web UI framework based on C# instead of JavaScript. With Blazor you can write your client-side logic
and UI components in C#, compile them into normal .NET assemblies, and then run them directly in the browser
using a new open web standard called WebAssembly. Or alternatively, Blazor can run your .NET UI components
on the server and handle all UI interactions fluidly over a real-time connection with the browser. When paired
with .NET running on the server, Blazor enables full-stack web development with .NET. While Blazor shares many
commonalities with ASP.NET Web Forms, like having a reusable component model and a simple way to handle
user events, it also builds on the foundations of .NET to provide a modern and high-performance web
development experience.
This book introduces ASP.NET Web Forms developers to Blazor in a way that is familiar and convenient. It
introduces Blazor concepts in parallel with analogous concepts in ASP.NET Web Forms while also explaining new
concepts that may be less familiar. It covers a broad range of topics and concerns including component
authoring, routing, layout, configuration, and security. And while the content of this book is primarily for
enabling new development, it also covers guidelines and strategies for migrating existing ASP.NET Web Forms
to Blazor for when you want to modernize an existing app.
NE XT
Containerized Docker Application Lifecycle with
Microsoft Platform and Tools
4/26/2021 • 2 minutes to read • Edit Online
Credits
Author:
Acquisitions Editor:
Janine Patrick
Developmental Editor:
Editorial Production:
Dianne Russell
Octal Publishing, Inc.
Copyeditor:
Copyright
PUBLISHED BY
Microsoft Developer Division, .NET and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
NE XT
DevOps for ASP.NET Core Developers
4/21/2021 • 2 minutes to read • Edit Online
EDITION v1.1.0
Refer changelog for the book updates and community contributions.
This guide is available as a downloadable PDF e-book.
PUBLISHED BY
Microsoft Developer Division, .NET, and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
Credits
Authors:
Cam Soper
Scott Addie
Colin Dembovsky
Welcome
Welcome to the Azure Development Lifecycle guide for .NET! This guide introduces the basic concepts of
building a development lifecycle around Azure using .NET tools and processes. After finishing this guide, you'll
reap the benefits of a mature DevOps toolchain.
NE XT
Modernize existing .NET applications with Azure
cloud and Windows Containers
3/6/2021 • 15 minutes to read • Edit Online
EDITION v5.0
Refer changelog for the book updates and community contributions.
PUBLISHED BY Microsoft Press and Microsoft DevDiv Divisions of Microsoft Corporation One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced in any form or by any means
without the written permission of the publisher.
This book is available for free in the form of an electronic book (e-book) available through multiple channels at
Microsoft such as https://dot.net/architecture.
If you have questions related to this book, email at dotnet-architecture-ebooks-
feedback@service.microsoft.com.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies. All other marks are property of their respective owners.
Author:
Scott Hunter , Partner Director PM, .NET team, Microsoft Paul Yuknewicz , Principal PM Manager, Visual
Studio Tools team, Microsoft Lisa Guthrie , Sr. PM, Visual Studio Tools team, Microsoft Ankit Asthana ,
Principal PM Manager, .NET team, Microsoft Unai Zorrilla , Developer Lead, Plain Concepts Javier Valero ,
Chief Operating Officer at Grupo Solutio
Introduction
When you decide to modernize your web applications or services and move them to the cloud, you don't
necessarily have to fully rearchitect your apps. Rearchitecting an application by using an advanced approach like
microservices isn't always an option because of cost and time restraints. Depending on the type of application,
rearchitecting an app also might not be necessary. To optimize the cost-effectiveness of your organization's
cloud migration strategy, it's important to consider the needs of your business and the requirements of your
apps. You'll need to determine:
Which apps require a transformation or rearchitecting.
Which apps need to be only partially modernized.
Which apps you can "lift and shift" directly to the cloud.
Figure 1-1 . Modernization paths for existing .NET applications and services
Each migration approach has different benefits and reasons for using it. You can choose a single approach when
you migrate apps to the cloud, or choose certain components from multiple approaches. Individual applications
aren't limited to a single approach or maturity state. For instance, a common hybrid approach would have
certain on-premises components plus other components in the cloud.
The definition and short explanation for each application maturity level are the following:
Level 1: Cloud Infrastructure-Ready applications: In this migration approach, you just migrate or rehost
your current on-premises applications to an infrastructure as a service (IaaS) platform. Your apps have almost
the same composition as before, but now you deploy them to VMs in the cloud. This simple type of migration is
typically known in the industry as "Lift & Shift."
Level 2: Cloud Optimized applications: At this level and still without rearchitecting or altering significant
code, you can gain additional benefits from running your app in the cloud with modern technologies like
containers and additional cloud-managed services. You improve the agility of your applications to ship faster by
refining your enterprise development operations (DevOps) processes. You achieve this functionality by using
technologies like Windows Containers, which is based on Docker Engine. Containers remove the friction that's
caused by application dependencies when you deploy in multiple stages. In this maturity model, you can deploy
containers on IaaS or PaaS while using additional cloud-managed services related to databases, cache as a
service, monitoring, and continuous integration/continuous deployment (CI/CD) pipelines.
The third level of maturity is the ultimate goal in the cloud, but it's optional for many apps and not the main
focus of this guide:
Level 3: Cloud-Native applications: This migration approach typically is driven by business need and targets
modernizing your mission-critical applications. At this level, you use PaaS services to move your apps to PaaS
computing platforms. You implement cloud-native applications and microservices architecture to evolve
applications with long-term agility, and to scale to new limits. This type of modernization usually requires
architecting specifically for the cloud. New code often must be written, especially when you move to cloud-
native application and microservice-based models. This approach can help you gain benefits that are difficult to
achieve in your monolithic and on-premises application environment.
Table 1-1 describes the main benefits of and reasons for choosing each migration or modernization approach.
C LO UD- N AT IVE
C LO UD IN F RA ST RUC T URE- REA DY C LO UD- O P T IM IZ ED M O DERN IZ E, REA RC H IT EC T, A N D
L IFT A N D SH IFT M O DERN IZ E REWRIT E
Applications deployed to VMs in Azure Monolithic or N-Tier apps deployed to Containerized microservices on Azure
Azure App Service, Azure Container Kubernetes Service (AKS) and/or
Instance (ACI), VMs with containers, or serverless microservices based on
AKS (Azure Kubernetes Service) Azure Functions.
Data target
SQL or any relational database on a Azure SQL Database Managed Fined-grain databases per
VM Instance or another managed microservice, based on Azure SQL
database in the cloud. Database, Azure Cosmos DB, or
another managed database in the
cloud
Advantages
No rearchitecting, no new code No rearchitecting Architect for the cloud, you get the
Least effort for quick migration Minimal code/config changes best benefits from the cloud but new
Least-common denominator Improved deployment and DevOps code is needed
supported in Azure agility to release because of containers Microservices cloud-native
Basic availability guarantees Increased density and lower approaches
After moving to the cloud, it's easier deployment costs Modern mission-critical applications,
to modernize even more Portability of apps and cloud-resilient hyper-scalable
dependencies Fully managed services
Flexibility of host targets: PaaS Optimized for scale
approaches or IaaS Optimized for autonomous agility
by subsystem
Built on deployment and DevOps
Challenges
C LO UD- N AT IVE
C LO UD IN F RA ST RUC T URE- REA DY C LO UD- O P T IM IZ ED M O DERN IZ E, REA RC H IT EC T, A N D
L IFT A N D SH IFT M O DERN IZ E REWRIT E
Smaller cloud value, other than the Containerizing is an additional step Requires rearchitecture for cloud-
shift in operating expense or closing in the learning curve for developers native apps and microservice
datacenters and IT Operations architectures and usually requires
Little is managed: No OS or DevOps and CI/CD pipelines are significant code refactoring or rewriting
middleware patching; might use usually 'a must' for this approach. If when modernizing (increased time and
infrastructure solutions, like Terraform, not currently present in the culture of budget)
Spinnaker, or Puppet the organization, it might be an
additional challenge
Table 1-1. Benefits and challenges of modernization paths for existing .NET applications and services
Figure 1-2. Primary technologies for each maturity level for modernizing existing .NET web applications
Figure 1-2 highlights the most common scenarios, but many hybrid and mixed variations are possible when it
comes to architecture. For example, the maturity models apply not only to monolithic architectures in existing
web apps, but also to service orientation, N-Tier, and other architecture style variations. The higher focus or
percentage on one or another architecture type and related technologies determines the overall maturity level
of your applications.
Each maturity level in the modernization process is associated with the following key technologies and
approaches:
Cloud Infrastructure-Ready (rehost or basic lift & shift): As a first step, many organizations want only
to quickly execute a cloud-migration strategy. In this case, applications are rehosted. Most rehosting can
be automated by using Azure Migrate, a service that provides the guidance, insights, and mechanisms
needed to assist you in migrating to Azure based on cloud tools like Azure Site Recovery and Azure
Database Migration Service. You can also set up rehosting manually, so that you can learn infrastructure
details about your assets when you move legacy apps to the cloud. For example, you can move your
applications to VMs in Azure with little modification-probably with only minor configuration changes. The
networking in this case is similar to an on-premises environment, especially if you create virtual networks
in Azure.
Cloud-Optimized (Managed Services and Windows Containers): This model is about making a few
important deployment optimizations to gain some significant benefits from the cloud, without changing
the core architecture of the application. The fundamental step here is to add Windows Containers support
to your existing .NET Framework applications. This important step (containerization) doesn't require
touching the code, so the overall lift and shift effort is light. You can use tools like Image2Docker or Visual
Studio, with its tools for Docker. Visual Studio automatically chooses smart defaults for ASP.NET
applications and Windows Containers images. These tools offer both a rapid inner loop, and a fast path to
get the containers to Azure. Your agility is improved when you deploy to multiple environments. Then,
moving to production, you can deploy your Windows Containers to Azure Web App for Containers, Azure
Container Instances (ACI), and Azure VMs with Windows Server 2016 and containers if you prefer an IaaS
approach. For more complex multi-container applications, consider using orchestrators like Azure
Kubernetes Service (AKS/ACS).
During this initial modernization, you can also add assets from the cloud, such as monitoring with tools like
Azure Application Insights; CI/CD pipelines for your app lifecycles with Azure DevOps Services; and many more
data resource services that are available in Azure. For instance, you can modify a monolithic web app that was
originally developed by using traditional ASP.NET Web Forms or ASP.NET MVC, but now you deploy it by using
Windows Containers. When you use Windows Containers, you should also migrate your data to a database in
Azure SQL Database Managed Instance, all without changing the core architecture of your application.
Cloud-Native : As introduced, you should think about architecting cloud-native applications when you are
targeting large and complex applications with multiple independent development teams working on
different microservices that can be developed and deployed autonomously. Also, due to granularized and
independent scalability per microservice. These architectural approaches face very important challenges and
complexities but can be greatly simplified by using cloud PaaS and orchestrators like Azure Kubernetes
Service (AKS/ACS) (managed Kubernetes), and Azure Functions for a serverless approach. All these
approaches (like microservices and Serverless) typically require you to architect for the cloud and write new
code—code that is adapted to specific PaaS platforms, or code that aligns with specific architectures, like
microservices.
Figure 1-3 shows the internal technologies that you can use for each maturity level:
Figure 1-3. Internal technologies for each modernization maturity level
Modernization scenarios
For modernization scenarios, you might have a pure Cloud-Optimized application that uses elements only from
that maturity level. Or, you might have an intermediate-state application with some elements from Cloud
Infrastructure-Ready and other elements from Cloud-Optimized (a "pick and choose" or mixed model), like in
Figure 1-5.
Figure 1-5. Example "pick and choose" scenario, with database on IaaS, DevOps, and containerization assets
Next, as the ideal scenario for many existing .NET Framework applications to migrate, you could migrate to a
Cloud-Optimized application, to get significant benefits from little work. This approach also sets you up for
Cloud-Native as a possible future evolution. Figure 1-6 shows an example.
Figure 1-6. Example Cloud-Optimized apps scenario, with Windows Containers and managed services
Going even further, you could extend your existing Cloud-Optimized application by adding a few microservices
for specific scenarios. This approach would move you partially to the level of Cloud-Native model, which is not
the main focus of the present guidance.
NE XT
Modernizing Desktop Apps on Windows 10 with
.NET 5
3/6/2021 • 4 minutes to read • Edit Online
Miguel Ramos , Senior Program Manager, Windows Developer Platform team, Microsoft
Adam Braden , Principal Program Manager, Windows Developer Platform team, Microsoft
Ricardo Minguez Pablos , Senior Program Manager, Azure IoT team, Microsoft
Introduction
This book is about strategies you can adopt to move your existing desktop applications through the path of
modernization and incorporate the latest runtime, language, and platform features. You'll discover that there's
no unique recipe as each application is different, and so are your requirements and preferences. The good news
is that there are common approaches you can apply to add new features and capabilities to your applications.
Some of them won't even require major modifications of your code. In this book, we'll reveal how all those
features work behind the scenes and explain the mechanics of their implementations. Moreover, you'll find some
common scenarios for modernizing existing desktop applications shown in detail so you can find inspiration for
evolving your projects.
Microsoft's approach to modernizing existing applications is to give you the flexibility to create your own
customized path. All the modernization strategies described in this book are mostly independent. You can
choose ones that are relevant for your application and skip others that aren't important for you. In other words,
you can mix and match the strategies to best address your application needs.
NE XT
.NET Microservices: Architecture for Containerized
.NET Applications
3/6/2021 • 6 minutes to read • Edit Online
Action links
This e-book is also available in a PDF format (English version only) Download
Clone/Fork the reference application eShopOnContainers on GitHub
Watch the introductory video on Channel 9
Get to know the Microservices Architecture right away
Introduction
Enterprises are increasingly realizing cost savings, solving deployment problems, and improving DevOps and
production operations by using containers. Microsoft has been releasing container innovations for Windows
and Linux by creating products like Azure Kubernetes Service and Azure Service Fabric, and by partnering with
industry leaders like Docker, Mesosphere, and Kubernetes. These products deliver container solutions that help
companies build and deploy applications at cloud speed and scale, whatever their choice of platform or tools.
Docker is becoming the de facto standard in the container industry, supported by the most significant vendors
in the Windows and Linux ecosystems. (Microsoft is one of the main cloud vendors supporting Docker.) In the
future, Docker will probably be ubiquitous in any datacenter in the cloud or on-premises.
In addition, the microservices architecture is emerging as an important approach for distributed mission-critical
applications. In a microservice-based architecture, the application is built on a collection of services that can be
developed, tested, deployed, and versioned independently.
Version
This guide has been revised to cover .NET 5 version along with many additional updates related to the same
“wave” of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET 5
release. That’s why the book version has also been updated to version 5.0 .
What this guide does not cover
This guide does not focus on the application lifecycle, DevOps, CI/CD pipelines, or team work. The
complementary guide Containerized Docker Application Lifecycle with Microsoft Platform and Tools focuses on
that subject. The current guide also does not provide implementation details on Azure infrastructure, such as
information on specific orchestrators.
Additional resources
Containerized Docker Application Lifecycle with Microsoft Platform and Tools (downloadable e-
book)
https://aka.ms/dockerlifecycleebook
Credits
Co-Authors:
Editors:
Mike Pope
Steve Hoag
Copyright
PUBLISHED BY
Microsoft Developer Division, .NET and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
NE XT
Serverless apps: Architecture, patterns, and Azure
implementation
11/2/2020 • 6 minutes to read • Edit Online
Contributor:
Editors:
Introduction
Serverless is the evolution of cloud platforms in the direction of pure cloud native code. Serverless brings
developers closer to business logic while insulating them from infrastructure concerns. It's a pattern that doesn't
imply "no server" but rather, "less server." Serverless code is event-driven. Code may be triggered by anything
from a traditional HTTP web request to a timer or the result of uploading a file. The infrastructure behind
serverless allows for instant scale to meet elastic demands and offers micro-billing to truly "pay for what you
use." Serverless requires a new way of thinking and approach to building applications and isn't the right
solution for every problem. As a developer, you must decide:
What are the pros and cons of serverless?
Why should you consider serverless for your own applications?
How can you build, test, deploy, and maintain your serverless code?
Where does it make sense to migrate code to serverless in existing applications, and what is the best way to
accomplish this transformation?
Before the cloud, a discernible boundary existed between development and operations. Deploying an
application meant answering myriad questions like:
What hardware should be installed?
How is physical access to the machine secured?
Does the data center require an Uninterruptible Power Supply (UPS)?
Where are storage backups sent?
Should there be redundant power?
The list goes on and the overhead was enormous. In many situations, IT departments were forced to deal with
incredible waste. The waste was due to over-allocation of servers as backup machines for disaster recovery and
standby servers to enable scale-out. Fortunately, the introduction of virtualization technology (like Hyper-V)
with Virtual Machines (VMs) gave rise to Infrastructure as a Service (IaaS). Virtualized infrastructure allowed
operations to set up a standard set of servers as the backbone, leading to a flexible environment capable of
provisioning unique servers "on demand." More important, virtualization set the stage for using the cloud to
provide virtual machines "as a service." Companies could easily get out of the business of worrying about
redundant power or physical machines. Instead, they focused on the virtual environment.
IaaS still requires heavy overhead because operations is still responsible for various tasks. These tasks include:
Patching and backing up servers.
Installing packages.
Keeping the operating system up-to-date.
Monitoring the application.
The next evolution reduced the overhead by providing Platform as a Service (PaaS). With PaaS, the cloud
provider handles operating systems, security patches, and even the required packages to support a specific
platform. Instead of building a VM then configuring .NET and standing up Internet Information Services (IIS)
servers, developers simply choose a "platform target" such as "web application" or "API endpoint" and deploy
code directly. The infrastructure questions are reduced to:
What size services are needed?
How do the services scale out (add more servers or nodes)?
How do the services scale up (increase the capacity of hosting servers or nodes)?
Serverless further abstracts servers by focusing on event-driven code. Instead of a platform, developers can
focus on a microservice that does one thing. The two key questions for building the serverless code are:
What triggers the code?
What does the code do?
With serverless, infrastructure is abstracted. In some cases, the developer no longer worries about the host at all.
Whether or not an instance of IIS, Kestrel, Apache, or some other web server is running to manage web
requests, the developer focuses on an HTTP trigger. The trigger provides the standard, cross-platform payload
for the request. The payload not only simplifies the development process, but facilitates testing and in some
cases, makes the code easily portable across platforms.
Another feature of serverless is micro-billing. It's common for web applications to host Web API endpoints. In
traditional bare metal, IaaS and even PaaS implementations, the resources to host the APIs are paid for
continuously. That means you pay to host the endpoints even when they aren't being accessed. Often you'll find
one API is called more than others, so the entire system is scaled based on supporting the popular endpoints.
Serverless enables you to scale each endpoint independently and pay for usage, so no costs are incurred when
the APIs aren't being called. Migration may in many circumstances dramatically reduce the ongoing cost to
support the endpoints.
NE XT
Dapr for .NET Developers
6/25/2021 • 2 minutes to read • Edit Online
EDITION v1.0
PUBLISHED BY
Microsoft Developer Division, .NET, and Azure Incubations teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2021 by Microsoft Corporation
All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by
any means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
Authors:
Mark Russinovich , Azure CTO and Technical Fellow, Azure Office of CTO, Microsoft
Nish Anil , Senior Program Manager, .NET team, Microsoft
Mark Fussell , Principal Program Manager, Azure Incubations, Microsoft
Yaron Schneider , Principal Software Engineer, Azure Incubations, Microsoft
Ori Zohar , Senior Program Manager, Azure Incubations, Microsoft
Editors:
Version
This guide has been written to cover the Dapr 1.0 version. .NET Core samples are based on .NET Core 3.1 .
NE XT
Porting Existing ASP.NET Apps to .NET Core
3/6/2021 • 3 minutes to read • Edit Online
IMPORTANT
PREVIEW EDITION
This article provides early content from a book that is currently under construction. If you have any feedback, submit it at
https://aka.ms/ebookfeedback.
PUBLISHED BY
Microsoft Developer Division, .NET, and Visual Studio product teams
A division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright © 2020 by Microsoft Corporation
All rights reserved. No part of this book's contents may be reproduced or transmitted in any form or by any
means without the written permission of the publisher.
This book is provided "as-is" and expresses the author's views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change without
notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks
of the Microsoft group of companies.
Mac and macOS are trademarks of Apple Inc.
The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.
All other marks and logos are property of their respective owners.
Authors:
Version
This guide covers .NET Core 3.1 and updates related to the same technology "wave" (that is, Azure and other
third-party technologies) coinciding in time with the .NET Core 3.1 release. Updating from .NET Core 3.1 to .NET
5.0 (the next version) is relatively straightforward and certainly will require substantially less effort than porting
from .NET Framework to .NET Core. Migrating from .NET Framework 4.x to .NET 5.0 will be similar to migrating
to .NET Core 3.1. For more information, see choosing the right .NET Core version.
NE XT