Microservices vs Monolithic สร้าง Web App ให้แข็งแรงด้วยสถาปัตยกรรมไหนดี

ในปัจจุบันเราคงปฎิเสธไม่ได้เลยว่าเครื่องมืออย่าง PC หรือ Smartphone เข้ามามีบทบาทในชีวิตของเรามากขึ้น เรามีการใช้โปรแกรมหรือ Application เพื่อทำให้เรื่องงานหรือ กิจกรรมต่างๆในชีวิตประจำวันนั้นสะดวกสบายมากขึ้น ไม่ทางตรงก็ทางอ้อม ยกตัวอย่าง หากเราต้องการหาข้อมูลเรื่องที่เราสงสัยหรืออยากศึกษา ก็จะใช้ Web Browser ในการค้นหาจนเจอได้โดยง่าย

Web Browser ไม่เพียงแค่ใช้ในการค้นหาข้อมูลเท่านั้น แต่ได้มีการพัฒนาให้สามารถใช้งานเสมือนเป็น App ผ่านทาง Web Browser ซึ่งการพัฒนาหรือออกแบบ App เหล่านี้ จำเป็นต้องทำอะไรบ้างนั้น ผู้เขียนขอนำเสนอการออกแบบ Web App ซึ่งเป็น App ประเภทหนึ่งที่ได้รับนิยมและใช้งานง่าย ว่าต้องรู้และเข้าใจอะไรบ้าง

Web app คืออะไร

Web App หรือ Web Application เป็น App ที่เราสามารถเข้าใช้งานได้ทาง Web Browser ไม่ว่าจะเป็น ใน OS ไหนก็ตาม ซึ่ง Web app ส่วนใหญ่จะสามารถใช้งานในรูปแบบ App ได้ซึ่ง User Interface (UI) และ Feature ไม่แตกต่างกันจาก Application ใน platform อื่นๆ เท่าไรนัก ตัวอย่าง Web App ที่นิยมใช้งานกัน ได้แก่ Gmail, Twitter, Facebook เป็นต้น

Web app ทำงานอย่างไร

Architecture ของ Web App มีลัษณะเป็น Client-server ที่ประกอบด้วย Code 2 ส่วนหลักๆ คือ

Client-side Script เป็นส่วนที่จัดการ UI อย่างปุ่มต่างๆ หรือ Drop-down เมื่อ User มีการคลิ๊ก Link ใน Web App ตัว Web Browser จะทำการโหลด Script เพื่อ Render Text หรือ Graphic Element ขึ้นมา ส่วนการคลิ๊กปุ่มอย่าง Submit เป็นการส่ง Request จากทาง Client ไปยัง Server
Server-side Script เป็นส่วนที่ Process ข้อมูล เมื่อ User มีการส่ง Request มายัง Server ก็จะทำการ Process แล้วส่งกลับไปทาง Client ยกตัวอย่าง User กรอกข้อมูล แล้วกดปุ่ม Submit มายัง Server แล้ว Server จะทำการเก็บเข้า Database

Image source https://damsak.medium.com/evolution-of-client-server-architecture-and-web-servers-cd58f60436f7

Layer ใน Web App Architecture

Web App ประกอบด้วย Layer หลักๆ 4 Layers ซึ่งแต่ละ Layer จะมี Function ในการทำงานเฉพาะอย่าง

Presentation Layer หรือ Client-side เป็นส่วนที่แสดง UI ทั้งหมดใน Web App
Business Layer เป็นส่วนที่มีการใช้ Logic ทำหน้าที่รับข้อมูลจาก Persistence Layer และส่ง Request กลับไปยัง Client-side ตาม Business Logic ซึ่ง Layer นี้อาจเรียกได้ว่า Logic Layer หรือ Application Layer
Persistence Layer หรือ Data Access Layer เป็นส่วนที่มีการอ่าน เขียนหรือจัดการ Database
Database Layer เป็นส่วนที่เก็บข้อมูลทั้งหมดของ Web App ไว้ในนี้

ในแต่ละ Layer เมื่อมีการเปลี่ยนแปลงจะไม่ส่งผลกระทบต่อ Layer อื่น ทำให้ลดปัญหาเวลา Web App ทำงานและช่วยให้มีความเสถียรขึ้น

Image source https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

Model ของ Web app

ใน Web App นั้น แบ่ง Model ได้ตามจำนวนของ Web Server และ Database ซึ่งแบ่งประเภทได้ดังนี้

