ไมโครซอฟท์ส่งโครงการ Dapr เข้า CNCF Incubator

โครงการ Dapr ระบบรันไทม์สำหรับสร้าง microservice เข้าเป็นโครงการของ CNCF Foundation มูลนิธิที่ทำหน้าที่ดูแลโครงการ Kubernetes และโครงการแวดล้อมอื่นๆ โดยเข้าเป็นโครงการระดับ incubating ที่แสดงว่าโครงการเริ่มมีการใช้งานหลากหลาย

แม้โครงการ Dapr จะเริ่มต้นโดยไมโครซอฟท์ แต่ในกรรมการดูแลโครงการตอนนี้ก็มีตัวแทนจาก อาลีบาบา, อินเทล, และไมโครซอฟท์ ดูแลร่วมกัน โดยไมโครซอฟท์เปิดตัวโครงการนี้เมื่อปี 2019 แม้ชื่อโครงการจะบอกว่าเป็น runtime แต่แอปพลิเคชั่นจะเชื่อมต่อกับบริการต่างๆ ของ Dapr ผ่านทาง HTTP หรือ gRPC เท่านั้น โดยตัวบริการช่วยให้แอปพลิเคชั่นสามารถเรียกใช้บริการต่างๆ เช่น message queue, จัดการสถานะ, ไปจนถึงการทำ tracing

โครงการในระดับ Incubator แสดงความเป็นโครงการกลางที่ไม่ผูกติดกับผู้ผลิตรายใดรายหนึ่งแล้ว โครงการระดับเดียวกันในกลุ่ม เช่น Argo, CNI, Contour, Flux, gRPC, KEDA, Natary เป็นต้น

บริการ Azure Container Apps ของไมโครซอฟท์ที่เพิ่งเปิดบริการไปเมื่อวานนี้ก็เป็นบริการที่อาศัย Dapr อย่างหนัก

ที่มา – CNCF, Dapr

Topics: 

CNCF

Microsoft

microservice

from:https://www.blognone.com/node/125658

Dapr โครงการรันไทม์โอเพ่นซอร์สสำหรับพัฒนาไมโครเซอร์วิสออกเวอร์ชัน 1.0 แล้ว

Dapr โครงการรรันไทม์โอเพ่นซอร์สจาก Microsoft เพื่อการพัฒนาแอปแบบ event-driven โดยเฉพาะไมโครเซอร์วิสเข้าสู่เวอร์ชัน 1.0 และพร้อมใช้งานในโปรดักชั่นแล้ว

Dapr ย่อมาจาก Distributed Application Runtime เปิดตัวโครงการครั้งแรกเมื่อปลายปี 2019 ออกอัพเดตมาแล้ว 14 ครั้ง รองรับคลาวด์รายใหญ่หลายเจ้า ทั้ง AWS, GCP, Azure และ Alibaba ซึ่งตอนนี้โครงการมีผู้ร่วมส่งโค้ดราว 700 คน และมีองค์กรบางแห่งเริ่มใช้งานในโปรดักชั่นบ้างแล้ว

Mark Russinovich ซีทีโอของ Azure ระบุว่า โครงการ Dapr เกิดขึ้นมาเพื่อช่วยองค์กรที่ระบบไอทีเป็นรูปแบบดั้งเดิม คือไคลเอนท์, เซิร์ฟเวอร์, เว็บ, ฐานข้อมูล แต่ตอนนี้ต้องทำแอปแบบคอนเทนเนอร์เพื่อสร้างไมโครเซอร์วิสสำหรับ scale-out และอัพเดตแบบไม่มีดาวน์ไทม์ รวมถึงอินทิเกรตกับบริการคลาวด์ต่าง ๆ และต้องย้ายไปมาระหว่าง on-premise กับคลาวด์หลาย ๆ บริษัทได้

โครงการ Dapr จึงพัฒนาเป็นรันไทม์ตัวเดียวเพื่อให้นักพัฒนาที่ต้องการสร้างไมโครเซอร์วิสแบบ event-driven มี building blocks สำหรับการคุยกันระหว่างเซอร์วิส, การจัดการสถานะ, pub/sub และระบบจัดการ secret เพื่อให้นักพัฒนาโฟกัสกับงานส่วนของโค้ดเป็นหลัก

ที่มา – TechCrunch, Dapr.io

Topics: 

Microsoft

microservice

Open Source

from:https://www.blognone.com/node/121243

ซอยย่อยเกินไป Istio รวบไบนารีหลักเหลือ istiod ตัวเดียว แม้เป็นแพลตฟอร์มทำ microservice

โครงการ Istio ที่เป็นแพลตฟอร์มทำ service mesh ควบคุมการสื่อสารระหว่าง microservice ประกาศเปลี่ยนสถาปัตยกรรมใหม่ จากเดิมเซิร์ฟเวอร์หลักแบ่งเป็นส่วนย่อยๆ ถึง 5 ชิ้น ได้แก่ Mixer, Pilot, Gallery, Citadel, และ Injector มาเหลือ istiod ไบนารีเดียวเท่านั้น โดย Mixer เป็นส่วนขยายที่ลงแยกได้ และเวอร์ชั่นใหม่จะไม่ลงเป็นค่าเริ่มต้น

สำหรับซอฟต์แวรร์ที่รันบนโหนดก็จะรวบจาก Node Agent และ Istio Agent เหลือ Istio Agent ตัวเดียวเช่นกัน

