Important updates in regard to Microservice architecture patterns chapter and s… #3407
Conversation
…ome updates about products.
|
@CESARDELATORRE, It will cover your contributions to all .NET Foundation-managed open source projects. |
|
One quick note (I haven't reviewed the whole thing yet): I see that you're renaming a file. When we do that, we need to add an entry here to redirect traffic from the old page to the new one here: In this case, you need to set the three properties. |
|
It needs to be in the same otherwise it will complain the file still exists. Let me add it here and I'll close the other PR. |
|
@CESARDELATORRE done. Also, make sure you follow the process to sign the CLA. |
…ome updates about products.
|
I removed the minor change in the other "eBook" content (Docker lifecycle ebook) so we don't mix different content in the same PR. |
|
@CESARDELATORRE, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request. |
* added new ASP.NET 4.7.1 APIs * removed extra spaces
…cker and framework selection in .NET
* Core/FSharp FWLink Finishes * Revert "Core/FSharp FWLink Finishes" This reverts commit b2ebe95. * Fixed FWLinks to include final redirects * Fixed Visible Link * Fixed Localizing * feedback
There was a problem hiding this comment.
Looks good @CESARDELATORRE. Left a few comments.
@BillWagner do we have an issue open to address the SEO issues we previously discussed for the e-books? E.g. "missing" descriptions, image filenames, images alt text, etc.
| @@ -0,0 +1,117 @@ | |||
| --- | |||
There was a problem hiding this comment.
filename guidelines is to be all lowercase.
There was a problem hiding this comment.
OK, changed to lowercase, the filename itself plus the references to it.
| keywords: Docker, Microservices, ASP.NET, Container, API Gateway | ||
| author: CESARDELATORRE | ||
| ms.author: wiwagn | ||
| ms.date: 05/26/2017 |
There was a problem hiding this comment.
isn't this new content? then ms.date should be current
There was a problem hiding this comment.
OK, date updated.
|
|
||
| **Figure 4-12**. Using a direct client-to-microservice communication architecture | ||
|
|
||
| In this approach. each microservice has a public endpoint, sometimes with a different TCP port for each microservice. An example of an URL for a particular service could be the following URL in Azure: |
|
|
||
| In a production environment based on a cluster, that URL would map to the load balancer used in the cluster, which in turn distributes the requests across the microservices. In production environments, you could have an Application Delivery Controller (ADC) like [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/application-gateway-introduction) between your microservices and the Internet. This acts as a transparent tier that not only performs load balancing, but secures your services by offering SSL termination. This improves the load of your hosts by offloading CPU-intensive SSL termination and other routing duties to the Azure Application Gateway. In any case, a load balancer and ADC are transparent from a logical application architecture point of view. | ||
|
|
||
| A direct client-to-microservice communication architecture could be good enough for a small microservice-based applications, especially if the client app is a server-side web application like an ASP.NET MVC app. However, when you build large and complex microservice-based applications (for example, when handling dozens of microservice types), and expecially when the client apps are remote mobile apps or SPA web applications, that approach faces a few issues. You need to consider the following questions when developing a large application based on microservices: |
There was a problem hiding this comment.
a small microservice-based applications -> a small microservice-based application
typo: expecially
You need to consider -> Consider
|
|
||
| Sometimes a granular API Gateway can also be a microservice by itself, and even have a domain or business name and related data. Having the API Gateway’s boundaries dictated by the business or domain will help you to get a better design. | ||
|
|
||
| Granularity in the API Gateway tier can be especially useful for more advanced composite UI applications based on microservices, because the concept of a fine-grained API Gateway is similar to an UI composition service. We discuss this later in the [Creating composite UI based on microservices](#creating-composite-ui-based-on-microservices-including-visual-ui-shape-and-layout-generated-by-multiple-microservices). |
| - When **SignalR services** run on *.NET Core*, you can also choose *Linux containers*. | ||
| - Your .NET implementation choice is *.NET Framework*, or *.NET Core 2.1 or beyond*. | ||
| - Your container platform choice must be *Windows containers* if you chose the .NET Framework dependency. | ||
| - When **SignalR services** run on *.NET Core*, you can use *Linux containers or Windows Containers*. |
There was a problem hiding this comment.
expectation of when this will happen?
There was a problem hiding this comment.
Not sure if this date is public or even confirmed, yet, so I prefer not to say it.
There was a problem hiding this comment.
It seems to be public. See https://github.com/aspnet/Home/wiki/Roadmap#210-roadmap and there's even an alpha release already: https://blogs.msdn.microsoft.com/webdev/2017/09/14/announcing-signalr-for-asp-net-core-2-0/
There was a problem hiding this comment.
Yeah, I know that SignalR ALPHA is public. What is not confirmed is when .NET Core 2.1 will be RTM. In the roadmap it says "Q1-Q2 2018"... Not sure if we want to put such a broad timeframe in the doc. I think we should just say it'll come in .NET Core 2.1. :)
| * Your application uses **WCF, WF, and other legacy frameworks**. | ||
| - Your .NET implementation choice is *.NET Framework*, or *.NET Core (in the roadmap for a future release)*. | ||
| - Your container platform choice must be *Windows containers* because of the .NET Framework dependency. | ||
| - When the dependency runs on *.NET Core*, you can also choose *Linux containers*. | ||
| - If WCF supports *.NET Core* in the future, you could choose between *Linux containers and Windows containers*. |
There was a problem hiding this comment.
but this is not true now except for WCF client no? So why say that?
There was a problem hiding this comment.
Agree. I removed that point.
|
|
||
| - Your application currently uses .NET Framework and has strong dependencies on Windows. | ||
|
|
||
| - You need to use Windows APIs that are not supported by .NET Core. | ||
|
|
||
| - You need to use third-party .NET libraries or NuGet packages that are not available for .NET Core. | ||
|
|
||
| Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This "lift and shift" scenario is important for "dockerizing" legacy applications (at least, those that are not based on microservices). | ||
| Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This [*"lift and shift" scenario*](https://aka.ms/liftandshiftwithcontainersebook) (which is not the main focus for this guidance) is important for "dockerizing" legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps or WCF (Windows Communication Foundation) services. |
There was a problem hiding this comment.
(which is not the main focus for this guidance) -> is important to say this? Perhaps say on a sentence after this one?
There was a problem hiding this comment.
OK, removed.
|
|
||
| [Visual Studio for Mac](https://www.visualstudio.com/vs/visual-studio-mac/) is an IDE, evolution of Xamarin Studio, running in macOS and supports Docker since mid-2017. | ||
|
|
||
| You can also use [Visual Studio Code](https://code.visualstudio.com/) (VS Code) on macOS, Linux, and Windows. VS Code fully supports .NET Core, including IntelliSense and debugging. Because VS Code is a lightweight editor, you can use it to develop containerized apps on the Mac in conjunction with the Docker CLI and the .NET Core CLI (dotnet cli). You can also target .NET Core with most third-party editors like Sublime, Emacs, vi, and the open-source OmniSharp project, which also provides IntelliSense support. In addition to the IDEs and editors, you can use the .NET Core command-line tools (dotnet CLI) for all supported platforms. |
There was a problem hiding this comment.
Is it Sublime or Sublime Text?
.NET Core CLI or .NET Core command-line tools? Referring to the same thing with different names confuse people
Is it only OmniSharp that provides IntelliSense?
There was a problem hiding this comment.
OK, changed to the official name: .NET Core command-line interface (CLI) tools:
https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=netcore2x
|
|
||
| ## Using containers for new ("green-field") projects | ||
|
|
||
| Containers are commonly used in conjunction with a microservices architecture, although they can also be used to containerize web apps or services that follow any architectural pattern. You can use .NET Framework on Windows Containers, but the modularity and lightweight nature of .NET Core makes it perfect for containers and microservices architectures. When you create and deploy a container, its image is far smaller with .NET Core than with .NET Framework. | ||
|
|
||
| ## Creating and deploying microservices on containers | ||
|
|
||
| You could use the full .NET framework for microservices-based applications (without containers) when using plain processes, because .NET Framework is already installed and shared across processes. However, if you are using containers, the image for .NET Framework (Windows Server Core plus the full .NET Framework within each image) is probably too heavy for a microservices-on-containers approach. | ||
| Even when you could use the full .NET framework for microservices-based applications (without containers) when using plain processes, because .NET Framework is already installed and shared across processes. However, if you are using containers, the image for .NET Framework (Windows Server Core plus the full .NET Framework within each image) is probably too heavy for a microservices-on-containers approach. |
There was a problem hiding this comment.
we don't refer to framework as full
|
@mairaw This is ready from my perspective. Do you want to check and make sure you're ready to approve it as well? |
* CC6494: Update interpolated-strings.md #41 [AUTOMATED] Hi, @BillWagner, This proposed file change comes from: https://github.com/dotnet/docs.ko-kr/pull/41/files. Could you help to review this and merge this? Many thanks in advance. * Update interpolated-strings.md * Update interpolated-strings.md * feedback * Update interpolated-strings.md
Hello, @dotnet-bot @dotnetcontent, It seems that reported link should read "Windows Driver Kit" according to the title of the web site. Could you review this and merge if agreed, please? Many thanks in advance.
* Add Live Unit Testing link Live Unit Testing link updated to point to the [Visual Studio doc on this topic](https://docs.microsoft.com/en-us/visualstudio/test/live-unit-testing-start?tabs=csharp) instead of being empty. * Changed to relative link
Hello, Substitute positive enforcement: "In this regard" for "However". The containing sentence enforces the notion in the sentence prior to it. "However" would have indicated an exception to the rule. "In this regard" carries forward the realized example to the notion being covered. Thank you. Good day.
Fix typos. Remove "Windows". It's just "Nano Server". Image should be updated as well.
* removed weird chars * fixed broken link
|
@mairaw Is everything ready to merge or is anything missing from my side? |
Regular expression used \w in the part the matches the domain. A word (\w) matches with '_' which is an invalid character in a domain name.
|
@CESARDELATORRE I'll check. Can you resolve the merge conflict? |
…ome updates about products.
|
I think I resolved the merge conflict. Can you confirm? |
|
@CESARDELATORRE it now brought a bunch of commits that don't belong to this PR which is undesirable. let me try to clean this up. the change was simple enough that the resolve conflicts button was enabled here. |
|
I first pressed on the button but then it ididn't show me any possible further action, so I tried with the Git CLI, but it got a bit unclear, at some point.. |
|
Closing in favor of #3486 |
Important updates in regard to Microservice architecture patterns chapter and some updates about products.
Summary
There was a section that was a different topic included as part of another topic's page, so I split it.
For that I needed to re-number the images and while doing so, I was reviewing all that content and updating things that needed to be updated either because of changes in products or more accurate technical explanations.
Fixes #Issue_Number
This is not related to an specific issue. I'm starting to update this documentation so it is up-to-date plus in the upcoming days I will update code snippets so it also supports .NET Core 2.0 (current content shows examples in .NET 1.1)
Suggested Reviewers
@BillWagner