1 Web Server, 1 Database เหมาะกับ Web App เล็กๆ ส่วนบุคคล ถ้า Web Server ล่ม Web App จะไม่สามารถใช้งานได้ ถ้า Database ล่ม ข้อมูลจะสูญหายทั้งหมด
2+ Web Servers, 1 Database ช่วยให้ Web Server ไม่ต้องรับ Load มากเกินไป และถ้าล่มก็ยังมีตัวสำรอง แต่ยังมีความเสี่ยงในเรื่องข้อมูลสูญหาย และคอขวดจากการรับ Load มากๆได้
2+ Web Servers, 2+ Database มีตัวสำรองทั้ง Server และ Database หรืออาจเลือกได้ว่ามี Redundancy แต่การมี Database มากกว่า 1 ตัว อาจมีความเสี่ยงในเรื่องของ Data Integrity และ Restore Integrity รวมถึงความซับซ้อนในการ Access ตัว Database ด้วย

Type ของ Web App Architecture

สำหรับ Web App นั้นมี Architecture หลายแบบ ไม่ว่าจะเป็น Single-page App, Server-Side Rendering หรือ Client-Side Rendering แต่ในที่นี่ทางผู้เขียนจะอธิบายในส่วนของ Monolithic และ Microservices

Monolithic คืออะไร

Monolithic Architecture คือ Architecture แบบหนึ่งของโปรแกรมที่เป็นยูนิตเพียงหนึ่งเดียว รวมการทำงานของหลายๆส่วนเข้าไว้ในตัวเดียวกัน เมื่อมีการแก้ไข Code เพียงส่วนใดส่วนหนึ่งต้องหยุดการทำงานทั้งโปรแกรม และเมื่อแก้ไขเสร็จแล้ว จะ Deploy เพื่อรันโปรแกรมแค่ครั้งเดียว

Image source https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Microservices คืออะไร

Microservices Architecture คือ Architecture แบบหนึ่งของโปรแกรมที่ถูกพัฒนาขึ้นมาจาก Monolithic ซึ่งแยกตัวโปรแกรมที่มีการทำงานต่างกันเป็นหลายๆ services และทำงานแบบไม่ขึ้นต่อกัน ไม่ว่าจะเป็นในเรื่องการ Deploy, Update, Test หรือการ Scale อาจเรียกได้ว่าเป็น Distributed System

Image source https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Microservices vs. Monolithic

ทั้งสองแบบต่างก็มีข้อได้เปรียบและข้อจำกัดแตกต่างกันออกไป ดังนี้

ข้อได้เปรียบของ Monolithic

Deploy ง่าย เนื่องจากมีตัว Executable File 1 ตัว จึง Deploy เพียงครั้งเดียว
ง่ายต่อการพัฒนา เพราะมี Code ที่ใช้รันโปรแกรมมี 1 ชุด
ประสิทธิภาพในการทำงานของ 1 API ต่อการรัน Function หนึ่งเทียบเท่ากับ Microservices หลายๆ API
ทำการทดสอบได้ง่าย เนื่องจากมี Code แค่ชุดเดียว เมื่อทำการเทสแบบ End-to-end หรือเทสทั้งระบบ จะทำได้รวดเร็วกว่า Microservices
Debug ได้ง่าย ถ้า Code รวมกันอยู่ในที่เดียว จะสามารถตรวจสอบเพื่อหา Issue ได้ง่าย

ข้อจำกัด ของ Monolithic

พัฒนาได้ช้า เนื่องจากเป็นการเขียน Code ให้ทุกอย่างทำงานร่วมกันใน 1 ชุด จึงต้องใช้เวลา
ไม่สามารถ Scale Component ตัวใดตัวหนึ่งในโปรแกรมได้โดยไม่กระทบกับ Component อื่น
ถ้ามี Error เกิดขึ้นจากส่วนใดส่วนหนึ่งในโปรแกรม อาจทำให้โปรแกรมใช้ไม่ได้
เมื่อต้องเปลี่ยนไปใช้ Tool หรือภาษาใหม่ๆ จะทำให้มีผลกระทบทั้งโปรแกรม ซึ่งใช้เงินและเวลามหาศาล
ไม่มีความยืดหยุ่น Architecture แบบ Monolithic จะสามารถใช้เทคโนโลยีที่ใช้ได้อยู่แล้วใน Architecture แบบนี้
Deployment บ่อยครั้ง ถ้ามีการแก้ไขหรือเปลี่ยนแปลงข้างใน ถึงจะเป็นส่วนเพียงเล็กน้อย แต่ต้อง Deployment ทั้งตัวโปรแกรม