Christian Posta ผู้เขียนหนังสือ Microservices for Java Developers เขียนบล็อกกถึงเรื่องนี้ ว่า Istio เป็นตัวอย่างของกรณีที่ไม่ควรแบ่งแอปพลิเคชั่นเป็น microservice ด้วยเหตุผลหลักคือระบบจะซับซ้อนขึ้นมาก และคำถามสำคัญคือ “แต่ละชิ้นสามารถ deploy แยกกันได้จริงหรือไม่”ปรากฎว่าในโลกความเป็นจริงไม่มีใครติดตั้งชิ้นส่วนของ Istio แยกกันนัก มักจะอัพเกรดไปพร้อมๆ กัน แถมในแง่ความปลอดภัย ชิ้นส่วนย่อยๆ ของ Istio ก็มีสิทธิ์เท่ากันอยู่ดี

Istio จะเปลี่ยนสถาปัตยกรรมในเวอร์ชั่น 1.5 โดยตอนนี้อยู่ที่สถานะ beta 5 คาดว่าจะออกตัวจริงได้ภายในเดือนนี้

ที่มา – Istio Blog

Topics: 

Istio

microservice

from:https://www.blognone.com/node/115020

ผู้เขียนหนังสือ Building Microservices ชี้องค์กรกว่าครึ่งใช้ monolith แบบเดิมๆ เหมาะกับคนส่วนใหญ่ อย่าเร่งไป Microservice

Sam Newman ผู้เขียนหนังสือ Building Microservices และ Monolith to Microservices ขึ้นพูดในงาน QCon ที่ลอนดอนระบุถึงกระแสของนักพัฒนาที่พยายามพัฒนาทุกอย่างให้เป็น microservice ไปเสียหมดว่าไม่เหมาะ

เขาระบุว่ากระแส microservice ตอนนี้เหมือนยุค 1980 ที่คนทำงานไอทีมักพูดกันว่า “ไม่มีใครถูกไล่ออกเพราะซื้อไอบีเอ็ม” และคนทำงานมักเกาะกระแสนพยายามอิมพลีเมนต์แอปพลิเคชั่นให้เป็น microservice ไปเสียหมด แต่หลังจากทำไปก็จะพบว่าสถาปัตยกรรมซับซ้อนเกินไป

Sam เล่าถึงกรณีที่แย่กว่านั้นคือการซอยแอปพลิเคชั่นออกเป็นส่วนย่อยๆ อย่างผิดๆ ทำให้ไม่ได้แอปที่เป็น microservice แต่กลับเป็นแอปแบบ monolith แบบกระจายตัวที่เอาเข้าจริงแล้วแอปแต่ละส่วนไม่สามารถอัพเดตแยกจากกันได้ แต่ต้องอัพเดตไปพร้อมๆ กันทั้งยวง

เขาเล่าถึงซอฟต์แวร์ในบริษัท Segment ที่ทำงานด้านวิเคราะห์ข้อมูลที่สุดท้ายต้องปรับแอปเป็น monolith เพราะพบว่านักพัฒนาทำงานช้าลงเรื่อยๆ ขณะที่ซอฟต์แวร์แบบ monolith เองหากออกแบบได้ดีก็สามารถแบ่งย่อยเป็นโมดูลได้เหมือนกัน

เขาให้สัมภาษณ์กับ The Register ระบุว่าคนทำงานควรหาคอขวดของระบบให้ดี และการแปลงแอปเป็น microservice ควรเป็นทางเลือกสุดท้าย

ที่มา – The Register

ภาพชุดเฟืองโดย MustangJoe

Topics: 

microservice

from:https://www.blognone.com/node/114994

ไมโครซอฟท์เปิดโครงการ Dapr รันไทม์โอเพนซอร์สสำหรับการพัฒนา microservice

ไมโครซอฟท์เปิดตัวโครงการ Dapr รันไทม์แบบ event driven สำหรับการพัฒนา microservice ช่วยจัดการงานที่ต้องทำบ่อยๆ ในการพัฒนา โดยในเวอร์ชั่นอัลฟ่าบริการเหล่านี้ได้แก่

• Service invocation: การเรียกใช้งานระหว่างบริการต่างๆ
• State management: จัดการเก็บสถานะลงของ microservice ลงฐานข้อมูล โดยตอนนี้รองรับ Redis และ Azure Cosmos แต่เตรียมจะรองรับบริการอื่น เช่น AWS DynamoDB
• Pub/Sub: รอข้อความใน message queue ตามหัวข้อที่ตัว microservice ต้องการ
• Event driven resource bindings: รอรับ event และยิง event ออกจาก microservice
• Virtual actor: รันไทม์จัดการการเรียกโค้ดให้เป็นเธรดเดียวเสมอในแต่ละ actor
• Distributed tracing: รองรับการติดตามการประมวลผลในแต่ละจุด โดยทำงานร่วมกับ OpenTelemetry

ตัวโค้ดแอปพลิเคชั่นสามารถสื่อสารกับ Dapr ผ่านทาง HTTP หรือ gRPC ก็ได้ ถ้าต้องการใช้ Dapr SDK โดยตรงก็รองรับภาษา Go, Java, Javascript, Python, และ .NET Core

ไมโครซอฟท์ตั้งเป้าจะให้ Dapr เป็นโครงการที่ไม่ผูกติดกับผู้ผลิตรายใด และการเปิดโครงการนี้ก็ต้องการเสียงตอบรับจากนักพัฒนาว่าต้องการให้ Dapr ทำงานร่วมกับอะไรอีกบ้าง

ที่มา – Microsoft Cloud Blog

Topics: 

Microsoft

microservice

Open Source

from:https://www.blognone.com/node/112583

IBM, Google, และ Lyft ร่วมมือพัฒนา Istio แพลตฟอร์มจัดการ Microservice

