EAI & SOA & ESB … Microservices
ใน Blog ที่แล้ว เราได้มีการพูดถึงเทคโนโลยีที่มาแรงแซงทางโค้ง อย่างพวก Kubernetes , Docker กันไปบ้างแล้ว (สำหรับใครที่ตกเทรน ไปตามกันได้ที่ Kubernetes ) แต่นอกจากเจ้าสองตัวข้างบนแล้ว ยังมีเทคโนโลยีใหม่ๆ ที่สนับสนุน concept อย่างเช่น DevOps และ CI/CD (รายละเอียดเพิ่มเติมสามารถเข้าไปอ่านได้ที่ Blog ของ Sirisoft จ้า)
แต่เนื้อหาในบทความ จะลงลึกในส่วนของ Infrastructure ซะส่วนใหญ่ ไม่ก็เกี่ยวกับขั้นตอน หรือ วิธีการติดตั้ง แต่ยังไม่ค่อยได้พูดถึงในส่วนของตัว Application กันว่า เจ้าพวกเทคโนโลยีแบบนี้ Application แบบใดกันแน่ที่เหมาะสมในการใช้งาน
ใน Blog นี้เราจะมาพูดถึง application ที่เหมาะสม ในการใช้งานเทคโนโลยีใหม่ๆ ให้มีประสิทธิภาพ เพราะถึงแม้บาง application สามารถใช้งานได้ แต่บางอย่างก็ไม่เหมาะกับการทำ infra แบบนั้น
ก่อนที่จะพูดถึง Application ที่เหมาะสม จะขอย้อนกลับไปเกี่ยวกับ application ก่อนว่า application ส่วนใหญ่ ที่เรามีการใช้งานในปัจจุบันเป็นลักษณะแบบใด เพื่อที่จะได้เข้าใจภาพรวมมากขึ้น
application ส่วนใหญ่ที่นิยมใช้งานจะเป็นพวก application ที่ต้องมีการทำงานร่วมกันของหลายๆ ระบบ ที่เชื่อมต่อกัน อาจจะเป็นทั้งในเรื่องของข้อมูล หรือ ส่วนของ business logic แต่ในการเชื่อมต่อ ถ้าในตอนพัฒนา ไม่ได้ออกแบบ การเชื่อมต่อที่อาจจะเกิดขึ้นได้ในอนาคต ก็อาจจะติดปัญหาเรื่อง การใช้งานคนล่ะแพลตฟอร์ม ฮาร์ดแวร์ที่ต่างกัน หรือ รูปแบบข้อมูลที่ใช้ต่างกัน ทำให้ไม่สามารถเชื่อมต่อกันได้
ด้วยเหตุนี้สิ่งที่ทำให้ระบบ สามารถทำการเชื่อมต่อกันได้ เพื่อประโยชน์สูงสุดในองค์กร คือ Enterprise application integration หรือ EAI
Enterprise Application Integration คือ framework ของ software ที่จะทำหน้าที่เป็นตัวกลาง หรือ Middleware เพื่อเชื่อมการทำงานต่างๆ เพื่อให้สามารถทำงานร่วมกันได้อย่างมีประสิทธิภาพ เช่น การใช้ข้อมูลร่วมกัน , การติดต่อสื่อสารระหว่างระบบ
ส่วนเทคโนโลยีที่ทำให้ EAI นี้เกิดขึ้นจริง หรือที่ทำให้ EAI ประสบความสำเร็จ ก็จะเกี่ยวข้องกับ SOA และ ESB ที่เรารู้จักกันดี
กล่าวง่ายๆ ก็คือ EAI , SOA และ ESB จะคล้ายๆ กับ Russian stacking doll โดยมี EAI เป็นตุ๊กตาชั้นนอกสุด SOA เป็นตุ๊กตาชั้นกลาง และ ESB เป็นตุ๊กตาชั้นใน เราจะมาดูกันว่าตุ๊กตาแต่ล่ะชั้นจะทำให้เกิด EAI ได้อย่างไร
จะขออธิบายอย่างคร่าวๆ โดยเริ่มจากชั้นที่ ถัดมาจาก EAI อย่าง SOA หรือ Service Oriented Architecture
SOA เป็นเทคโนโลยีที่เน้นการพัฒนาให้อยู่ในรูปแบบของ web service ที่จะมีมาตรฐานในการเรียกใช้ ทำให้สามารถเรียกใช้จากต่างแพลตฟอร์ม หรือระบบปฏิบัติการที่แตกต่างกันได้ โดยส่วนใหญ่แล้ว จะนำส่วนของ Business Logic มาทำให้เป็น web service อย่างเช่น จากเดิมเรามีโปรแกรมของแผนก HR ที่ต้องทำการส่ง sms ถ้าเราไม่ได้พัฒนาแบบ soa เราก็จะเอาส่วนของ sms รวมไว้กับโปรแกรมของ HR เลย ซึ่งในการแก้ไข ถึงแม้เราจะแก้แค่ส่วน sms แต่มันจะกระทบกับทั้งโปรแกรม แต่พอเป็นในรูปแบบ soa จะทำการแยกส่วน sms ออกมา ให้อยู่ในรูปแบบของ web service ที่ HR สามารถเรียกใช้งานได้ นอกจากจะไม่กระทบเมื่อมีการแก้ไขแล้ว ถ้าระบบอื่นๆ ต้องการเรียกใช้ sms ก็สามารถใช้ web service ส่วนนี้ได้เลย โดยไม่ต้องมีการพัฒนาขึ้นใหม่ นอกจากจะช่วยลดระยะเวลาในการพัฒนา ยังช่วยลดในเรื่องของค่าใช้จ่ายอีกด้วย
ต่อมาในเรื่องของ ESB หรือ Enterprise Service Bus จะทำหน้าที่เป็นตัวกลาง ที่คอยเชื่อมต่อแต่ล่ะระบบเข้าด้วยกัน เพราะถ้าเป็นระบบ แบบเดิม ที่ไม่มีตัวกลางในการเชื่อมต่อ อย่างที่เรารู้จักกันดีแบบ Point-to-Point หรือการเชื่อมต่อแบบ จุดต่อจุด เมื่อต้องการเชื่อมต่อ ก็เชื่อมต่อระหว่างจุดต่อจุด โดยไม่ผ่านตัวกลางในการเชื่อมต่อ ทำให้ในอนาคต เมื่อมีการเชื่อมต่อที่เพิ่มมากขึ้น จะจัดการได้ยาก
โดย ESB จะเปลี่ยน การเชื่อมต่อให้เป็นแบบ Bus แทน ทำให้การเชื่อมต่อที่แต่เดิม จะมีเป็นจำนวนมาก ลดลงมาเหลือเพียงเท่ากับจำนวนระบบ ที่มีเท่านั้น ทำให้ช่วยลดปัญหาความยุ่งยากในการเชื่อมต่อระบบ การดูแลระบบ รวมถึงเวลาที่ต้องใช้ในการพัฒนาระบบให้ทำงาน ร่วมกับระบบอื่นๆ นอกจากนี้แล้ว Service Bus ยังมี ความสามารถอื่นๆ ที่จะช่วยในเรื่อง ของความยืดหยุ่นและจัดการ กับความเปลี่ยนแปลงของระบบงานที่เกี่ยวข้องได้อีกด้วย
ถ้าจะเปรียบเทียบง่ายๆ ก็คือ ถ้าเรามอง SOA เป็นแต่ล่ะระบบที่ ต้องการเชื่อมต่อกัน เป็นบ้านหนึ่งหลัง เจ้าตัว ESB จะเปรียบเหมือน ถนนสายหลักที่ทำหน้าที่เป็นตัวกลางเชื่อมต่อ บ้านแต่ล่ะหลังเข้าด้วยกัน
เทคโนโลยี SOA กับ ESB เป็นเทคโนโลยีที่มีมาตั้งแต่ ปี 1998 ทำให้ในการใช้งานส่วยใหญ่ จะอยู่บน Infrastructure แบบ n-Tier และถึงแม้จะทำทุกอย่างอยู่ในรูปแบบของ web service แต่ก็ยังมีข้อเสียอยู่ คือ เมื่อเวลาผ่านไป ในการพัฒนา application เพิ่มเติมในอนาคต ก็มีโอกาสทำให้ application มีขนาดใหญ่มากขึ้น จะเป็นเพียง app ขนาดใหญ่ตัวนึง แต่เพิ่มช่องทางในการเรียกใช้งาน web service เข้ามา ทำให้ในการที่เราเพิ่ม feature เข้าไปในระบบเดิม มันอาจจะกระทบกับระบบเก่า ทำให้เกิดการแก้ไขที่ยากขึ้นในอนาคต
ทำให้ในปัจจุบัน เพื่อรองรับกับการทำงานร่วมกับ Infrastructures แบบใหม่ จะมีการพัฒนา service ในรูปแบบใหม่ ซึ่งยังเป็นรูปแบบในการพัฒนา ที่เหมาะสมกับ Infrastructures แบบ kubernetes อีกด้วย เราเรียกรูปแบบการพัฒนานั้นว่า micro service
micro service จะเป็นรูปแบบในการพัฒนาที่แยก service ออกเป็น service ย่อยๆ
ซึ่ง service ที่ถูกแบ่งออกมา จะเป็น service ที่แบ่งย่อยกว่าแบบเดิมอย่าง soa เพื่อที่จะทำให้การแก้ไขในอนาคตไม่กระทบกับ service ส่วนอื่น กล่าวคือ แยกออกเป็น function ย่อยๆ ในเชิง business อย่างเช่น Business Logic หรือ เรื่องการใช้งาน database สมมุติมีการใช้ร่วมกันของ 2 app เราต้องแยกส่วนของ database ของ 2 app นั้นออกจากกันอย่างสิ้นเชิง หรือจริงๆ แล้วก็คือ Microservices เป็นรูปแบบหนึ่งของ SOA นั้นเอง
สิ่งที่เหมือนกันของทั้งคู่คือ ทั้งคู่คุยกันผ่านทาง web service แต่ ข้อแตกต่าง คือการคุยกันนั้น ถ้าเป็นในรูปแบบ soa จะเรียก web service ตรงผ่านจุดต่อจุด
แต่ตัว microservice จะคุยกันผ่านทาง api managed ที่จะคอยทำหน้าที่บอกว่า ในการใช้งาน มี microservice ใดให้ใช้บ้าง หรือต้องเรียก ไปยังที่อยู่ uri ใด ตัว api managed เป็นตัวที่ทำการจัดการในการเรียกใช้
ฟังดูเหมือนจะเป็นการเพิ่มงานในส่วนของ api แต่จริงๆแล้วในส่วนนี้ จะมี tool หลายอย่างที่เข้ามา รองรับการทำงาน ทำให้สามารถพัฒนาได้เร็ว และจัดการได้ง่าย
อย่างที่กล่าวว่า microservice เป็น subset ของ soa ทำให้ในการพัฒนา จะค่อยๆ พัฒนา microservice เพิ่มขึ้นมาในองค์กร โดยในรูป message pope จะเปรียบได้กับ ESB คือ เป็นการรวม การเชื่อมต่อ โดยเรียกผ่านเครื่องตัวกลาง ที่เราสามารถ monitor และสามารถเห็นภาพรวม การใช้งาน ว่าใครเชื่อมต่อกับใคร ล่าช้าที่ตรงไหน และยังมีในส่วน Business APIs ที่สามารถ expose ตัว service ออกไปให้ข้างนอกเรียกใช้งานได้ เช่น customer service มี function อะไรให้เรียกใช้งานบ้าง ส่วนนี้คือ business api จะเป็นตัวจัดการ ในการเรียกใช้ของ service
จะเห็นได้ว่าการพัฒนาแบบ microservice ทำให้สามารถ build และ deploy ได้ด้วยตัวเอง ไม่ขึ้นอยู่กับใคร ทำให้ Infrastructures ที่เป็นแบบ Docker หรือพวก Kubernetes ทำให้เราสามารถ scale up — scale down ให้เหมาะกับการใช้งานขณะนั้น มีเครื่องมืออย่าง CI/CD ที่ช่วยในการทำ automated ที่ช่วยในการ build และ deploy ทำให้ลดการทำงานในส่วยที่ต้อง manual ลงไปได้มาก แถมยังสามารถตอบโจทย์แนวทางสำหรับ DevOps ทำให้ในการพัฒนาโปรแกรมสะดวกและรวดเร็วมากขึ้น
มาถึงตรงนี้เพื่อนๆ คงจะเห็นภาพกันบ้างแล้วใช่มั้ยคะ ว่าในการพัฒนาโปรแกรมแบบ ใหม่ก็ต้องเลือกใช้ Infrastructures ให้เหมาะสมกับการใช้งานเพื่อให้เกิดประสิทธิภาพสูงสุด แต่ในขณะเดียวกัน ก็ไม่ได้หมายความว่า Infrastructures แบบใหม่ ไม่สามารถนำมาใช้งานกับ application ในรูปแบบเดิม แต่จะเป็นในเรื่องประสิทธิภาพมากกว่า ที่เราจะไม่สามารถใช้งาน Infrastructures ให้มีประสิทธิภาพสูงสุดได้