ข้อได้เปรียบของ Microservices

แบ่งทีมพัฒนาโปรแกรมได้ง่ายเพราะมีหลาย Services
Scale ได้ง่าย ถ้า Service 1 Service รับ Load ใกล้เต็มแล้ว จะมีการสร้าง Instance ตัวใหม่ขึ้นมาเพื่อรองรับ Load ที่เกิดขึ้น
Deploy ได้ต่อเนื่องขึ้น ไม่ต้องรอ Test ทั้งหมดเพื่อตรวจสอบว่าโปรแกรมสามารถทำงานได้ เมื่อมีการแก้ไขหรือเปลี่ยนแปลง
Maintain และเทสได้ง่ายขึ้น เพราะมีการแบ่งเป็นหลายๆ Services ทำให้แก้ไขหรือเทสแต่ Services ได้โดยไม่กระทบกับ Service อื่น
มี Reliability สูงแต่ละ Services แยกกัน Deploy ได้โดยไม่ขึ้นกับ Service อื่น และไม่ต้องกังวลว่าจะทำให้โปรแกรมล่ม
ทีมพัฒนาสามารถเลือกใช้ Tool เพื่อพัฒนาได้อย่างอิสระ

ข้อจำกัดของ Microservices

มีความยุ่งยากในการพัฒนาเมื่อเทียบกับแบบ Monolithic เนื่องจากหลายๆ Services ถูกพัฒนาด้วยหลายๆผู้พัฒนา ถ้ามีการจัดการไม่ดีพอ จะทำให้การพัฒนาเป็นไปได้ช้า
มีค่าใช้จ่ายสูง เนื่องจากแต่ละ Services ก็มีค่า Test, Deploy, Monitoring และ Cloud ในส่วนของแต่ละ Services
ต้องมีการวางแผนการพัฒนาให้ดีหรือสื่อสารให้เข้าใจกันเพราะมีโอกาสผิดพลาดสูง
Debug ได้ยาก เพราะแต่ละ Services ก็มี Log ในรูปแบบของตัวมันเอง ซึ่งเพิ่มความซับซ้อนใน Debug มากยิ่งขึ้น
อิสระในการเลือกใช้ Tool หรือภาษาที่ใช้ที่หลากหลายเกินไป อาจทำให้ต้องใช้หลาย Convention ในการตรวจสอบหรือพัฒนา

Image source https://www.suse.com/c/rancher_blog/microservices-vs-monolithic-architectures/

สามารถอ่านเรื่อง Monolithic และ Microservices เพิ่มเติมจากบทความทาง CloudHM ได้ ที่นี่

ในการออกแบบ Web App ไม่ว่าจะเลือกใช้เป็นแบบ Monolithic หรือ Microservices ต่างก็มีส่วนของ Database ที่สัมพันธ์กับการทำงานใน Architecture ทั้งสองแบบ ซึ่งผู้เขียนขออธิบายในส่วนต่อไป

Database คืออะไร

Database คือที่ที่ข้อมูลถูกจัดเก็บไว้อย่างเป็นระเบียบ และเป็นหมวดหมู่ สามารถเข้าถึงได้จากระบบคอมพิวเตอร์ โดยปกติแล้ว Database จะถูกจัดการด้วย Software ที่เรียกว่า Database Management System หรือ DBMS เสมือนเป็นตัวกลางระหว่าง User และ Database โดย User สามารถที่จะจัดการข้อมูลข้างใน Database โดยการ สร้าง-อ่าน-อัพเดทหรือลบข้อมูลได้

Image source https://www.kaashivinfotech.com/blog/difference-between-dbms-and-rdbms/

ต่อมาได้มีการพัฒนาตัว DBMS ขึ้นมาเป็น Relational Database Management System หรือ RDBMS ซึ่งใช้ Structured Query Language หรือ SQL เป็นภาษาที่ใช้ในการจัดการ Database แบบ Relational Database ที่มีการจัดเก็บข้อมูลเป็นตาราง ซึ่งมี Rows และ Columns ข้อมูลแบบนี้อาจเรียกได้ว่าเป็น Structured Data หรือข้อมูลที่มีรูปแบบชัดเจน