ปัญหาที่ตามมากับการพัฒนาแอพพลิเคชันในรูปแบบ microservice นั้นคงจะหนีไม่พ้นการจัดการกับ microservice ทั้งหลาย ไม่ว่าจะเป็นการทำ service discovery, การติดตั้ง load balancer, หรือการดูแลให้ทุกๆส่วนในระบบทำงานไปได้โดยไม่สะดุด แต่ในวันนี้ IBM, Google, และ Lyft ได้ร่วมมือกันพัฒนาแพลตฟอร์ม Istio มาเพื่อดูแลจัดการกับ microservices ต่างๆโดยเฉพาะ

จุดเริ่มต้นของการร่วมมือพัฒนา Istio ครั้งนี้ประกอบไปด้วยระบบและเทคโนโลยีที่แต่ละบริษัทมีอยู่แล้ว อันได้แก่

• Amalgam8 ของ IBM – โปรเจคโอเพ่นซอร์สที่มุ่งเน้นไปที่การกำกับ traffic ในระบบที่มาพร้อมกับ programmable control plane ซึ่งช่วยให้องค์กรสามารถทำ A/B testing, การทำ canary release (การปล่อยซอฟต์แวร์อีกเวอร์ชั่นให้ผู้ใช้ส่วนน้อยได้ใช้งานก่อนเปลี่ยนไปใช้เวอร์ชั่นใหม่ทั้งหมด), และการทดสอบความแข็งแกร่งของระบบ
• Service Control ของ Google – ระบบควบคุมที่เน้นไปที่การสร้างและใช้งาน policy ต่างๆ เช่น ACL, ลิมิตการใช้งาน, หรือการทำ authentication ซึ่งนอกจากสิ่งเหล่านี้แล้วยังสามารถเก็บข้อมูลภายในระบบและ proxy ได้ด้วย
• Envoy proxy ของ Lyft – edge และ service proxy ซึ่งถูกพัฒนาขึ้นมาเพื่อ microservice โดยเฉพาะ ซึ่งถูกใช้งานจริงในบริษัทกับกว่า 10000 VMs ที่มี microservice มากกว่า 100 ตัว

Istio นั้นทำงานด้วยการเพิ่ม layer ในการ routing และการจัดการเข้าไปในระบบที่ประกอบไปด้วย microservice ต่างๆ เมื่อเพิ่มเซิฟเวอร์ Envoy proxy เข้าไปใน network ระบบ Istio จะเข้ามาจัดการกำกับดูแล traffic ในระบบ เช่น การทำ load-balancing และ การทำ fine-grained routing หลังจากนั้น ผู้ใช้ก็จะสามารถเปิดใช้งานการ authentication และ authorization ระหว่างการสื่อสารของ service ใดๆก็ตาม ผ่าน TLS authentication ที่มีการจัดการ certificate อัตโนมัติโดยระบบ

Credit: IBM Blog

การทำงานของ Istio นั้นจะรวมไปถึงการเก็บข้อมูลสถิติต่างๆในระบบซึ่ง 1) สามารถนำไปใช้ในการตั้งค่าในระบบ เช่นการตั้งลิมิตการใช้งาน และ 2) จะถูกส่งไปยังระบบ monitoring โดยไม่ต้องตั้งค่าหรือเขียนโค้ดเพิ่มมากมายแต่อย่างใด

Feature เด่นๆของ Istio มีดังนี้

• Zone-aware load balancing และ failover แบบอัตโนมัติสำหรับ HTTP/1.1, HTTP/2, gRPC, และ TCP
• การควบคุมพฤติกรรม traffic แบบ fine-grained มาพร้อม routing rules หลากหลายรูปแบบ, การทำ fault tolerance, และการทำ fault injection
• Policy layer ที่สามารถตั้งค่าได้สำหรับการตั้ง access control, rate limits, และโควต้าการใช้งาน
• การเก็บข้อมูลสถิติ, logs, และ traces สำหรับ traffic ในคลัสเตอร์ รวมถึงปริมาณ traffic เข้าออกในคลัสเตอร์
• การ authentication ที่ปลอดภัยระหว่าง service ต่างๆ ที่มีการทำ strong identity assertions ระหว่าง service ภายใน cluster เดียวกันด้วย

ปัจจุบัน Istio ยังทำงานร่วมกับคลัสเตอร์ Kubernetes เท่านั้น แต่ในอนาคตทางทีมพัฒนามีแผนที่จะขยายไปยังแพลตฟอร์มอื่นๆ สำหรับท่านใดที่สนใจสามารถเข้าไปอ่านข้อมูลเพิ่มเติมและทดลองดาวน์โหลดแอพลิเคชันตัวอย่างได้ที่ https://istio.io/docs/ หรือใน GitHub ที่ https://github.com/istio/

 

ที่มา: https://developer.ibm.com/dwblog/2017/istio/

from:https://www.techtalkthai.com/istio-microservice-mesh-ibm-google-lyft/

ทำความรู้จักกับ Microservices สถาปัตยกรรมระบบที่ทั้งนักพัฒนา และผู้ดูแลระบบควรรู้จัก

ช่วงสองสามปีที่ผ่านมา หลายๆคนคงได้ยินคำว่า Microservices มาไม่มากก็น้อย

ในวงการไอทีต่างประเทศ สถาปัตยกรรมแบบ Microservices ได้ถูกนำมาใช้งานในบริษัทใหญ่ๆ (Amazon, Netflix ) มาเป็นเวลาหลายปีแล้ว  ช่วง 2-3 ปีที่ผ่านมา แนวคิดของสถาปัตยกรรมแบบนี้เริ่มตื่นตัว และถูกนำไปใช้อย่างแพร่หลายมากขึ้น บ้างก็ประสบความสำเร็จเป็นอย่างดี บ้างก็ประสบปัญหา ได้รับบาดแผลกันมาพอสมควร

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

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

 

