[01] 初探 Enterprise Web App Patterns | Enterprise Web App Patterns 系列

2024-11-27 Wednesday

cover

當提到 application 要上雲或者要變成 modernize app，cloud native app 本質上都在講同一件事事情。

當有類似任務降臨的時候，有沒有什麼可以參考的資料或者該如何下手？

這篇我們來談看軟提出的一個針對 web 類型 app 的一個 pattern

Enterprise Web App Patterns

什麼是 Enterprise Web App Patterns

Enterprise Web App Patterns 其實就是微軟基於 Azure Well-Archited Framework 所整理出來的一個讓大家可以 follow 的 pattern。

它的目的是要讓大家想要變成 cloud native app 有個可以參考的 guidance

Enterprise web app patterns

Enterprise Web App Patterns Overview

我們從左邊到右邊可以看到，他就是希望大家在地端的 APP 可以透過：

Landing Zone -> 依照 App 性質不同，微軟有不同的進入方式，這些稱之為 Landing Zone。簡單來說就是有建議該用什麼類型的 Azure 服務有個懶人包，直接簡曆出來
Reliable Web App Pattern => 從地端到雲端，前提是 App 要夠穩定，因此這塊是在最小的調整情況下，讓 App 可以足夠穩定的建議。目的是從地端可以上雲
Moder Web App pattern => 地端可以上雲之後，接下來就是如何把雲的特性用到極致。這也就牽扯架構改善，往 modernize app 進化的最少需要內容

如果從下往上的化可以看到：

提供了 .NET 和 Java 的範例 => 包含了可以用什麼套件，範例的 project 讓大家更有感覺
Well-Architected Framework => 這個是一直以來都有提供的讓大家上雲可以參考的一個架構。所以這個 Enterprise Web App 其實也是 Well-Architected Framework 的其中微軟認為重要被挑出來的部分

當我們有點概念之後，在進入細節之前，我們往回倒一點點

看一下所謂的 Modernize App/Cloud Native App 以及 Well-Archited Framework

什麼是 Cloud Native App/Modernize App

What is Cloud Native?

如果用 Cloud Native App 這個名字來看，好像要上雲才需要，但其實講的是現代化架構這件事

我們在 [01] Cloud Native Application 是什麼？ | AZ-204 在考什麼有提過微軟所謂的 5 個支柱

Cloud Native 的支柱

實際上，我們只需要看 Micro Services 那個大家就理解，一般地端的應用因為全部都是在同一個程式碼裡面，所以很多東西不用考慮。但當我們拆成了一個一個服務然後中間用 API 等方式溝通的時候，那很多問題就延伸出來了，舉例來說：會不會有網路問題導致不穩定，那應用的策略是什麼？

所以 Reliable Web App Pattern 其中關注的地方就在如何讓他可靠

那難到把應用拆成 Mecroservices 就是 Modernize App 了嗎？

有人有把核心理念整理成為 Twelve Factor App

Factor	Explanation
1 - Code Base	A single code base for each microservice, stored in its own repository. Tracked with version control, it can deploy to multiple environments (QA, Staging, Production).
2 - Dependencies	Each microservice isolates and packages its own dependencies, embracing changes without impacting the entire system.
3 - Configurations	Configuration information is moved out of the microservice and externalized through a configuration management tool outside of the code. The same deployment can propagate across environments with the correct configuration applied.
4 - Backing Services	Ancillary resources (data stores, caches, message brokers) should be exposed via an addressable URL. Doing so decouples the resource from the application, enabling it to be interchangeable.
5 - Build, Release, Run	Each release must enforce a strict separation across the build, release, and run stages. Each should be tagged with a unique ID and support the ability to roll back. Modern CI/CD systems help fulfill this principle.
6 - Processes	Each microservice should execute in its own process, isolated from other running services. Externalize required state to a backing service such as a distributed cache or data store.
7 - Port Binding	Each microservice should be self-contained with its interfaces and functionality exposed on its own port. Doing so provides isolation from other microservices.
8 - Concurrency	When capacity needs to increase, scale out services horizontally across multiple identical processes (copies) as opposed to scaling-up a single large instance on the most powerful machine available. Develop the application to be concurrent making scaling out in cloud environments seamless.
9 - Disposability	Service instances should be disposable. Favor fast startup to increase scalability opportunities and graceful shutdowns to leave the system in a correct state. Docker containers along with an orchestrator inherently satisfy this requirement.
10 - Dev/Prod Parity	Keep environments across the application lifecycle as similar as possible, avoiding costly shortcuts. Here, the adoption of containers can greatly contribute by promoting the same execution environment.
11 - Logging	Treat logs generated by microservices as event streams. Process them with an event aggregator. Propagate log data to data-mining/log management tools like Azure Monitor or Splunk and eventually to long-term archival.
12 - Admin Processes	Run administrative/management tasks, such as data cleanup or computing analytics, as one-off processes. Use independent tools to invoke these tasks from the production environment, but separately from the application.

更後面又加了 3 個

New Factor	Explanation
13 - API First	Make everything a service. Assume your code will be consumed by a front-end client, gateway, or another service.
14 - Telemetry	On a workstation, you have deep visibility into your application and its behavior. In the cloud, you don't. Make sure your design includes the collection of monitoring, domain-specific, and health/system data.
15 - Authentication/ Authorization	Implement identity from the start. Consider RBAC (role-based access control) features available in public clouds.

不過以上都是核心概念，實際落地面怎麼做呢？

這時候就有 Azure Well-Architeded Framework

Azure Well-Architeded Framework

Azure Well-Architeded Framework 基本上就是微軟整理不同常見的 pattern 以及架構並且用 5 個面向來分析需要關注的點

Tenets	Description
Cost management	Focus on generating incremental value early. Apply Build-Measure-Learn principles to accelerate time to market while avoiding capital-intensive solutions. Using a pay-as-you-go strategy, invest as you scale out, rather than delivering a large investment up front.
Operational excellence	Automate the environment and operations to increase speed and reduce human error. Roll problem updates back or forward quickly. Implement monitoring and diagnostics from the start.
Performance efficiency	Efficiently meet demands placed on your workloads. Favor horizontal scaling (scaling out) and design it into your systems. Continually conduct performance and load testing to identify potential bottlenecks.
Reliability	Build workloads that are both resilient and available. Resiliency enables workloads to recover from failures and continue functioning. Availability ensures users access to your workload at all times. Design applications to expect failures and recover from them.
Security	Implement security across the entire lifecycle of an application, from design and implementation to deployment and operations. Pay close attention to identity management, infrastructure access, application security, and data sovereignty and encryption.