Image source https://sqlrelease.com/sql-server-tutorial/dbms-rdbms-and-sql-server

เมื่อ Internet เริ่มใช้กันอย่างแพร่หลาย ได้มีการพัฒนา App ประเภท Web-base หรือ Web App กันมากขึ้น นำไปสู่การพัฒนา Database แบบใหม่เพื่อจัดการกับข้อมูล Unstructured Data อย่าง Non-Structured Query Language หรือ NoSQL ซึ่งหลักๆแบ่งออกเป็น 4 แบบ ดังนี้

Document Store ข้อมูลและ Metadata ถูกเก็บเป็นลำดับชั้นในรูปแบบ Semi-structure Data ยกตัวอย่างเช่น JSON หรือ XML ใน Database
Key Value Store เป็นรูปแบบที่ง่ายที่สุดของ NoSQL ซึ่งข้อมูลจะถูกเก็บในรูปแบบของ Key-value
Wide-Column Store ข้อมูลที่ relate กันจะถูกเก็บในรูปแบบ Nested-key/value Pairs ซึ่งจะเก็บมากกว่า 1 ค่าใน 1 Column
Graph Store ข้อมูลจะถูกเก็บในโครงสร้างแบบ Graph ซึ่งจะมีความเชื่อมโยงกันของข้อมูลแต่ละส่วน

Image source https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/relational-vs-nosql-data

SQL และ NoSQL ใน CAP Theorem

CAP Theorem นั้นเป็นกฏสำหรับ Distributed System อย่าง Microservices ที่ว่า Database สามารถมีคุณสมบัติได้เพียง 2 ใน 3 เท่านั้น ซึ่งทั้ง 3 คุณสมบัตินั้นมีดังนี้

Consistency ข้อมูลใน Database ต้องเป็นข้อมูลล่าสุดเสมอ
Availability สามารถเข้าถึงข้อมูลใน Database ได้ตลอดเวลา ถึงแม้ว่า Node จะล่มไปแล้ว
Partition Tolerance สามารถใช้งาน Function ใน Database ได้ ถึงแม้ว่า Node จะไม่สามารถสื่อสารกันได้

Relational Database ที่ใช้ SQL นั้นเป็นแบบ CA ที่มี Consistency และ Availability ทำให้ข้อมูลใน Database นั้นมีความแม่นยำ ไม่เสียหาย และสามารถเรียกข้อมูลได้ตลอดเวลา ในความเป็นจริง CA นั้นไม่สามารถใช้ได้กับ Distributed System อย่าง Microservices เพราะต้องมี Partition จากการมี Node ที่เชื่อมต่อกับ Database มากกว่า 1 Node ทำให้พบได้จาก Monolithic เท่านั้น

ส่วน Non-relational Database ที่ใช้ NoSQL จะมีทั้งแบบ AP และ CP นั้น ซึ่งมี Partition Tolerance ทั้ง 2 แบบเพื่อทำให้ใช้งานได้เร็วขึ้น

ถ้าเป็นแบบ AP เมื่อ Node อย่างน้อย 2 Node ไม่สามารถสื่อสารกันได้ จะถูกทำให้ Out of Sync หรือ ข้อมูลไม่ตรงกัน
ถ้าเป็นแบบ CP เมื่อ Node อย่างน้อย 2 Node ไม่สามารถสื่อสารกันได้ Database จะไม่สามารถใช้งานได้จนกว่า แต่ละ Node จะ Sync ข้อมูลให้เสร็จก่อน Database ถึงทำงานได้

Image source https://mytechnetknowhows.wordpress.com/2016/05/31/cap-theorem-consistency-availability-and-partition-tolerance/

สามารถอ่านเรื่อง SQL และ NoSQL เพิ่มเติมจากบทความทาง Cloud HM ได้ ที่นี่

Data consistency คืออะไร

Data Consistency เป็นคุณสมบัติที่บ่งบอกว่าทุกๆ Node ในระบบจะมีชุดข้อมูลที่เหมือนกัน ซึ่งใช้กับ Database ใน Distributed System อย่าง Microservices

Data Consistency สามารถแบ่ง Model ออกได้เป็น 2 Model ได้แก่