ตัวอย่างและนิยามของ Microservices

สมมติว่าเราต้องการพัฒนาระบบ E-banking ของธนาคาร เราสามารถแตกระบบออกเป็นส่วนย่อยๆได้ ดังนี้

• Authentication – สำหรับล็อคอินเข้าสู่ระบบ
• Account Balance – สำหรับตรวจสอบยอดเงินของผู้ใช้
• Payment – สำหรับโอน/จ่ายเงิน
• SMS Verification- สำหรับใช้ยืนยันผู้ใช้ผ่านทาง SMS
• ฯลฯ (ในที่นี้ยกตัวอย่างแบบไม่ซับซ้อน ระบบธนาคารจริงมีรายละเอียดเยอะกว่านี้มากๆครับ )

ในการพัฒนา เราสามารถเขียนระบบของทั้งหมดรวมกันเป็นชิ้นเดียว (ถ้าเป็น Java ก็อยู่ใน JAR หรือ WAR file เดียวกัน) แล้วนำไปวางบนเว็บเซอร์เวอร์ที่เดียว โดยเราเรียกสถาปัตยกรรมแบบนี้ว่า Monolith

แต่ถ้าเป็นสถาปัตยกรรม Microservices เราจะแยกพัฒนาแต่ละเซอร์วิซออกจากกันโดยชัดเจน โดยกำหนด API ไว้ให้เรียกใช้ แต่ละเซอร์วิซสามารถทำงานได้อย่างเป็นอิสระ มีฐานข้อมูลเป็นของตัวเอง และหากจำเป็นต้องใช้ข้อมูลที่อยู่ในเซอร์วิซอื่น ก็สามารถเรียกใช้ผ่าน API

เมื่อลูกค้าต้องการเช็คยอดเงิน จะสามารถติดต่อไปยัง Account Balance Service  เพื่อดึงข้อมูลออกมา  หากต้องการโอนเงิน ก็จะมีการติดต่อไปยัง Payment Service ซึ่งจะเรียก API ของ SMS Verification service อีกทอดนึง เพื่อทำการส่ง SMS สำหรับยืนยันการโอน

ถึงจุดนี้ เราน่าจะเห็นภาพคร่าวๆแล้วว่า Microservices คืออะไร บางคนอาจจะเริ่มคิดในใจว่า “เฮ้ย นี่มันก็คือ SOA (Service-oriented Architecture) ดีๆนี่เอง”  ซึ่งเป็นความคิดที่ถูกต้องครับ Microservices เป็นรูปแบบหนึ่งของ SOA  ซึ่งมีลักษณะพิเศษเพิ่มอีกหลายอย่าง

เพื่อให้ชัดเจนยิ่งขึ้นว่าลักษณะพิเศษเหล่านี้คืออะไร เราจะมาลองดูสถาปัตยกรรมแบบอื่นๆที่ ไม่ใช่ Microservices กันครับ

 

จุดเด่นของ Microservices เมื่อเปรียบเทียบกับสถาปัตยกรรมแบบอื่นๆ

ส่วนที่แล้ว ผมได้เปรียบเทียบความแตกต่างของ Microservices กับสถาปัตยกรรมแบบรวมทุกอย่างไว้เป็นเนื้อเดียว (Monolith) ในทางปฏิบัติ น้อยครั้งมาก ที่เราจะเห็นแอพพลิเคชั่นสมัยใหม่ถูกพัฒนาแบบทุกอย่างเป็นเนื้อเดียวกัน

 

Thee-tier architecture

เว็บแอพพลิเคชั่นส่วนใหญ่มักจะใช้สถาปัตยกรรมแบบ Three-tier โดยการแบ่ง Presentation (User interface), application logic, และ Database แยกออกจากกัน ตัวอย่างเช่น User interface ถูกเขียนด้วยจาวาสคริปต์และใช้งานบนเว็บบราวเซอร์ โดย application logic จะถูกซ่อนไว้บนเว็บเซอร์เวอร์ซึ่งติดต่อกับฐานข้อมูลในอีกเซอร์เวอร์แยกไปอีก

การใช้สถาปัตยกรรมแบบ Three-tier สามารถนำมารวมเข้ากับ Microservices ได้ โดยการแบ่งส่วนแต่ละ Tier ออกไปอยู่ในเซอร์วิซต่างๆแยกกัน ตามรูปข้างล่าง

ประเด็นสำคัญคือ การแบ่งชิ้นส่วน (Component) ของ Microservices นั้นแบ่งตามความต้องการของผู้ใช้งาน (Requirement หรือ Business capability) แทนที่จะแบ่งกันตามหน้า (Technical responsibility) เหมือนในกรณีของ Three-tier  โดยแต่ละเซอร์วิซจะมีอิสระต่อกันมาก

ดังนั้น ข้างในแต่ละเซอร์วิซ ก็จะสามารถนำมาแบ่งออกเป็น tier ย่อยลงไปได้อีก

อีกประเด็นที่สำคัญคือ การแบ่งตามเซอร์วิซ จะมีผลกระทบต่อการทำงานของทีมด้วย สมมติว่าเรามีทีมพัฒนา 20 คน  ครึ่งหนึ่ง (ทีมเหลือง) ต้องพัฒนา Payment service ส่วนอีกครึ่งหนึ่ง (ทีมเทา) ต้องพัฒนา Account Balance Service

