หรือผมจะต้อง downgrade ตัวเองไปทำ client
ก็ต้องไปดูแลกลุ่มเมฆแหละครับ
ถาม:วิศวกรระบบทำหน้าที่อะไรบ้างครับ ดูจากชื่อแล้วนึกไม่ออกครับ ต่างจากผู้ดูแลระบบยังไงครับ
ประเด็นคือ กลุ่มเมฆมันใช้คนน้อยกว่า ที่เหลือจะมีที่อยู่ตรงไหน?
เป็นกรรมกรตอนซ่อมครับ...
Dream high, work hard.
จริงๆมันก็หายไปแค่ฝั่งที่ใช้ PaaS เองนะครับ พวกที่เป็น IaaS ก็ยังต้องมี sys.en อยู่ดี
ผมเห็นทุกวันนี้ sys.en ค่อนข้างขาดแคลน ถ้าฝั่ง dev หนีไปใช้ cloud แบบ PaaS กันเยอะขึ้น sys.en ก็ไม่ถึงกับตกงานอยู่ดีมั้งครับ
แต่ถ้ามันเฟ้อจริงก็คงต้องปล่อยเป็นไปตาม natural selection ล่ะครับ
ดูแลอย่าให้ cloud ล่ม (หรือกู้ระบบ ถ้าล่มไปแล้ว)
aka ohmohm
ก่อนอื่นต้องบอกว่า องค์กรยังต้องการ Private System อยู่ครับ ณ ตอนนี้, คือถ้าเป็น Cloud ก็คงเป็น Private Cloud
แล้วลองพิจารณาให้ดีครับว่า Cloud กับ ไม่ Cloud ต่างกันอย่างไร ?
Cloud มันก็คล้ายๆ กับ Virtual Server/Hardware นั้นหละครับ .. ยังจำเป็นต้องการการติดตั้ง OS, App, Config ระบบ เหมือนทำบน Server โดยตรงครับ .. (แถมอีกหน่อย เห็นน้องบอกว่ามี Virtual Switch, Router, Load Balancer ด้วย)
ถ้าใช้งาน Private Cloud ยังงัยก็ยังมีงาน Hardware เช่น สั่งซื้อ, ตรวจรับ, ประกอบ, เชื่อมระบบ network อยู่ดีครับ .. เว้นเสียแต่ว่าในอนาคตราคา Hardware มันถูกมาก + เช่าบริการ Cloud Provider ถูกกว่าระบบมีประสิทธิภาพกว่า ซึ่งต่อให้เป็นเช่นนั้น ก็จะกระทบในส่วนของงาน Hardware อย่างเดียวนะครับ .. ส่วนงานด้านอื่นเช่น System Admin ก็ยังมีเหมือนเดิมครับ
พอเปลี่ยนจากอุปกรณ์แบบ physical ไปเปนอุปกรณ์แบบ virtual แล้ว.. labor work จะลด เพราะ task ที่ทำแบบ automate ได้จะมีเยอะขึ้น ดังนั้นถ้ามองว่า work load รวมมีเท่าเดิมก้อมีคนตกงานแน่ ส่วนพวก private cloud ก้อคงหวังพึ่งได้ไม่นานนัก เพราะยังไงๆ ก้อคงจะมีสัดส่วนน้อยลงไปเรื่อยๆ (ไม่นับว่าโดยส่วนตัว ไม่อยากนับว่า private cloud เปน cloud ซะด้วยซ้ำ มันเปน cloud พิการๆ ที่ market ยืม term มาใช้ขายของซะมากกว่า เพราะลำพังแค่ประเดนด้าน resiliency ก้อทำไรแทบไม่ได้แล้ว หากไม่ได้เปนองค์กรที่ใหญ่ๆ จะมีซักกี่รายที่ทำ backup site ได้ ถ้าทำก้อต้องพึ่ง hybrid cloud ซึ่งหากได้พึ่งเมื่อไร ก้อจะพึ่งมากขึ้นๆ เพราะโดนของดีราคาถูกเย้ายวน เนื่องจากทางนู่นได้ประโยชน์จาก economic of scale)
แต่ในภาพรวมแล้ว work load มีแนวโน้มขยายตัวอยู่เรื่อยๆ ดังนั้น labor work ที่ต้องการโดยรวมนั้นเปนไปได้ทั้ง เพิ่ม/ลด/ทรงตัว แต่ในระยะยาวแล้วสุดท้ายไงก้อคงต้องการน้อยลง ซึ่งก้อเปนวงจรปกติของทุกๆ สายงาน ทว่าก้อมิใช่แค่ sys eng ที่จะโดนหางเลขจากการมาของ cloud เพราะฟาก sw eng เองก้อโดนด้วย เพราะ cloud ใน layer ที่เปน cloud app หรือ cloud service จะทำให้ user มี basic component เยอะขึ้นๆ ดังนั้น work load รวมของพวก sw eng เองก้อจะลดลง เพราะจะเหลือแต่งานที่เปน high level มากขึ้นๆ เนื่องจาก component ที่เปน level ล่างๆ นั้นมีให้ใช้แล้ว แค่นำมาประกอบกัน
btw, ทาง sw eng จะโชคดีหน่อย เพราะการเพิ่ม work load โดยสร้าง product ใหม่ๆ นั้นอาจไม่จำเปนต้องมี innovation มากนัก แต่ก้อจะทำให้มีคู่แข่งเกิดตามขึ้นมาได้ง่ายด้วยเช่นกัน ไม่รุว่าจะเหนื่อยแรงน้อยกว่าเก่ามั้ย แต่เหนื่อยสมองกว่าเดิมแน่นอน.. จิงๆ พอตัดส่วน physical ออก ก้อทำให้พวก sys eng แข่ง innovation ได้มากขึ้นเช่นกัน เพราะกลุ่มที่ไม่สามารถผลิต hardware ได้ ก้อจะสามารถลงมาร่วมแข่งได้มากขึ้น แต่เนื่องจากยังไงๆ ฐานลูกค้าก้อมีน้อยกว่าทาง sw eng มากนัก ดังนั้นก้อต้องใส่ innovation เข้าไปมากๆ เพื่อให้โดดเด่นพอที่จะเตะตาโดนใจลูกค้า
ที่น่าจะโชคดี (หรือโชคร้าย) คือ cloud แบบเจ๋งๆ ในบ้านเราอาจจะมาช้า ยังมีติดอีกหลายประเดน.. ใครที่ปรับตัวช้าก้ออาจจะพอมีเวลาใหได้พักหายใจบ้าง แต่ว่าอย่าพักนานจนเพลิน เพราะว่ายังไงๆ ก้อมาชัวร
ต้องนับถือ True IDC ในเรื่องที่เริ่มให้บริการ Cloud ไปแล้ว .. ก่อนทราบเรื่อง True IDC เปิดให้บริการ cloud นั้น ผมรู้สึกว่าทางต่างประเทศขยับเข้ามา asean มากขึ้นโดยมาที่สิงค์โปร ผมลองเช็คความเร็ว hosting ที่อยู่สิงค์โปรโดยเล่นจากไทยนั้นใช้ได้ดีจนน่าใจหาย อดที่จะเป็นห่วงอนาคตไม่ได้ ในเรื่องต่างประเทศจะเข้ามายึดโอกาสทาง business ในไทยไปเสียหมด
ตปท เหมือนกี่รายๆ ก้อแหยง ยังไม่ค่อยจะเข้ามากันเท่าไหร่ เว้นพวกที่เดิมมี DC ไว้ host ให้ลูกค้าอยู่แล้ว.. ส่วนจากไทยจะไปใช้เมืองนอก รวมถึงการใช้ข้าม ปท ใดใดนี่ไงคงต้องเชค กม. อีกทีด้วย ไม่งั้นมีปัญหาทีหลังอาจมึนได้
ของทรูจิงๆ ก้อโอเคนะ.. เพียงแต่เทียบกับของเมืองนอกก้อยังห่างหลายก้าวอยู่ แอบลุ้นให้ตามเค้าได้ไวๆ ไม่งั้นหากทนไม่ไหวจิงๆ อาจต้องขอชิ่งไปทำงานอยู่เมืองนอกแทน เผลอได้ใช้ cloud แล้วติดหนึบ ทำเสียนิสัยชะมัด >.<"
Virtual hardware ถึงไม่พัง (ด้วยตัวมันเอง) แต่อาจสร้างปัญหาอื่นๆ ได้เหมือนกันนะครับ http://support.microsoft.com/kb/815056/en-us
นั่นมันปัญหา io ไม่ได้เกี่ยวกับ virtual ตรงๆเท่าไหร่ครับ
ถ้าผู้ให้บริการ virtual ยัดลูกค้าเยอะจนดิสทำงานไม่ทันก็จะเป็นงั้นแหละ
กลับกัน ถ้า virtual ทำงาน disk เร็วไป ก็อาจเกิดปัญหาได้เหมือนกัน
อันนี้ ตรงตัวกว่า High-end disk subsystems may experience error 17883 http://support.microsoft.com/kb/810885/en-us
ก็ไม่เกี่ยวกับ virtual อยู่ดีครับอันนั้น
แนะนำให้ดูวันที่ก่อนเอามาแปะด้วยนะครับ
บางที่ ยังใช้ของเก่าอยู่นะครับ และที่แปะก็ถือได้ว่า ปัญหาแบบนี้เคยเกิดขึ้น แม้หาวิธีคลี่คลายบรรเทาได้แล้ว
ปล. ตอนนี้ผมกำลังได้รับผลกระทบจาก virtual โดนยัดเยอะจนดิสก์ไม่ทำงาน แต่ไม่ใช่หน้าที่ผมในการดูแลแก้ปัญหานี้ละครับ (เป็นเหยื่อ)
http://www.blognone.com/news/21995/mfec-เข้าซื้อกิจการเครือเมกัส-และนอร์ธเทอร์นสตาร์ซอฟต์แวร์
ถ้าไม่อัพเกรดมันก็มีสองทางเลือกคือ ทนใช้ระบบเก่าต่อไป รึจะอัพเกรด
ปัญหาที่คุณแปะมาทั้งหมดมันไม่เกี่ยวกับ virtual สักนิดเลยครับ มันเป็นแค่บั๊กของ microsoft ซึ่งก็ออก patch แก้ไปตั้ง 7 ปีแล้ว ก็แค่นั้น
แล้วเป็นไปได้ไหมที่ virtual จะเร็วไป หรือกากไป
ปล ผมรู้ SQL 2000 discontinued ไปแล้ว
คงไม่มีระบบไหนที่การันตีได้ว่า error-free .. เอาแค่ five nines ยังไม่ค่อยมีใครกล้าเลย
point คือเมื่อเพิ่ม abstraction layer เข้ามาแทนที่การ interface กับ physical ตรงๆ ทำให้เกิด common interface/behavior ดังนั้นเมื่อจะปรับแก้อะไร ก้อสามารถทำได้ที่จุดเดียว แทนที่โอกาสเกิดปัญหาจะเปน O(n^2) หรือเผลอๆ O(n^d) ก้อเปน O(n) .. แต่แน่นอนว่าเมื่อมีการกำหนดสเปคไรใหม่ ของเดิมๆ ที่มีคงไม่ compat ทั้งหมด ต้องมีบ้างบางอย่างที่ต้องปรับแก้ แต่ระยะยาวแล้วการ interface ผ่าน virtual layer นั้นจะทำให้ใช้ effort เพื่อปรับแก้ต่างๆ น้อยกว่า ใครจะไป cloud จะโดนบอกเสมอ ว่าถ้าอยากได้ benefit เตมๆ ก้อต้องแก้แอพด้วยถึงจะนับว่าเปน cloud-app ได้ หากแค่โยนขึ้นไปบน IaaS เฉยๆ มันก้อเปนแค่การทำ virtualization
แต่อย่างน้อยก้อยังได้อีก point คือการก้าวข้าม physical limit เช่น การใช้ disk .. สมมติมี disk 2 ตัว แต่ละตัวเหลือที่อยู่ 2 GB ถ้ามีข้อมูลก้อนนึงขนาด 3 GB มันก้อเกบข้อมูลนี้ไม่ได้ ไม่งั้นแอพก้อต้องฉลาดรุจัก disk ทั้งหมดและสามารถแบ่งเขียนก้อนข้อมูลแล้วอ่านรวมทีหลังได้ แต่ถ้ามี virtual layer ที่ทำให้ layer อื่นมอง disk ทั้งหมดเปนผืนเดียว ปัญหาก้อจบได้ง่ายๆ แล้วถ้า virtual layer มันจัดการได้แบบ dynamic ก้อจะช่วยเรื่อง utilization กับ redundancy ได้อีก
ปัญหา มีหรือไม่มี มีบ่อยหรือไม่บ่อย ไม่สำคัญเท่าว่าถ้ามีปัญหาจะรับมืออย่างไร
ถึงได้มองว่าการเพิ่ม abstraction layer อย่าง virtualization เข้ามานั้น ในระยะยาวจะทำให้การตรวจเชคและแก้ปัญหานั้นทำได้สะดวกขึ้น เพราะมันทำให้เกิดการ separation of concerns
แต่แน่นอนว่าเมื่อมีการเพิ่ม component เข้าไปในระบบ ในอีกแง่นึงมันก้อทำให้มี complexity เพื่มขึ้น โดยเฉพาะในช่วงแรกๆ ที่ต้องปรับแก้ของเดิมที่มีอยู่ ทั้งเพราะ interface/behavior ต่างๆ ที่เปลี่ยนไปและเพราะ side-effect ต่างๆ ที่อาจไม่ทันคาดคิดมาก่อน.. แต่จากที่ผ่านๆ มา โดยรวมแล้วดูจะมีผลดีมากกว่าผลเสีย
เนื่องจาก cloud คงผ่าน network จึงต้องดูแล หรือแก้ไข ปัญหา network ด้วยล่ะ
ถ้าไม่ใช่ stand-alone .. ไงก้อยุ่งกับ network อยู่ดี :?
Cloud Computing นี่ส่วนหนึ่งเกิดได้เพราะ "ค่าบำรุงรักษา" (เงินเดือน Sys Admin นี่ล่ะ) มันพุ่งสูงขึ้นเรื่อยๆ ในทุกหน่วยงาน เพราะการใช้ IT ที่มากขึ้นนะครับ เขาเลยพยายามลดมันลงด้วยการโยนงานไปรวมๆ กัน
ในมุมมองผม IT Spending รวมๆ ไปถึงเงินที่ใช้จ้างงาน ไม่ได้ลดลงครับ งานแปลกประหลาด ประเภท Core Business ต้องตั้งเครื่องในบริษัท แต่เครื่องทั่วไปใช้ IaaS หรือเว็บใช้ PaaS แล้วต้อง Integrate กัน ทำ SSO ข้ามกัน ฯลฯ ยังมีอีกเยอะ และเพิ่มขึ้นเรื่อยๆ อาจจะลดความเร็วในการเพิ่มไปบ้าง
lewcpe.com, @wasonliw
"โยนงานไปรวมๆ กัน" .. คือแค่พยายามเพิ่ม utilization ใช่มั้ยคับ ยังไม่ถึงขั้น outsrc
คือถ้าพูดถึง outsrc ด้วย จะสงสัยต่อเรื่อง private cloud ว่าจะพิจารณารวมไม่รวมยังไงดี?
ก็ต้องไปดูแลกลุ่มเมฆแหละครับ
ถาม:วิศวกรระบบทำหน้าที่อะไรบ้างครับ ดูจากชื่อแล้วนึกไม่ออกครับ ต่างจากผู้ดูแลระบบยังไงครับ
ประเด็นคือ กลุ่มเมฆมันใช้คนน้อยกว่า ที่เหลือจะมีที่อยู่ตรงไหน?
เป็นกรรมกรตอนซ่อมครับ...
Dream high, work hard.
จริงๆมันก็หายไปแค่ฝั่งที่ใช้ PaaS เองนะครับ พวกที่เป็น IaaS ก็ยังต้องมี sys.en อยู่ดี
ผมเห็นทุกวันนี้ sys.en ค่อนข้างขาดแคลน ถ้าฝั่ง dev หนีไปใช้ cloud แบบ PaaS กันเยอะขึ้น sys.en ก็ไม่ถึงกับตกงานอยู่ดีมั้งครับ
แต่ถ้ามันเฟ้อจริงก็คงต้องปล่อยเป็นไปตาม natural selection ล่ะครับ
ดูแลอย่าให้ cloud ล่ม (หรือกู้ระบบ ถ้าล่มไปแล้ว)
aka ohmohm
ก่อนอื่นต้องบอกว่า องค์กรยังต้องการ Private System อยู่ครับ ณ ตอนนี้, คือถ้าเป็น Cloud ก็คงเป็น Private Cloud
แล้วลองพิจารณาให้ดีครับว่า Cloud กับ ไม่ Cloud ต่างกันอย่างไร ?
Cloud มันก็คล้ายๆ กับ Virtual Server/Hardware นั้นหละครับ .. ยังจำเป็นต้องการการติดตั้ง OS, App, Config ระบบ เหมือนทำบน Server โดยตรงครับ .. (แถมอีกหน่อย เห็นน้องบอกว่ามี Virtual Switch, Router, Load Balancer ด้วย)
ถ้าใช้งาน Private Cloud ยังงัยก็ยังมีงาน Hardware เช่น สั่งซื้อ, ตรวจรับ, ประกอบ, เชื่อมระบบ network อยู่ดีครับ .. เว้นเสียแต่ว่าในอนาคตราคา Hardware มันถูกมาก + เช่าบริการ Cloud Provider ถูกกว่าระบบมีประสิทธิภาพกว่า ซึ่งต่อให้เป็นเช่นนั้น ก็จะกระทบในส่วนของงาน Hardware อย่างเดียวนะครับ .. ส่วนงานด้านอื่นเช่น System Admin ก็ยังมีเหมือนเดิมครับ
พอเปลี่ยนจากอุปกรณ์แบบ physical ไปเปนอุปกรณ์แบบ virtual แล้ว.. labor work จะลด เพราะ task ที่ทำแบบ automate ได้จะมีเยอะขึ้น ดังนั้นถ้ามองว่า work load รวมมีเท่าเดิมก้อมีคนตกงานแน่ ส่วนพวก private cloud ก้อคงหวังพึ่งได้ไม่นานนัก เพราะยังไงๆ ก้อคงจะมีสัดส่วนน้อยลงไปเรื่อยๆ (ไม่นับว่าโดยส่วนตัว ไม่อยากนับว่า private cloud เปน cloud ซะด้วยซ้ำ มันเปน cloud พิการๆ ที่ market ยืม term มาใช้ขายของซะมากกว่า เพราะลำพังแค่ประเดนด้าน resiliency ก้อทำไรแทบไม่ได้แล้ว หากไม่ได้เปนองค์กรที่ใหญ่ๆ จะมีซักกี่รายที่ทำ backup site ได้ ถ้าทำก้อต้องพึ่ง hybrid cloud ซึ่งหากได้พึ่งเมื่อไร ก้อจะพึ่งมากขึ้นๆ เพราะโดนของดีราคาถูกเย้ายวน เนื่องจากทางนู่นได้ประโยชน์จาก economic of scale)
แต่ในภาพรวมแล้ว work load มีแนวโน้มขยายตัวอยู่เรื่อยๆ ดังนั้น labor work ที่ต้องการโดยรวมนั้นเปนไปได้ทั้ง เพิ่ม/ลด/ทรงตัว แต่ในระยะยาวแล้วสุดท้ายไงก้อคงต้องการน้อยลง ซึ่งก้อเปนวงจรปกติของทุกๆ สายงาน ทว่าก้อมิใช่แค่ sys eng ที่จะโดนหางเลขจากการมาของ cloud เพราะฟาก sw eng เองก้อโดนด้วย เพราะ cloud ใน layer ที่เปน cloud app หรือ cloud service จะทำให้ user มี basic component เยอะขึ้นๆ ดังนั้น work load รวมของพวก sw eng เองก้อจะลดลง เพราะจะเหลือแต่งานที่เปน high level มากขึ้นๆ เนื่องจาก component ที่เปน level ล่างๆ นั้นมีให้ใช้แล้ว แค่นำมาประกอบกัน
btw, ทาง sw eng จะโชคดีหน่อย เพราะการเพิ่ม work load โดยสร้าง product ใหม่ๆ นั้นอาจไม่จำเปนต้องมี innovation มากนัก แต่ก้อจะทำให้มีคู่แข่งเกิดตามขึ้นมาได้ง่ายด้วยเช่นกัน ไม่รุว่าจะเหนื่อยแรงน้อยกว่าเก่ามั้ย แต่เหนื่อยสมองกว่าเดิมแน่นอน.. จิงๆ พอตัดส่วน physical ออก ก้อทำให้พวก sys eng แข่ง innovation ได้มากขึ้นเช่นกัน เพราะกลุ่มที่ไม่สามารถผลิต hardware ได้ ก้อจะสามารถลงมาร่วมแข่งได้มากขึ้น แต่เนื่องจากยังไงๆ ฐานลูกค้าก้อมีน้อยกว่าทาง sw eng มากนัก ดังนั้นก้อต้องใส่ innovation เข้าไปมากๆ เพื่อให้โดดเด่นพอที่จะเตะตาโดนใจลูกค้า
ที่น่าจะโชคดี (หรือโชคร้าย) คือ cloud แบบเจ๋งๆ ในบ้านเราอาจจะมาช้า ยังมีติดอีกหลายประเดน.. ใครที่ปรับตัวช้าก้ออาจจะพอมีเวลาใหได้พักหายใจบ้าง แต่ว่าอย่าพักนานจนเพลิน เพราะว่ายังไงๆ ก้อมาชัวร
ต้องนับถือ True IDC ในเรื่องที่เริ่มให้บริการ Cloud ไปแล้ว .. ก่อนทราบเรื่อง True IDC เปิดให้บริการ cloud นั้น ผมรู้สึกว่าทางต่างประเทศขยับเข้ามา asean มากขึ้นโดยมาที่สิงค์โปร ผมลองเช็คความเร็ว hosting ที่อยู่สิงค์โปรโดยเล่นจากไทยนั้นใช้ได้ดีจนน่าใจหาย อดที่จะเป็นห่วงอนาคตไม่ได้ ในเรื่องต่างประเทศจะเข้ามายึดโอกาสทาง business ในไทยไปเสียหมด
ตปท เหมือนกี่รายๆ ก้อแหยง ยังไม่ค่อยจะเข้ามากันเท่าไหร่ เว้นพวกที่เดิมมี DC ไว้ host ให้ลูกค้าอยู่แล้ว.. ส่วนจากไทยจะไปใช้เมืองนอก รวมถึงการใช้ข้าม ปท ใดใดนี่ไงคงต้องเชค กม. อีกทีด้วย ไม่งั้นมีปัญหาทีหลังอาจมึนได้
ของทรูจิงๆ ก้อโอเคนะ.. เพียงแต่เทียบกับของเมืองนอกก้อยังห่างหลายก้าวอยู่ แอบลุ้นให้ตามเค้าได้ไวๆ ไม่งั้นหากทนไม่ไหวจิงๆ อาจต้องขอชิ่งไปทำงานอยู่เมืองนอกแทน เผลอได้ใช้ cloud แล้วติดหนึบ ทำเสียนิสัยชะมัด >.<"
Virtual hardware ถึงไม่พัง (ด้วยตัวมันเอง) แต่อาจสร้างปัญหาอื่นๆ ได้เหมือนกันนะครับ
http://support.microsoft.com/kb/815056/en-us
aka ohmohm
นั่นมันปัญหา io ไม่ได้เกี่ยวกับ virtual ตรงๆเท่าไหร่ครับ
ถ้าผู้ให้บริการ virtual ยัดลูกค้าเยอะจนดิสทำงานไม่ทันก็จะเป็นงั้นแหละ
กลับกัน ถ้า virtual ทำงาน disk เร็วไป ก็อาจเกิดปัญหาได้เหมือนกัน
อันนี้ ตรงตัวกว่า
High-end disk subsystems may experience error 17883 http://support.microsoft.com/kb/810885/en-us
aka ohmohm
ก็ไม่เกี่ยวกับ virtual อยู่ดีครับอันนั้น
แนะนำให้ดูวันที่ก่อนเอามาแปะด้วยนะครับ
บางที่ ยังใช้ของเก่าอยู่นะครับ และที่แปะก็ถือได้ว่า ปัญหาแบบนี้เคยเกิดขึ้น แม้หาวิธีคลี่คลายบรรเทาได้แล้ว
ปล. ตอนนี้ผมกำลังได้รับผลกระทบจาก virtual โดนยัดเยอะจนดิสก์ไม่ทำงาน แต่ไม่ใช่หน้าที่ผมในการดูแลแก้ปัญหานี้ละครับ (เป็นเหยื่อ)
http://www.blognone.com/news/21995/mfec-เข้าซื้อกิจการเครือเมกัส-และนอร์ธเทอร์นสตาร์ซอฟต์แวร์
aka ohmohm
ถ้าไม่อัพเกรดมันก็มีสองทางเลือกคือ ทนใช้ระบบเก่าต่อไป รึจะอัพเกรด
ปัญหาที่คุณแปะมาทั้งหมดมันไม่เกี่ยวกับ virtual สักนิดเลยครับ มันเป็นแค่บั๊กของ microsoft ซึ่งก็ออก patch แก้ไปตั้ง 7 ปีแล้ว ก็แค่นั้น
แล้วเป็นไปได้ไหมที่ virtual จะเร็วไป หรือกากไป
ปล ผมรู้ SQL 2000 discontinued ไปแล้ว
aka ohmohm
คงไม่มีระบบไหนที่การันตีได้ว่า error-free .. เอาแค่ five nines ยังไม่ค่อยมีใครกล้าเลย
point คือเมื่อเพิ่ม abstraction layer เข้ามาแทนที่การ interface กับ physical ตรงๆ ทำให้เกิด common interface/behavior ดังนั้นเมื่อจะปรับแก้อะไร ก้อสามารถทำได้ที่จุดเดียว แทนที่โอกาสเกิดปัญหาจะเปน O(n^2) หรือเผลอๆ O(n^d) ก้อเปน O(n) .. แต่แน่นอนว่าเมื่อมีการกำหนดสเปคไรใหม่ ของเดิมๆ ที่มีคงไม่ compat ทั้งหมด ต้องมีบ้างบางอย่างที่ต้องปรับแก้ แต่ระยะยาวแล้วการ interface ผ่าน virtual layer นั้นจะทำให้ใช้ effort เพื่อปรับแก้ต่างๆ น้อยกว่า ใครจะไป cloud จะโดนบอกเสมอ ว่าถ้าอยากได้ benefit เตมๆ ก้อต้องแก้แอพด้วยถึงจะนับว่าเปน cloud-app ได้ หากแค่โยนขึ้นไปบน IaaS เฉยๆ มันก้อเปนแค่การทำ virtualization
แต่อย่างน้อยก้อยังได้อีก point คือการก้าวข้าม physical limit เช่น การใช้ disk .. สมมติมี disk 2 ตัว แต่ละตัวเหลือที่อยู่ 2 GB ถ้ามีข้อมูลก้อนนึงขนาด 3 GB มันก้อเกบข้อมูลนี้ไม่ได้ ไม่งั้นแอพก้อต้องฉลาดรุจัก disk ทั้งหมดและสามารถแบ่งเขียนก้อนข้อมูลแล้วอ่านรวมทีหลังได้ แต่ถ้ามี virtual layer ที่ทำให้ layer อื่นมอง disk ทั้งหมดเปนผืนเดียว ปัญหาก้อจบได้ง่ายๆ แล้วถ้า virtual layer มันจัดการได้แบบ dynamic ก้อจะช่วยเรื่อง utilization กับ redundancy ได้อีก
ปัญหา มีหรือไม่มี มีบ่อยหรือไม่บ่อย ไม่สำคัญเท่าว่าถ้ามีปัญหาจะรับมืออย่างไร
aka ohmohm
ถึงได้มองว่าการเพิ่ม abstraction layer อย่าง virtualization เข้ามานั้น ในระยะยาวจะทำให้การตรวจเชคและแก้ปัญหานั้นทำได้สะดวกขึ้น เพราะมันทำให้เกิดการ separation of concerns
แต่แน่นอนว่าเมื่อมีการเพิ่ม component เข้าไปในระบบ ในอีกแง่นึงมันก้อทำให้มี complexity เพื่มขึ้น โดยเฉพาะในช่วงแรกๆ ที่ต้องปรับแก้ของเดิมที่มีอยู่ ทั้งเพราะ interface/behavior ต่างๆ ที่เปลี่ยนไปและเพราะ side-effect ต่างๆ ที่อาจไม่ทันคาดคิดมาก่อน.. แต่จากที่ผ่านๆ มา โดยรวมแล้วดูจะมีผลดีมากกว่าผลเสีย
เนื่องจาก cloud คงผ่าน network จึงต้องดูแล หรือแก้ไข ปัญหา network ด้วยล่ะ
aka ohmohm
ถ้าไม่ใช่ stand-alone .. ไงก้อยุ่งกับ network อยู่ดี :?
Cloud Computing นี่ส่วนหนึ่งเกิดได้เพราะ "ค่าบำรุงรักษา" (เงินเดือน Sys Admin นี่ล่ะ) มันพุ่งสูงขึ้นเรื่อยๆ ในทุกหน่วยงาน เพราะการใช้ IT ที่มากขึ้นนะครับ เขาเลยพยายามลดมันลงด้วยการโยนงานไปรวมๆ กัน
ในมุมมองผม IT Spending รวมๆ ไปถึงเงินที่ใช้จ้างงาน ไม่ได้ลดลงครับ งานแปลกประหลาด ประเภท Core Business ต้องตั้งเครื่องในบริษัท แต่เครื่องทั่วไปใช้ IaaS หรือเว็บใช้ PaaS แล้วต้อง Integrate กัน ทำ SSO ข้ามกัน ฯลฯ ยังมีอีกเยอะ และเพิ่มขึ้นเรื่อยๆ อาจจะลดความเร็วในการเพิ่มไปบ้าง
lewcpe.com, @wasonliw
"โยนงานไปรวมๆ กัน" .. คือแค่พยายามเพิ่ม utilization ใช่มั้ยคับ ยังไม่ถึงขั้น outsrc
คือถ้าพูดถึง outsrc ด้วย จะสงสัยต่อเรื่อง private cloud ว่าจะพิจารณารวมไม่รวมยังไงดี?