บันทึกงาน Google Cloud Summit 2019
สวัสดีชาวโลกจ้า~
สืบเนื่องจากเมื่อวันก่อน (2019-09-26) ได้ไปงาน Google Cloud Summit 2019 ที่จัดที่ Royal Paragon Hall หนึ่งวันเต็มๆ เลยอยากเก็บความทรงจำนี้เอาไว้ในบล็อกนี้ฮะ
คือ งานนี้มีกูเกิลยักษ์ใหญ่เป็นแม่งาน ต้องขอชมเลยว่า อิ่มอร่อยกับขนมและของกินฮะ (ผิด) ไม่ใช่ๆ หมายถึง มีของใหม่จากกูเกิลมาโชว์แน่นอนฮะ คือ งานนี้แบ่งเป็นช่วงๆ ช่วงละครึ่งชั่วโมง แต่ละช่วงแบ่งย่อยเป็นสองห้อง หรือสองแทร็คอีกฮะ เราเลยต้องเลือกสักแทร็คนึงของช่วงนั้นเข้าไปฟัง และต่อไปนี้ ผมจะขอเล่าที่ผมได้ไปฟังนะฮะ
Keynote
เปิดงานมา กูเกิลก็เล่าถึงความสำคัญของ cloud ทันที
ระบบ Cloud มีการใช้งานในระดับองค์กรเยอะขึ้นมาก แต่ข้อมูลที่ยังอยู่ในระบบ On-prem หรือ on-premise (ดูแลด้วยตัวเอง) ยังไม่ได้อยู่ในระบบ Cloud อยู่เยอะเหมือนกัน (กูเกิลบอกมีแค่ 10% ที่อยู่ใน cloud) และแน่นอนว่ามันทำให้ค่าใช้จ่ายและการดูแลระบบยังคงซับซ้อนอยู่
ด้วยความที่องค์กรส่วนใหญ่ใช้ทั้ง on-premise และ cloud (Multi-cloud) กูเกิลจึงขอนำเสนอ “Anthos” เป็น open-source เพื่อช่วยจัดการทั้ง Multi-cloud และ Hybrid cloud (cloud หลายยี่ห้อ) ให้สามารถจัดการข้อมูลไปมาระหว่างกันได้ฮะ ไม่จำกัดค่ายด้วยแหละ รองรับทั้ง Google Cloud Platform (GCP), Amazon Web Service (AWS), Microsoft Azure รวมไปถึง Alibaba Cloud ด้วย
ปิดการขายด้วยความปลอดภัย และความเป็นส่วนตัวว่า ข้อมูลของคุณ คุณจัดการได้ โดยให้กูเกิลเป็นยามเฝ้าสมบัติของคุณนะ
Data analysis
เปิดกล่องใหม่ด้วย Cloud Data Fusion ที่ใช้ทำ ETL ผมเห็นแล้วนึกถึง Talend เลยอ่ะ (ไม่รู้จัก? ย้อนไปอ่านได้ที่ Data Integration (EP 1) ฮะ) ที่ใช้งานง่ายแบบเดียวกันเลย ลากๆ วางๆ เอา กูเกิลโฆษณาว่า ใช้งานบนเว็บได้อย่างง่ายดาย เข้าใจง่ายด้วย แถมรองรับฐานข้อมูลหลายแบบมากๆ
อธิบาย use case ว่าพอเราใช้ Data Fusion ใส่ลง BigQuery แล้ว ก็สามารถดึงไปทำ Machine Learning ได้ด้วย AutoML Tables อีก หรือจะทำ Insight analysis แบบเร็วๆ ด้วย BigQuery BI Engine ก็ได้เหมือนกันฮะ
AI & Cloud AutoML
จริงๆ แล้ว กูเกิลเขาก็เด่นเรื่อง Machine Learning มานานเหมือนกันฮะ และคราวนี้ เขาก็มาพร้อมกับวิถีแห่ง Machine Learning ที่โฆษณาว่า ง่าย สะดวก รวดเร็ว และไม่ต้องโค้ดดิ้งฮะ
Anthos
ตัวนี้ฮือฮาในฮอลล์เหมือนกันฮะ ด้วยการเริ่มโจทย์ว่า องค์กรเราย่อมอยากรักษาข้อมูลที่เป็นความลับขององค์กรไว้ในระบบฐานข้อมูลของตัวเอง แต่ก็อยากจะใช้ cloud เพื่อความสะดวกของการทำงานร่วมกันในองค์กรอีกนั่นแหละ กูเกิลเลยเปิดคำตอบด้วยสิ่งนี้
Anthos เป็นเครื่องมือจัดการระบบไอทีขององค์กร ที่ครอบคลุมทั้งระบบ on-premise และระบบ cloud ที่ไม่จำกัดว่าเป็นของกูเกิลเท่านั้นฮะ มันเป็น open-source ดังนั้น ราคาย่อมไม่แพงแน่นอน
ตัว Anthos เองอยู่บนคอนเซปต์ของ Container Cluster หรือก็คือกลุ่ม Container ฮะ (Docker ใน ตอน Docker ก็คอนเซปต์ Container เหมือนกันนะ แต่เป็นแบบตัวเดี่ยวๆ) ซึ่งตัวกูเกิลเองก็มีระบบนี้ในชื่อของ Google Kubernetes Engine (GKE) ที่ต่อยอดมาจาก Kubernetes ที่เป็น open-source container cluster อีกทีนึงฮะ
ทีนี้ พอเรามีระบบหลากหลายแบบขึ้นมา ทั้ง on-premise ทั้ง cloud หลายๆ เจ้า ก็สามารถใช้ Anthos จัดการตัวระบบให้มันไหลต่อเนื่องกัน เวลาจะเขียนโปรแกรมตัวนึงขึ้นมาใช้ ก็สามารถ deploy มันไปในแต่ละระบบโดยจัดการผ่าน Anthos เพียงตัวเดียวได้เลยฮะ
Continuous Integration / Continuous Delivery
Continuous Integration / Continuous Delivery หรือ CI/CD เป็นคอนเซปต์การ deploy application ที่ developers ใช้กันเป็นพื้นฐานเลยฮะ (ตัวผมที่เป็น data engineer เลยไม่คุ้นชินเท่าไหร่) กูเกิลก็เสนอสิ่งนี้เข้ามา โดยสินค้ารอบนี้ คือ Cloud build ที่เป็นเหมือนตัวกลางจัดการ container image ของเราผ่าน Container Registry ก่อนจะไป deploy ที่ระบบปลายทางด้วย Cloud Run (ที่เปิดตัวมาได้สักพักนึงแล้ว) บนระบบ Google Kubernetes Engine และจบด้วย monitoring ผ่าน Stackdriver ฮะ
อยากย้ายไปอยู่บน cloud
สมมติว่า เรามีระบบ on-premise อยู่ แล้ววันนี้อยากย้ายระบบไปใช้บน cloud จะทำยังไงดี
วิทยากรเปรียบเทียบระบบสองระบบ โดยที่ระบบนึงเป็น on-premise ยังทำงานกันแบบเดิมๆ กับอีกระบบนึงที่เป็น cloud ที่มีความปลอดภัยสูง ปรับเพิ่มลดขนาดระบบได้อย่างอิสระ และคิดค่าใช้จ่ายตามจริง ทีนี้ ถ้าเรายังใช้ระบบแรกอยู่ แต่ต้องการไปใช้ระบบหลัง จะมีวิธีอะไรบ้าง
1. Lift and shift
คือ การย้ายระบบที่มีอยู่แล้ว ไปอยู่บน cloud แบบตรงๆ เลย ไม่ต้องแก้ไขอะไร ใช้สำหรับระบบส่วนที่ไม่มีผลกระทบกับส่วนอื่น ตัวอย่างเช่น เว็บไซต์ PHP ที่ไม่ซับซ้อน ก็ย้ายขึ้นตรงๆ เลย
2. improve and move
คือ ระบบที่ต้องเปลี่ยนโครงสร้างอยู่บ้าง ก่อนที่จะต้องย้ายไปบน cloud เพราะระบบ cloud ไม่รองรับ ตัวอย่างเช่น ระบบบริหารงานที่พัฒนาด้วย JAVA ต้องติดต่อกับ network ต่างๆ ก็จำเป็นต้องเปลี่ยนแปลงหลายๆ จุดหน่อย อย่างการเชื่อมต่อเครือข่าย การเชื่อมต่อฐานข้อมูล เป็นต้น
3. Rebuild
โหดหินที่สุด คือ ต้องเขียนใหม่ เพราะระบบเดิมกับระบบ cloud ไม่มีอะไรที่เข้ากันได้เลย ตัวอย่าง ระบบธุรกรรมของสถาบันทางการเงิน ที่เขียนด้วยภาษา Cobol ซึ่งมั่นใจได้เลยว่าไม่มี cloud เจ้าไหนรองรับภาษานี้ ก็คงต้องเขียนใหม่หมดฮะ
ไม่ว่าจะใช้วิธีไหน วิทยากรก็เตือนว่า ไม่ควรทำทีเดียวจบฮะ เพราะผลกระทบมันอาจจะมากเกินไปจนจัดการไม่ไหว ควรจะค่อยๆ ทยอยทำ หลังจากที่เราวางแผนไว้แต่ละขั้นตอนแล้ว ว่าต้องทำอะไรก่อนหลัง พอย้ายแต่ละส่วนเสร็จ ก็ปรับปรุงนิดนึงให้ระบบมันเข้าที่เข้าทาง ก่อนทำขั้นถัดไป
และแน่นอนฮะ ปิดท้ายแทร็คนี้ด้วยวิธีการย้ายระบบมาบน cloud ด้วย Google Compute Engine หรือ VM นั่นเอง กับอีกวิธีคือใช้ Anthos จัดการ ตามที่ได้เล่าไปแล้วข้างบนฮะ
Case study: KBTG
partner ของกูเกิลที่มาเล่าในแทร็คนี้ เป็น KBTG หรือ Kasikorn Bank ฮะ
เขาเล่าว่า ด้วยความที่เป็นระบบของธนาคาร จึงต้องวางแผนกันอย่างรัดกุมเลยแหละฮะ เพราะมันกระทบกับเงินๆ ทองๆ ของลูกค้าจำนวนมาก ทั้งประเทศ แต่เพื่อแลกกันกับการบริการลูกค้าที่มันยืดหยุ่นกว่า แถมประหยัดค่าใช้จ่ายกว่าของ cloud จึงตัดสินใจเลือกฮะ
ทางธนาคารเลือกใช้เป็น Multi-cloud ที่ผสมกันกับระบบ on-premise ของตัวเองด้วย โดยใช้ Google Cloud Storage จัดเก็บเอกสารต่างๆ มี Google Cloud Firestore เก็บข้อมูลที่ต้องการความ real-time รวมกันกับ Firebase รองรับลูกค้าที่ใช้ applications บนมือถือ
SRE กับหน้าที่ดูแลความมั่นคงของระบบ
ชื่อเต็มคือ Site Reliability Engineer [1] ซึ่งเค้าคนนี้มีบทบาทใกล้เคียงกับ DevOps (Development and Operation) ที่เรามักจะได้ยินบ่อยๆ ในยุคนี้เลย ความแตกต่างคือ DevOps จะสนใจจุดหมายว่า สุดท้ายแล้ว ระบบจะต้องประกอบไปด้วยอะไรบ้าง ทำงานยังไงบ้าง ในขณะที่ SRE จะเน้นกระบวนการว่า ระบบจะดำเนินไปอย่างไร ถึงจะตรงตามจุดประสงค์ของระบบ (วิทยากรเปรียบเทียบว่า DevOps เป็น Interface ส่วน SRE คือ Interface-extended class)
เมื่อ SRE มีหน้าที่ดูแลความสมบูรณ์ของกระบวนการ ที่ขาดไม่ได้จึงเป็นเรื่องของความปลอดภัยฮะ กูเกิลมีสิ่งที่เรียกว่า Binary Authorization ที่ใช้ควบคุม source code ไม่ให้ deploy หากยังไม่ได้รับอนุมัติจากผู้เกี่ยวข้อง
นอกจากนี้ SRE ยังมีบทบาทใหญ่ๆ ในสี่ประเด็น คือ
- SLOs หรือ Service Level Objectives หมายถึง จุดประสงค์การให้บริการ ที่ SRE จะต้องดูแลกระบวนการให้ได้ผลลัพท์ตรงตามจุดประสงค์นั้น
- Error Budget คือ การประเมินและตรวจสอบความถูกต้อง ความเสถียรของงาน ไปพร้อมกับความเร็วของการ deploy งาน
- Blameless Post-Mortem เวลาเกิดปัญหา SRE จะมีหน้าที่ควบคุมและรายงานผลของปัญหา โดยไม่พาดพิง หรือกล่าวโทษใคร (อันนี้ยากนะฮะ)
- Capping and eliminating toil คือ ลดงานที่ใช้แรง หันไปใช้ automation เพื่อให้ทีมสามารถโฟกัสกับงานอื่นที่ให้ผลลัพท์ที่ดีกว่าฮะ
หนึ่งวันของงานนี้ก็จบไปแล้วนะฮะ จะมาเล่าให้อ่านใหม่ ถ้าได้ไปงานไหนนะฮะ
บาย~
Reference:
[1] https://blog.overops.com/devops-vs-sre-whats-the-difference-between-them-and-which-one-are-you/