หากเราเลือกทำตามรูปแบบทางซ้าย ทั้งสองทีมจะต้องเลือกใช้เทคโนโลยีเดียวกัน และ Release แอพพลิเคชั่นใหม่พร้อมกัน หากมีชิ้นส่วนไหนทำงานผิดพลาด ทั้งระบบอาจหยุดทำงานหมดได้

กรณีทางด้านขวา ทีมเหลืองอาจเลือกที่จะใช้ Java 7 ในการพัฒนา ส่วนทีมเทาอาจเลือกใช้ Python เขียน เนื่องจากเซอร์วิซทั้งสองตัวทำงานอยู่คนละ Process (หรืออาจจะอยู่คนละเครื่องเลย) ทั้งสองทีมมีอิสระอย่างเต็มที่ในการเลือกใช้เทคโนโลยีที่เหมาะสมกับทีม

นอกจากนี้ ทั้งสองทีมไม่มีความจำเป็นที่จะต้อง Release แอพพลิเคชั่นเวอร์ชั่นใหม่พร้อมกัน แต่ละทีมแค่ต้องรักษา Backward compatibility ของเซอร์วิซ ที่คนอื่นเรียกใช้ให้ทำงานได้เหมือนเดิมก็พอ  หากเซอร์วิซตัวหนึ่งเกิดพังขึ้นมา ตัวอื่น (ที่ไม่ได้ใช้งานเซอร์วิซนี้) ก็ยังสามารถทำงานได้อย่างปกติ

นี่เป็นกรณีของทีมพัฒนาขนาด 20 คน  ลองนึกภาพบริษัทใหญ่ที่มีทีมพัฒนาเป็นหลักพันคนดูสิครับ ถ้าไม่มีการแบ่งออกเป็นเซอร์วิซย่อยๆ จะ Release ทีนี่วุ่นวายแค่ไหน

 

Centrally Integrated database

ตัวเปรียบเทียบถัดไปคือแนวคิดของการจัดเก็บข้อมูล โดยแอพพลิเคชั่นบางประเภท (เช่น ERP- Enterprise Resource Planning) จะเน้นให้มีการจัดเก็บข้อมูลของทุกอย่างในฐานข้อมูลเดียวกัน เพื่อให้มีความสอดคล้อง (Consistent) และลดความซ้ำซ้อน (Duplication) ของข้อมูล

ในแนวคิดของ Microservices  แต่ละชิ้นส่วนของแอพพลิเคชั่น (เซอร์วิซ) จะเป็นอิสระต่อกัน ดังนั้น แต่ละเซอร์วิซสามารถมีฐานข้อมูลแยกออกไปเป็นอิสระของตัวเอง การออกแบบ Microservices จึงต้องระวังเรื่องความสอดคล้องและความซ้ำซ้อนของข้อมูลให้ดี

อีกประเด็นหนึ่งที่สำคัญคือ แต่ละเซอร์วิซจะไม่สามารถเข้าถึง Database ของชิ้นส่วนอื่นๆได้ โดยจะต้องดึงข้อมูลผ่านทาง API ที่ตกลงกันไว้เท่านั้น

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

 

Enterprise Service Bus

อีกตัวอย่างหนึ่งที่สามารถแสดงข้อแตกต่างของ Microservices กับ SOA แบบอื่นได้ดี คือสถาปัตยกรรมที่ใช้ Enterprise Service Bus

Enterprise Service Bus เป็นสถาปัตยกรรมแบบหนึ่งของ SOA  โดยตัว Bus จะหน้าที่หลายอย่างดังนี้ [2]

1. ส่งข้อมูลหรือข้อความต่างๆระหว่าง Service
2. จัดการ Deployment ของ Service เวอร์ชั่นต่างๆ
3. จัดการ Service ที่หลาย Service ต้องเรียกใช้ร่วมกัน (event handling, , data mapping and transformation, security, exception handling)
4. Service orchestration

ในทางตรงกันข้าม Microservices เลือกที่จะตัด Enterprise Service Bus ออก และหันไปใช้ “Dumb pipes” [1] ในการส่งข้อมูลแทน

Dumb pipes อาจจะเป็นเพียง HTTP connection หรือ Light-weight messaging  ใจความหลักคือ Dumb pipes จะทำหน้าที่ส่งข้อมูล ส่วนหน้าที่อื่นๆที่เคยถูกทำโดย Enterprise Service Bus จะถูกโอนไปให้ตัวเซอร์วิซเป็นผู้ตัดสินใจเอง

แล้วแบบไหนดีกว่า? คำตอบก็แล้วแต่มุมมองและสถานการณ์ ฝั่งที่สนับสนุน Microservices จะสนับสนุนตัวเองว่า Business logic และการจัดการต่างๆควรจะเป็นหน้าที่ของฝั่งเซอร์วิซ ไม่ใช่เอามาปนกันอยู่ใน Bus  ในขณะที่ฝั่งที่สนับสนุน Bus ก็จะบอกว่าการให้อิสระมากเกินไปกับฝั่งเซอร์วิซ จะทำให้ควบคุมจากส่วนกลางทำได้ยาก Interface ของแต่ละเซอร์วิซไม่สอดคล้องกัน และมี Logic ที่ซ้ำซ้อนระหว่างเซอร์วิซมากกว่า

โดยส่วนตัว ผู้เขียนชื่นชอบ Microservices มากกว่าเพราะเหตุผลในด้านการจัดการ  เนื่องจากทีมพัฒนาที่ดูแล Bus กับตัว Service มักจะเป็นคนละทีมกัน ทีมที่ดูแล Bus มักจะเป็นทีมที่มีงานมากที่สุด (เพราะต้องรองรับทุกๆ Service) พอใกล้เวลา Release ก็จะเกิดปัญหาคอขวดที่ทีมนี้เนื่องจากงานล้นมือ  และจบด้วยปัญหาการเมืองที่มาไล่จับแพะกันว่าทำไมถึง Release ไม่ทัน

 