Strong Consistency เป็นการการันตีว่าข้อมูลที่ถูกเขียนเสร็จแล้ว จะสามารถอ่านข้อมูลนั้นได้ทันที
- ข้อได้เปรียบของ Strong Consistency คือ มั่นใจได้ว่า User จะได้รับข้อมูลล่าสุดแน่นอน เข้าใจง่าย และข้อมูลมี Reliability
- ข้อจำกัดของ Strong Consistency คือ Latency ที่สูงเนื่องจากต้องรอให้ทุก Node นั้น Sync กันเสร็จก่อนถึงจะอ่านข้อมูลนั้นได้ เมื่อ Node ใด Node หนึ่งในระบบล่ม จะไม่สามารถเข้าถึงข้อมูลได้ และสามารถ Scale ได้ยาก

Image source https://medium.com/@abhirup.acharya009/strong-consistency-vs-eventual-consistency-19ce6f87c112

Eventual Consistency เป็นการการันตีว่าข้อมูลที่ถูกเขียนเสร็จแล้ว จะไม่มีการเปลี่ยนแปลง ซึ่งการอ่านข้อมูลนั้นในทันทีอาจจะไม่ได้อ่านข้อมูลที่เพิ่งถูกเขียนไป ต้องรอจนกว่าทุก Node ในระบบจะทำการ Sync จนเสร็จ
- ข้อได้เปรียบของ Eventual Consistency คือ การ Scale ที่สามารถเพิ่ม Node ในระบบได้โดยไม่ต้องกังวลการ sync ข้อมูล เพราะสามารถอ่านได้ตอนเวลา ส่งผลให้ Latency น้อย และเมื่อ Node ใด Node หนึ่งในระบบล่ม จะยังสามารถเข้าถึงข้อมูลใน Node อื่นๆได้
- ข้อจำกัดของ Eventual Consistency คือ มีช่วงเวลาที่ข้อมูลในแต่ละ Node ในระบบไม่เหมือนกัน ซึ่งอาจส่งผลให้ user ได้รับข้อมูลที่ไม่เป็นปัจจุบันได้

Image source https://medium.com/@abhirup.acharya009/strong-consistency-vs-eventual-consistency-19ce6f87c112

Database Partitioning คืออะไร

Database Partitioning หรือ Data Partitioning คือ วิธีการแบ่งชุดข้อมูลที่มีขนาดใหญ่มากๆ ออกเป็นหลายๆส่วนที่มีขนาดเล็กลงมา เพื่อให้จัดการได้ง่ายขึ้น แต่ละส่วนที่ถูกแบ่งออกมาจะเรียกว่า Partition

การทำ Data Partitioning นั้น หลักๆ แบ่งออกได้ 3 แบบ ดังนี้

Horizontal Partitioning เป็นการแบ่งชุดข้อมูลด้วย Row หรือ Record ซึ่ง Partition ที่ได้จากการแบ่งจะมี Column เหมือนกัน เป็นวิธีที่ทำให้สามารถเข้าถึงหรือเปลี่ยนแปลงข้อมูลใน Partition แต่ละส่วนแยกจากกันได้ อาจเรียกวิธีนี้ได้ว่า Row Partitioning ซึ่งสามารถแบ่งประเภทของ Row Partitioning ได้ออกเป็นหลายแบบ ยกตัวอย่างเช่น Range Partitioning, List Partitioning, Hash Partitioning หรือ Composite Partitioning

Image source https://learn.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning

Vertical Partitioning เป็นการแบ่งชุดข้อมูลด้วย Column หรือ Attribute ซึ่ง Partition ที่ได้จากการแบ่งจะมี Record ใน Attribute เดียวกัน เป็นวิธีที่จัดกลุ่ม Attribute ที่มีความสัมพันธ์กันอยู่ใน partition เดียวกัน ซึ่งช่วยลดเวลาในการอ่านข้อมูลลง ทำให้ retrieve ข้อมูลได้เร็วขึ้น อาจเรียกวิธีนี้ได้ว่า column partitioning

Image source https://learn.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning

Functional Partitioning เป็นการแบ่งชุดข้อมูลแบบเฉพาะเจาะจงตาม Function ที่ใช้งานกับข้อมูลนั้นๆ ยกตัวอย่างรูปด้านล่าง ที่มีข้อมูล 2 ชุด ซึ่งมีข้อมูลสำหรับอ่านอย่างเดียว กับตัวแปรสำหรับอ่านและเขียนด้วย