สรุปข้อดีข้อเสียของ Microservices

ถึงจุดนี้ ผู้อ่านคงเห็นภาพของ Microservices ชัดเจนมากขึ้น ผมข้อสรุปข้อดีข้อเสียไว้ดังนี้ครับ

• ข้อดี

  • Technology Independent – แต่ละเซอร์วิซมีอิสระในการเลือกใช้เทคโนโลยีที่ต่างกัน
  • Availability – หากเซอร์วิซหนึ่งพัง เซอร์วิซอื่นๆที่เหลือยังสามารถทำงานต่อได้โดยไม่พังทั้งระบบ
  • Release and deployment – การจัดการเซอร์วิซเล็กๆหลายตัวทำได้ง่ายกว่า
  • Scalability – การทำขยายเซอร์เวอร์เพื่อรองรับผู้ใช้งานที่มากขึ้น (เช่น เพิ่มจำนวนเซอร์เวอร์) สามารถทำได้ในเฉพาะเซอร์วิซที่ถูกใช้งานเยอะๆ  แทนที่จะต้องทำกับทั้งแอพพลิเคชั่น

• ข้อเสีย

  • Boundary definition between services – หากการแบ่งเซอร์วิซทำไว้ตอนแรกไม่ดี การแก้ไขในภายหลังจะยากมาก เพราะ  Service อาจถูกเรียกใช้แล้ว การรักษา Backward compatibility จะทำให้การ Refactor โค้ดระหว่างเซอร์วิซยากมากๆ
  • Latency – การใช้ส่งข้อมูลระหว่างเซอร์วิซนั้นช้ากว่าการส่งข้อมูลภายใน process เดียวกัน (ในกรณี Monolith)
  • Consistency – ความสอดคล้องกันของข้อมูลจะรักษายากกว่ากรณี Integrated Database
  • Infrastructure automation– การทำ Microservices ให้ได้ดี จำเป็นต้องมีการจัดการ Infrastructure ที่ดีมาก เพราะการ deploy เซอร์วิซจำนวนมากนั้นจะทำ Manual ยากมาก ส่วนใหญ่ต้องใช้การทำ Automation เกือบ 100%

แหล่งอ้างอิง:

• [1] http://martinfowler.com/microservices
• [2] https://en.wikipedia.org/wiki/Enterprise_service_bus
• [3] https://www.youtube.com/watch?v=wgdBVIX9ifA
• [4] https://www.youtube.com/watch?v=1aaw7iYS_VM

from:https://www.techtalkthai.com/introduction-to-microservices-architecture/

Splunk เผยแนวโน้มปี 2016 สำหรับ Cloud, Security, IT Operations, Big Data, Business Analytics, IoT

Splunk ผู้ผลิตระบบ Real-times Data Analytics ชั้นนำระดับโลกที่สามารถประยุกต์ใช้เข้ากับการใช้งานได้อย่างยืดหยุ่น ได้ออกมาทำนายถึงแนวโน้มปี 2016 สำหรับเทคโนโลยีเด่นๆ ดังต่อไปนี้

แนวโน้มทางด้าน Cloud ในปี 2016

• Cloud จะกลายเป็น Platform มาตรฐานสำหรับ Internet of Things
• SIEM จะย้ายมาอยู่บน Cloud แทน
• Cloud Platform จะเติบโตขึ้นเพราะเหล่าผู้เชี่ยวชาญทางด้านวิศวกรรม IT

 

แนวโน้มทางด้าน Security ในปี 2016

• ระบบวิเคราะห์พฤติกรรมจะถูกเปลี่ยนจากการวิเคราะห์พฤติกรรมของผู้ใช้งาน มาเป็นการวิเคราะห์พฤติกรรมของระบบแบบ Machine-to-Machine แทน
• แต่ละองค์กรจะเริ่มสร้างระบบ Threat Intelligence ของตัวเอง และกระบวนการทางด้าน Cybersecurity จะถูกพัฒนาอย่างแพร่หลาย และกลายเป็นหนึ่งในขีดความสามารถทางการแข่งขัน
• การทำ Automation และการโต้ตอบเหตุการณ์ต่างๆ ทางด้านความปลอดภัยจะเติบโตยิ่งขึ้น
• ความแพร่หลายในการใช้ Personally Indentifiable Information (PII) จะช่วยสร้างความปลอดภัยในการระบุตัวตนยิ่งขึ้น
• Internet of Things จะกลายเป็นเป้าหมายหลักในการโจมตีองค์กรที่มีความรุนแรงในชีวิตจริงเป็นอย่างมาก และต้องมีโซลูชั่นใหม่ๆ มาตอบโจทย์นี้โดยเฉพาะ

 

แนวโน้มทางด้าน IT Operations ในปี 2016

• เหล่าผู้นำทางด้านธุรกิจจะต้องการข้อมูลเกี่ยวกับผลกระทบของเทคโนโลยีที่มีต่อเป้าหมายทางธุรกิจอย่างละเอียดยิ่งขึ้น
• Sharing Economy ทางด้าน IT อย่าง Cloud, Microservice, API และอื่นๆ จะถูกเพิ่มความสามารถในการแสดงข้อมูลการทำงาน, การควบคุม, การบริหารจัดการ, การรักษาความปลอดภัย และอื่นๆ เพิ่มเติม
• การบริหารจัดการการให้บริการทางด้าน IT จะถูกปรับปรุงให้ดีขึ้นด้วยเทคโนโลยีใหม่ๆ
• การตรวจสอบการทำงานของบริการต่างๆ ในระบบ IT จะถูกปรับปรุงให้ดีขึ้นด้วย Predictive Analytics, Monitoring และ Automatic Response
• การทำ DevOps ในระดับองค์กรจะเติบโตอย่างรวดเร็วในหลากหลายธุรกิจ

 

แนวโน้มทางด้าน Big Data, Business Analytics, Internet of Things ในปี 2016

• จะเกิด Business Operations Center ขึ้น
• Machine Learning จะเข้ามาช่วยลดเวลาที่ใช้ในการวิเคราะห์และแสดงผลเหตุการณ์ต่างๆ ที่เกิดขึ้นได้เป็นอย่างมาก
• Internet of Things สำหรับอุตสาหกรรมจะเข้ามาเปลี่ยนแปลงระบบอัจฉริยะทั้งหมดในวงการ

สำหรับผู้ที่สนใจ Splunk ในการวิเคราะห์ข้อมูลเชิงธุรกิจ หรือใช้สร้าง Dashboard สำหรับระบบ SOC และ NOC และอยากพูดคุยเพื่อรับคำปรึกษาเพิ่มเติมหรือทดสอบระบบ สามารถติดต่อบริษัท STelligence ได้ทันทีที่ info@stelligence.com หรือติดต่อคุณธเนศ ฝ่ายขาย ที่โทร 089-444-2443 หรือโทร 02-938-7475 ได้ทันที หรือเข้าเยี่ยมชมเว็บไซต์ของ STelligence ได้ที่ http://www.stelligence.com

ที่มา: http://www.splunk.com/en_us/newsroom/2016-predictions.html

from:https://www.techtalkthai.com/splunk-predicted-2016-trend-for-cloud-security-it-operations-big-data-and-internet-of-things/

EMC แนะ จะทำ Hybrid Cloud ก็อย่าติดกับดักของการทำ Automation

EMC ได้ออกมาเปิดเผยถึงแนวคิดในการสร้าง Hybrid Cloud และการทำ IT-as-a-Service เพื่อรองรับการทำ DevOps เอาไว้ได้อย่างน่าสนใจในแง่มุมของการทำ Automation ซึ่งทาง EMC ได้สรุปสั้นๆ เอาไว้ท้ายบทความได้อย่างน่าสนใจดังนี้

Credit: ShutterStock.com

• ทำ Automation เฉพาะสิ่งที่จำเป็น
• แบ่งกระบวนการออกเป็นส่วนย่อยๆ ที่บริหารจัดการได้ง่ายตามแนวคิด Microservices
• Life Cycle ของการทำ Automation นั้นต้องคิดเผื่อถึงการปรับปรุงการทำ Automation และการปรับปรุง Process ให้ดีขึ้นไปด้วย รวมถึงการ Maintenance ระบบที่ถูก Automate เอาไว้
• หลีกเลี่ยงการเกิด Over-Engineering หรือการลงลึกทางด้านเทคนิคเยอะเกินไป

นอกจากนี้ EMC ยังได้หยิบยก Quote ที่น่าสนใจเกี่ยวกับการทำ Automation เอาไว้ด้วยดังนี้

• กระบวนการที่แย่ก็ยังคงเป็นกระบวนการที่แย่ถึงแม้เราจะ Automate มันไปแล้ว
• ไม่มีอะไรเปล่าประโยชน์เท่าการทำสิ่งที่ไม่สมควรต้องทำตั้งแต่แรกให้มีประสิทธิภาพ
• ยิ่ง Infrastructure ของเราซับซ้อนเท่าไหร่ การทำ Automation ของเราก็ยิ่งซับซ้อนมากขึ้นเท่านั้น และปัญหาที่เราจะแก้ได้ก็จะยิ่งซับซ้อนขึ้นไปด้วยเช่นกัน

ใครอยากอ่านฉบับเต็ม คลิกอ่านตรงที่มาด้านล่างนี้ได้เลยครับ

ที่มา: https://infocus.emc.com/harri_kallioniemi/hybrid-cloud-cookbook-avoid-automation-pitfalls/

from:https://www.techtalkthai.com/emc-suggested-avoid-automation-pitfalls-in-hybrid-cloud/

รู้จักกับ 3 เทคโนโลยีมาแรงสำหรับ Data Center ปี 2016: Disaggregation, Container และ Hyperconvergence

Credit: ShutterStock.com

ในปี 2016 นี้ เทรนด์เทคโนโลยีในฝั่งของ IT Infrastructure ที่จะมาแรงและน่าจับตามองก็จะมีด้วยกัน 3 ตัว ได้แก่ Disaggregation, Container และ Hyperconvergence ซึ่งแต่ละตัวเป็นยังไง ทางทีมงาน TechTalkThai ก็ขอสรุปคร่าวๆ ให้อ่านเข้าใจกันได้ง่ายๆ เอาไว้ดังนี้ครับ

 

Disaggregation การแยก Software ออกจาก Hardware

คำว่า Disaggragation นี้เป็นคำที่ตรงข้ามกับคำว่า Aggregation ที่เราคุ้นเคยกันดีในการทำ Port Aggregation นั่นเอง ความหมายแบบสั้นๆ ก็คือ “การแยกออกจากกัน” ซึ่งคำๆ นี้ถูกนำมาใช้เนื่องจากการมาของ Network Software ที่มีการพัฒนา Operating System Software สำหรับนำมาใช้ทำหน้าที่ในส่วนประกอบต่างๆ ของระบบเครือข่าย และเปิดให้ผู้ใช้งานสามารถนำ Hardware ที่ต้องการมาติดตั้ง Software เหล่านี้เข้าไปด้วยตัวเองได้อย่างอิสระ และกลายเป็นส่วนหนึ่งของการทำ Software Defined Networking ได้ด้วย เรียกได้ว่าเป็นการแยก Network Software ออกจาก Network Hardware นั่นเอง