Image source https://learn.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning

ถึงแม้ว่าวิธีการอย่าง Row และ Column Partitioning นั้นจะดูเหมือนใช้ได้แค่กับ Structured Data ในรูปแบบ Table ที่มีใน Relational Database ซึ่งใช้ SQL แต่ในความเป็นจริงแล้วสามารถใช้ได้กับ Non-relational Database ที่ใช้ NoSQL โดยเฉพาะ Unstructured Data ที่ยึดกับ Partition Key มากกว่า Row หรือ Column ซึ่ง Row Petitioning หรือ Sharding นั้นมี Replication หรือการ Copy ชุดข้อมูลตามมาด้วยเพื่อนำไปใช้กับ Node อื่นๆ ให้มีชุดข้อมูลที่เหมือนกัน เป็นวิธีที่ใช้กันใน Non-relational Database

Image source https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/

จุดประสงค์ในการทำ Partition นั้นเพื่อเพิ่มประสิทธิภาพในการเข้าถึงข้อมูล โดย Query จาก Partition นั้นเร็วกว่าการ Query จากทั้ง Database แน่นอน รวมถึง Scalability ที่เพิ่มขึ้นจากการทำ Sharding ทำให้สามารถเข้าข้อมูลที่กระจายอยู่หลายๆ Partition เชื่อมต่อแต่ละ Node โดยไม่เกิดการคอขวดได้ เหมาะกับ Microservices และยังเพิ่ม Security จากการทำ Partition แบ่งข้อมูลทั่วไปและข้อมูลที่ Sensitive ได้

Best Practices สำหรับการเลือกใช้ Database ในการออกแบบ Web App

ในการเลือกใช้ Database ให้เหมาะสมนั้นขึ้นอยู่กับว่าต้องการจุดเด่นแบบไหน

– ถ้าต้องการ Web App ที่ Scalability สูงและจะมีการพัฒนาอีกนาน ควรเลือกใช้ ์Non-relational Database ที่ใช้ NoSQL มีคุณสมบัติ Eventual Consistency และใช้ Sharding ได้

– ถ้าต้องการ Web App ที่ Maintainability สูงและใช้งานอีกนาน ควรเลือกใช้ Relational Database ที่ใช้ SQL มีงมีคุณสมบัติในการรักษาข้อมูลให้ถูกต้องและสอดคล้องกันตลอดเวลา

– ถ้าต้องการ Web App ที่ Performance สูง ยิ่งเร็วยิ่งดี ควรเลือกใช้ Non-relational Database ที่ใช้ NoSQL มีคุณสมบัติ Eventual Consistency และใช้ Vertical Partitioning ได้

จากจุดเด่นทั้ง 3 ที่กล่าวไปแม้ว่า Microservices จะสามารถทำได้ดีกว่า แต่ Monolithic ก็มีจุดเด่นอื่นๆอย่างสามารถใช้งานได้ง่าย ไม่ซับซ้อน และยังมี performance สูงเพราะใช้ node เพียง 1 node ทำให้ตัดปัญหาเรื่อง latency สูงที่มักพบใน Microservices ที่มีการจัดการไม่ดีพอ

มาถึงตรงนี้ ผู้เขียนหวังว่าผู้อ่านทุกท่านจะเข้าใจ และสามารถนำความรู้ที่ได้ไปเลือกใช้ให้เหมาะสมกับ Web app ของทางผู้อ่านเอง ไม่มากก็น้อย ซึ่งถ้าผู้อ่านต้องการผู้เชี่ยวชาญด้าน Database as a Service ผู้อ่านสามารถติดต่อกับ Cloud HM เพื่อขอคำปรึกษาในการดำเนินการได้เลย

Reference:

https://aws.amazon.com/what-is/web-application/

https://www.netsolutions.com/insights/web-application-architecture-guide/

https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

https://www.simplilearn.com/tutorials/dbms-tutorial/what-is-a-database

https://www.oracle.com/th/database/what-is-database/

https://betterprogramming.pub/what-is-the-cap-theorem-and-where-is-it-used-363475aa8db6

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/relational-vs-nosql-data

https://www.scylladb.com/glossary/cap-theorem/

https://airbyte.com/data-engineering-resources/what-is-data-partitioning

https://dimosr.github.io/partitioning-and-replication/

https://www.designgurus.io/answers/detail/what-is-strong-vs-eventual-consistency