อุปกรณ์ Hardware สำหรับติดตั้ง Network OS เหล่านี้จะถูกเรียกว่า White Box Hardware เช่น ถ้าถูกออกแบบมาสำหรับติดตั้ง Switch OS ก็จะถูกเรียกว่า White Box Switch เป็นต้น ซึ่งปัจจุบันนี้ผู้ผลิตอย่าง HP, Dell, Juniper และ Supermicro ต่างก็ผลิต White Box Switch นี้ออกมาวางจำหน่ายแล้ว ซึ่งแนวคิดนี้ก็จะทำให้แต่ละบริษัทสามารถ Focus ไปกับการพัฒนาสิ่งที่ตัวเองถนัดได้มากขึ้น ในขณะที่ผู้บริโภคเองก็มีทางเลือกมากขึ้น และรองรับการเปลี่ยน Network OS โดยไม่เปลี่ยน Hardware ได้ รวมถึงในอนาคต Network OS เหล่านี้ก็จะมีบทบาทในโลกของ Virtualization, Cloud และ Container อีกด้วย

 

Container แนวทางของ IT Infrastructure ที่ตอบโจทย์ DevOps

ทางด้านของ Container ที่เป็นเทคโนโลยีคู่กับวงการ IT มาช้านาน แต่เพิ่งมีการตื่นตัวอย่างรวดเร็วด้วยการมาของ Docker เมื่อเร็วๆ นี้ ก็เป็นเทคโนโลยีที่จะช่วยให้การจำลอง Environment สำหรับให้ Application ต่างๆ สามารถทำงานได้นั้นสามารถทำได้อย่างสะดวกและง่ายดายยิ่งขึ้น โดยผู้พัฒนา Software ก็สามารถพัฒนาบน Container ที่มี Environment แบบเดียวกับระบบ Producition ได้ ทำให้การ Deliver Software หรือ Feature ใดๆ นั้นน้อยลง รวมถึงรองรับสถาปัตยกรรมแบบ Microservice สำหรับรองรับการ Scale ระบบได้อย่างรวดเร็ว

ในขณะที่มุมของผู้ดูแลระบบเองก็สามารถสร้าง Container จำนวนมากเพื่อรองรับ Load ของผู้ใช้งานได้อย่างง่ายดายโดยที่มี Overhead ของ Resource ที่น้อยกว่าระบบ Virtualization เป็นอย่างมาก รวมถึงความผิดพลาดในการกำหนดค่าต่างๆ สำหรับ Environment ที่ต้องการใช้งานก็จะมีความผิดพลาดน้อยลงด้วยแนวคิดของ Infrastructure-as-Code อีกด้วย

 

Hyperconvergence ระบบ Data Center Infrastructure สำเร็จรูปด้วย Software

หลังจากที่พิสูจน์ตัวเองมาเป็นระยะเวลา 5 ปี แนวคิดของการทำ Hyperconvergence ก็กลายเป็นที่ยอมรับของตลาดจนมาถึงจุดที่ได้รับความนิยมเป็นอย่างมาก ด้วยการยุบรวมชั้นของ Server, Storage, Network และบางครั้งก็ถึงขั้นยุบรวมชั้นของ Security เข้ามาให้กลายเป็นระบบ Virtualization ทั้งหมดด้วย Software และติดตั้งลงบน Physical Server ใดๆ ก็ทำให้ Server นั้นๆ สามารถทำหน้าที่แทนทั้ง Server, Storage, Network รวมถึง Security ได้ทั้งหมดในตัวเดียว

ไม่เพียงเท่านั้น แนวคิดของ Hyperconvergence เองก็ยังเปิดให้ Server ที่ติดตั้ง Software เหล่านี้สามารถเพิ่มขยายแบบ Scale-out ได้ง่ายๆ ด้วยการเพิ่ม Server เข้ามาในระบบ และทำการติดตั้ง Software ให้เรียบร้อย จากนั้นก็เชื่อมต่อเครือข่ายเข้าถึงกัน ระบบ Hyperconvergence เหล่านี้ก็จะผสานระบบเข้าเป็นหนึ่งเดียว พร้อมให้บริหารจัดการได้จากศูนย์กลาง และรองรับประสิทธิภาพการทำงานที่สูงขึ้นตามประสิทธิภาพของ Server ที่เพิ่มเติมเข้าไปได้ทันที เป็นสถาปัตยกรรมที่ Cloud Data Center ขนาดใหญ่มักจะใช้กัน

 

ทั้งสามเทคโนโลยีนี้จะกลายเป็นสิ่งที่ผู้ดูแลระบบ IT ในองค์กรไม่สามารถหลีกเลี่ยงได้อีกต่อไป และต้องเริ่มทำการศึกษาเพื่อปรับตัวให้สามารถนำเทคโนโลยีเหล่านี้ไปใช้ประโยชน์ต่อไปได้ในอนาคตอีกด้วยครับ

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

ข้อมูลเพิ่มเติม: http://www.networkworld.com/article/3020668/virtualization/containers-hyperconvergence-and-disaggregation-are-hot.html#tk.rss_all 

from:https://www.techtalkthai.com/introduce-disaggregation-container-and-hyperconvergence-for-data-center-in-2016/