E-BOOK

แนวทางสู�การรองรับระบบCLOUD-NATIVE APPLICATIONSสรุป 8 ขั้นตอนสำหรับคุณ

1 . ความเร็ว: สิ�งที่จำเป�นอย�างยิ�งต�อ DIGITAL BUSINESS ..................................................................3

2 . อะไรคือ CLOUD-NATIVE APPLICATION? ..................................................................................3

3 . APPLICATION สถาป�ตยกรรมแบบดั้งเดิม เปร�ยบเทียบกับ CLOUD-NATIVE .................................4

4 . หลัก 4 ประการของการพัฒนาและติดตั้งใช�งาน APPLICATION แบบ CLOUD-NATIVE

.................. 6

5. เส�นทางสู� APPLICATION แบบ CLOUD-NATIVE: 8 ขั้นตอน .........................................................8

ขั้นตอนที่ 1: สร�างวัฒนธรรมและแนวทางการทำงานแบบ DEVOPS ................................................................................... 8

ขั้นตอนที่ 2: เพ��มความเร็วให�กับ APPLICATION ที่มีอยู�ด�วยแนวทาง FAST MONOLITHS ................................................ 8

ขั้นตอนที่ 3: ใช� APPLICATION SERVICE เพ�่อเร�งความเร็วให�กับการพัฒนา ................................................................... 9

ขั้นตอนที่ 4: เลือกเคร�่องมือให�เหมาะสมกับงาน ................................................................................................................. 9

ขั้นตอนที่ 5: ให�บร�การระบบโครงสร�างพ�้นฐานแบบ SELF-SERVICE และ ON-DEMAND .................................................. 10

ขั้นตอนที่ 6: ทำระบบ IT ให�เป�นอัตโนมัติเพ�่อเร�งความเร็วให�กับการส�งมอบ APPLICATION .................................................. 11

ขั้นตอนที่ 7: ทำ CONTINUOUS DELIVERY และใช�เทคนิคการติดตั้งใช�งานระบบชั้นสูง ..................................................... 12

ขั้นตอนที่ 8: พัฒนาสถาป�ตยกรรมระบบให�เป�น Modular มากยิ�งข�้นไปอีก .......................................................................... 13

6 . ผลลัพธ�เชิงธุรกิจสำหรับ APPLICATION แบบ CLOUD-NATIVE .................................................. 14

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 2redhat.com

สารบัญ

1. ความเร็ว: สิ�งที่จำเป�นอย�างยิ�งต�อ DIGITAL BUSINESSเมื่อพ�ดถึงคำว�า Digital Business นั้นเราก็มักจะนึกถึงนวัตกรรมเชิงเทคโนโลยีที่หลากหลาย ไม�ว�าจะเป�นอ�ปกรณ�พกพา, เซ็นเซอร�อัจฉร�ยะ, อ�ปกรณ�สวมใส�, Virtual Reality, Chatbot, Blockchain, Machine Learning และอื่นๆ โดยสำหรับบางคนนั้น คำนี้อาจทำให�นึกถึงธุรกิจที่เป�น Digitally Native ที่เข�ามาเปลี่ยนรูปแบบการทำงานของธุรกิจที่มีอยู�แต�เดิมไปโดยสิ�นเชิง ส�งผลกระทบต�อหลากหลายบร�ษัทไปทั่วทั้งอ�ตสาหกรรม ในขณะที่สำหรับองค�กรจำนวนมากนั้น คำว�า Digital Business กลับหมายถึงการเปลีย�นแปลงวัฒนธรรมขององค�กรให�มีความคล�องตัวสูงข�้น เพ�่อให�ความต�องการที่เปลี่ยนแปลงไปอย�างรวดเร็วนั้นถูกตอบสนองได�ด�วยกระบวนการการพัฒนาและส�งมอบที่รวดเร็วและยืดหยุ�นกว�าเดิม ทั้งนี้เนื่องจากองค�กรส�วนใหญ�นั้นไม�สามารถที่จะเปลี่ยนแปลงระบบเทคโนโลยีที่ใช�งานทั้งหมดได�ในชั่วข�ามคืน หร�อไม�สามารถเป�ดรับต�อว�ธีการทำงานและแนวคิดใหม�ๆ ได�อย�างทันที ทำให�องค�กรเหล�านี้จ�งต�องค�อยๆ เปลี่ยนแปลงรากฐานของวัฒนธรรมองค�กร, กระบวนการทำงาน และเทคโนโลยี เพ�่อให�มีความเร็วและความคล�องตัวที่สูงข�้นกว�าเดิม

จากการที่ Software นั้นได�มีความสำคัญมากข�้นต�อว�ธีการที่ผู�ใช�งานมีปฏิสัมพันธ�กับธุรกิจ และส�งผลต�อว�ธีการที่ธุรกิจจะยังคงมีความสามารถในการแข�งขันได�ด�วยการสร�างสรรค�นวัตกรรมใหม�ๆ ก็ทำให�ความเร็วในการพัฒนาและส�งมอบ Application นั้นกลายเป�นสิ�งจำเป�นสิ�งใหม�ในการก�าวสู�การเป�น Digital Business

แนวทางการพัฒนาแบบ Cloud-Native นั้นได�อธิบายถึงว�ธีการที่จะปรับปรุงระบบ Application แบบเดิมให�ทันสมัยยิ�งข�้นและสร�าง Application ข�้นมาโดยอ�างอิงกับหลักการทำงานของ Cloud ด�วยการใช�บร�การต�างๆ และเป�ดรับต�อกระบวนการที่ถูกออกแบบมาเพ�่อความคล�องตัวและการทำงานแบบอัตโนมัติบน Cloud โดยเฉพาะ ซึ่งภายใน E-Book ฉบับนี้ก็จะอธิบายขั้นตอนทั้งหมดโดยละเอียดเพ�่อเป�นส�วนหนึ่งที่จะช�วยให�คุณประสบความสำเร็จได�จากตำแหน�งที่คุณอยู�ในวันนี้ไปสู�อนาคตที่คุณจะสามารถเป�ดรับต�อแนวทางการพัฒนา Cloud-Native Application ได�ในอนาคต

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 3redhat.com

2. อะไรคือ CLOUD-NATIVE APPLICATION?Cloud-Native Application คือ Application ที่ถูกพัฒนาข�้นมาโดยนำข�อดีของระบบ Cloud Computing มาใช�ในการเพ��มความเร็ว, ความยืดหยุ�น และคุณภาพให�สูงข�้น ในขณะที่ลดความเสี่ยงในการติดตั้งระบบให�ลดน�อยลง ซึ่งหากพ�จารณาจากชื่อแล�ว Cloud-Native Application นี้ไม�ได�มุ�งเน�นไปที่ประเด็นว�า Application จะถูกติดตั้งใช�งานที่ไหน แต�สำคัญที่ว�ธีการในการสร�าง, ติดตั้งใช�งาน และบร�หารจัดการ Application เหล�านั้นมากกว�า

แนวทางแบบ Cloud-Native นี้คล�ายคลึงกับสถาป�ตยกรรมแบบ Microservices อย�างไรก็ดี ถึงแม�ว�า Microservices จะสามารถเป�นหนึ่งในผลพลอยได�ที่เกิดข�้นจากสร�าง Cloud-Native Application ก็ตาม ก็ยังมีขั้นตอนอีกหลายขั้นตอนกว�าที่จะสามารถบร�หารจัดการ Microservices บนระบบ Production ได�ในระดับที่สมบูรณ� Microservices นั้นไม�ได�บังคับให�ต�องนำข�อดีทั้งหมดที่จะได�รับจาก Cloud-Native Application มาใช� ในขณะที่หลายๆ องค�กรนั้นก็ยังคงได�รับประโยชน�จากแนวทางแบบ Cloud-Native ด�วยการมุ�งเน�นไปที่การสร�างระบบ Monolith ที่มีความเป�น Modular มากข�้นโดยอาศัยหลักการเดียวกันได�เช�นกัน

ว�วัฒนาการไปสู�การพัฒนาและการส�งมอบแบบ Cloud-Native นี้มีหลายมิติ ซึ่งจะส�งผลกระทบต�อทั้งวัฒนธรรม, กระบวนการ, สถาป�ตยกรรม และเทคโนโลยี ด�วยเหตุนี้เอง การเดินทางครั้งนี้จ�งไม�ได�มีปลายทางที่เป�าหมาย แต�เป�นการเดินทางที่สามารถรองรับการเปลี่ยนแปลงที่เกิดข�้นหลายต�อหลายครั้งได�เสียมากกว�า ซึ่งประเด็นนี้ก็ถือเป�นความท�าทายไม�น�อยทีเดียว

“องค�กรที่เร��มก�าวสู� Digital นั้นมีโอกาส 8 เท�าที่จะเติบโตกว�าเดิม

แต�ก็ยังตามหลังธุรกิจที่เป�น Digital Native อยู�ดี”

Bain Survey: For Traditional Enterprises, the Path to Digital

and the Role of Containers

CHRISTIAN POSTA CHIEF ARCHITECT AT RED HAT AND

AUTHOR OF MICROSERVICES FOR JAVA DEVELOPERS

SOURCE: INFOQ, “DEFINING CLOUD NATIVE: A PANEL

DISCUSSION,” 2017.

“’Cloud-Native’ คือคำขยายที่ใช�เพ�่ออธิบาย Application, สถาป�ตยกรรม, Platform/

ระบบโครงสร�างพ�้นฐานและกระบวนการ ซึ่งเมื่อนำมาผสานรวมกันแล�วก็ทำให�เกิด

ความคุ�มค�าในการทำงานด�วยการทำให�เราสามารถเพ��ม

ความสามารถในการตอบสนองต�อการเปลี่ยนแปลงได�

อย�างรวดเร็วและลดการเกิดของเหตุการณ�ที่ไม�คาดฝ�นลง”

TABLE 1. TRADITIONAL VERSUS CLOUD-NATIVE APPLICATION DEVELOPMENT

TRADITIONAL CLOUD-NATIVE

FOCUS Longevity and stability Speed to market

DEVELOPMENT METHODOLOGY

Waterfall, semi-agile development Agile development, DevOps

TEAMS Isolated development, operations, QA, and security teams

Collaborative DevOps teams

DELIVERY CYCLES Long Short and continuous

APPLICATION ARCHITECTURE

Tightly coupled

Monolithic

Loosely coupled

Service-based

Application programming interface (API)-based communication

INFRASTRUCTURE Server-centric

Designed for on-premise

Infrastructure-dependent

Scales vertically

Preprovisioned for peak capacity

Container-centric

Designed for on-premise and cloud

Portable across infrastructure

Scales horizontally

On-demand capacity

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 4redhat.com

3. APPLICATION สถาป�ตยกรรมแบบดั้งเดิม เปร�ยบเทียบกับ CLOUD-NATIVE APPLICATIONSความแตกต�างระหว�างการพัฒนา Application แบบ Cloud-Native และแบบเดิมนั้นทำให�เห็นถึงการเปลี่ยนแปลงที่จำเป�นในหลายแง�มุม

3.1 การพัฒนาและส�งมอบ APPLICATION แบบดั้งเดิมApplication จำนวนมากที่มีความจำเป�นต�อกระบวนการทำงานในธุรกิจนั้นไม�ได�ถูกออกแบบมาโดยคำนึงถึงประสบการณ�เชิง Digital แต�แรก แต�ถูกออกแบบมาภายใต�การใช�งานมาอย�างต�อเนื่องยาวนาน ทำให� Application เหล�านี้ถูกสร�างข�้นมาโดยระบบแบบ Monolith ที่ทำงานร�วมกันอย�างแนบแน�น และถูกสร�างข�้นมาในช�วงเวลาที่ความต�องการของระบบถูกกำหนดเอาไว�อย�างชัดเจน ซึ่งส�วนใหญ�มักเป�นช�วงเวลาอันยาวนานก�อนที่ระบบจะถูกส�งมอบได�จร�ง

แนวทางการพัฒนาระบบเหล�านี้ส�วนใหญ�มักจะเป�นแบบ Waterfall และ Sequential ที่กินเวลายาวนาน และได�ประยุกต�นำแนวปฏิบัติแบบ Agile ไปใช�งานเมื่อเร็วๆ นี้เท�านั้น ขั้นตอนในการพัฒนา, ทดสอบ, ตรวจวัด Security Compliance, ติดตั้งใช�งาน และบร�หารจัดการ Application เหล�านี้จ�งถูกแยกขาดจากกันตามหน�าที่การทำงานโดยแต�ละทีม, ผู�คนในแต�ละบทบาทความรับผิดชอบ โดยมีการสื่อสารแบบเชิงเส�นระหว�างทีมงานแต�ละทีม

Application เหล�านี้ถูกสร�างข�้นมาให�เป�นระบบขนาดใหญ�, มีความสามารถหลากหลาย, ทำงานร�วมกันอย�างใกล�ชิด โดยมี User Interface, บร�การอันหลากหลาย, โค�ดที่ใช�ในการเข�าถึงข�อมูล และส�วนประกอบอื่นๆ ถูกผสานรวมเข�าเป�น Application เดียว ไม�ว�าเทคโนโลยีที่เลือกใช�จะเป�นเทคโนโลยีใดก็ตาม ตัวอย�างเช��น ระบบ E-Commerce Application ที่ถูกสร�างข�้นมาให�เป�นระบบ Monolith หลายระบบที่ทำงานร�วมกันอย�างใกล�ชิด โดยมากก็มักจะรวมเอาทุกความสามารถทางด�าน Web User Interface, Product Catalog, Shopping Cart, Product Recommendation, Product Rating & Review, Payment System และส�วนประกอบอื่นๆ ที่จำเป�นต�อการสั่งซื้อสินค�าบนระบบ E-Commerce นี้เข�าไว�ด�วยกันเป�น Application เพ�ยงชุดเดียว

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

* Gartner defines bimodal as the practice of managing two separate but coherent styles of work: one focused on

predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and understood.

It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital

world. Mode 2 is exploratory, experimenting to solve new problems and optimizing for areas of uncertainty.

3.2 การพัฒนาและส�งมอบ APPLICATION แบบ CLOUD-NATIVEด�วยการให�ความสำคัญไปที่ความเร็วในการเป�ดตัวสินค�าออกสู�ตลาด การพัฒนาแบบ Cloud-Native Application นั้นจ�งต�องการความคล�องตัวที่สูงข�้น, การพัฒนาแบบ Service-based และ API-based รวมถึงแนวทางการส�งมอบอย�างต�อเนื่อง (Continuous Delivery) ซึ่งความสามารถเหล�านี้ต�างก็ถูกสนับสนุนโดยความร�วมมือจาก DevOps ภายในทีมพัฒนาและทีมส�งมอบ, สถาป�ตยกรรมแบบ Modular ที่แยกย�อยมากข�้น และระบบโครงสร�างพ�้นฐานที่ยืดหยุ�นซึ่งสามารถเพ��มขยายแบบแนวกว�างได�ตามต�องการ, สนับสนุนสภาพแวดล�อมการทำงานที่หลากหลาย และทำให� Application สามารถถูกนำไปติดตั้งย�ายระบบได�อย�างอิสระ

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

อย�างไรก็ดี ความสามารถหลายๆ ประการของระบบแบบเดิมๆ นั้นต�างก็ล�าสมัยและไม�จำเป�นต�อการใช�งานบนระบบ Cloud อีกต�อไป หร�อไม�ภายในบร�การ Cloud เองก็มีความสามารถเหล�านี้ที่พร�อมใช�งานได�อย�างง�ายดายอยู�แล�ว ระบบ Cloud นั้นทำให�การบร�หารจัดการวงจรชีว�ตของโฮสต�แต�ละเคร�่องเป�นไปได�อย�างง�ายดาย ในขณะที่ยังช�วยให�เหล�าองค�กรนั้นได�รับประโยชน�จากหลักพ�้นฐานที่ทำให�ระบบโครงสร�างพ�้นฐานไม�อาจถูกปลอมแปลงแก�ไขได� และการปรับแต�งให�โฮสต�แต�ละเคร�่องนั้นตอบโจทย�ต�อ Application เดี่ยวๆ ได�อย�างเต็มที่

เส�นทางสู� Cloud-Native Application นั้นอาจยาวไกลแตกต�างกันสำหรับแต�ละองค�กร เพ�ยงแค�การสร�าง Microservices ข�้นมาได�นั้นไม�ได�นำไปสู�การมีคุณภาพของการให�บร�การ และไม�ได�ทำให�การส�งมอบระบบสามารถทำได�ถี่ข�้นแต�อย�างใด ซึ่งทั้งสองสิ�งนี้ต�างก็เป�นสิ�งที่จำเป�นต�อ Digital Business ในทำนองเดียวกัน เพ�ยงแค�การนำเคร�่องมือมาใช�นั้นไม�ได�หมายความว�าองค�กรจะสนับสนุนการพัฒนาแบบ Agile หร�อ IT Automation เพ�ยงอย�างเดียวนั้นก็ไม�ได�นำไปสู�ความเร็วแบบเดียวกับที่จะได�รับจากแนวทางแบบ Cloud-Native แต�ที่จร�งแล�วมันคือการผสมผสานระหว�างแนวทางการปฏิบัติงาน, เทคโนโลยี, กระบวนการ และแนวคิดที่จะเป�นป�จจัยซึ่งนำไปสู�ความสำเร็จต�างหาก

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 5redhat.com

ภายในป� 2020 มากกว�า 50% ของ Application แบบ Mode 1*

ที่ถูกย�ายจากระบบ Data Center ส�วนตัวไปสู� Public Cloud นั้น

จะถูกเข�ยนข�้นใหม�ด�วยสถาป�ตยกรรมแบบ

Cloud-Native เพ��มข�้นจากปร�มาณเพ�ยง 10% ในป� 2017

Gartner: Why You Must Begin Delivering Cloud-Native Offerings

Today, Not Tomorrow, January 2018

SERVICE-BASED ARCHITECTURE

API-BASED COMMUNICATION

Architecture Communication Infrastructure Process

SERVICE-BASED API-DRIVEN CONTAINERS DEVOPS

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 6redhat.com

4. หลัก 4 ประการของการพัฒนาและติดตั้งใช�งาน APPLICATION แบบ CLOUD-NATIVEการพัฒนา Application แบบ Cloud-Native คือแนวทางในการสร�างและใช�งาน Application โดยการนำข�อดีของระบบ Cloud Computing ซึ่งอยู�บนพ�้นฐานของหลัก 4 ประการ ได�แก� สถาป�ตยกรรมแบบ Service-based, การสื่อสารแบบ API-based, ระบบโครงสร�างพ�้นฐานแบบ Container-based และกระบวนการ DevOps

สถาป�ตยกรรมแบบ Service-based อย�างเช�น Microservices นั้น สนับสนุนการสร�างบร�การแบบแบ�งส�วนย�อยและไม�ข�้นต�อกัน โดยแนวทางสถาป�ตยกรรมแบบแบ�งส�วนย�อยแบบอื่นๆ อย�างเช�น Miniservices ซึ่งก็ยังคงสนับสนุนการออกแบบแบบ Service-based และไม�ข�้นต�อกันนั้นก็ช�วยให�องค�กรสามารถเพ��มความเร็วในการพัฒนา Application ให�สูงข�้นได�โดยไม�เพ��มความซับซ�อนของระบบเช�นกัน

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

การออกแบบแบบ API-based อนุญาตให�มีเพ�ยงการสื่อสารระหว�างช�องทางของแต�ละบร�การได�ผ�านระบบเคร�อข�ายเท�านั้น ทำให�สามารถลดความเสี่ยงของการเชื่อมต�อโดยตรง, การใช�หน�วยความจำร�วมกัน หร�อการอ�านข�อมูลของทีมอื่นๆ โดยตรงได� การออกแบบนี้จะช�วยเพ��มให� Application และบร�การต�างๆ สามารถถูกเข�าถึงโดยอ�ปกรณ�ได�อย�างกว�างขวางในรูปแบบที่หลากหลายยิ�งข�้น

CONTAINER-BASED

INFRASTRUCTURE

DEVOPS

PROCESSES

Application แบบ Cloud-Native นั้นต�องอาศัย Container เป�นรูปแบบการทำงานกลางเพ�่อให�สามารถทำงานได�ในสภาพแวดล�อมของเทคโนโลยีที่หลากหลายได�ด�วยว�ธีการเดียวกัน และรองรับการย�าย Application ไปทำงานบนสภาพแวดล�อมหร�อระบบโครงสร�างพ�้นฐานที่แตกต�างกันได� ซึ่งรวมถึงทั้ง Public Cloud, Private Cloud และ Hybrid Cloud โดยเทคโนโลยี Container น้ันอาศัยความสามารถในการทำ Virtualization ที่ระดับชั้นของระบบปฏิบัติการเพ�่อแบ�งทรัพยากรการประมวลผลที่มีอยู�ให�กับ Application จำนวนมาก ในขณะที่ยังคงมั่นใจได�ว�า Application เหล�านั้นจะยังคงทำงานได�อย�างปลอดภัย และแยกขาดจากกันและกัน

Application แบบ Cloud-Native นั้นสามารถเพ��มขยายได�แบบแนวกว�าง สามารถเพ��มทรัพยากรของระบบเข�าไปได�ด�วยการเพ��มเพ�ยงแค� Application Instance เข�าไปเท�านั้น ซึ่งการเพ��มขยายนี้มักทำได�อย�างอัตโนมัติภายในระบบโครงสร�างพ�้นฐานของ Container เอง

การใช�ทรัพยากรที่ต่ำและความหนาแน�นที่สูงของ Container น้ีทำให� Container จำนวนมากสามารถทำงานร�วมกันได�ภายใน Virtual Machine หร�อ Physical Server เพ�ยงเคร�่องเดียว ทำให�เหมาะสมต�อการนำไปใช�ให�บร�การ Application แบบ Cloud-Native เป�นอย�างมาก

การพัฒนา Application สำหรับแนวทางแบบ Cloud-Native นี้เป�นไปตามแนวทางแบบ Agile พร�อมด�วยหลักการของการทำ Continuous Delivery และ DevOps ซึ่งมุ�งเน�นไปที่การสร�างและส�งมอบ Application ได�ด�วยการทำงานร�วมกันระหว�างทีมพัฒนา, ทีมตรวจสอบคุณภาพ, ทีมด�านความมั่นคงปลอดภัย, ทีมดูแลรักษาระบบ IT และทีมอื่นๆ ที่เกี่ยวข�องกับการส�งมอบระบบทั้งหมด

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 7redhat.com

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 8redhat.com

5. เส�นทางสู� APPLICATION แบบ CLOUD-NATIVE: 8 ขั้นตอนขั้นตอนที่ 1: สร�างวัฒนธรรมและแนวทางการทำงานแบบ DEVOPSเส�นทางสู� APPLICATION แบบ Cloud-Native นี้ ทีมพัฒนาและทีมดูแลระบบ IT ต�องมีการเปลี่ยนแปลงว�ธีการหลากหลาย ในการสร�างและติดตั้งใช�งาน Application ให�รวดเร็วยิ�งข�้นและมีประสิทธิภาพมากยิ�งข�้น ไม�ว�าจะเป�นธุรกิจในอ�ตสาหกรรมใด หร�อขนาดใดก็ตาม ทุกๆ ธุรกิจนั้นต�างก็ต�องทำการพ�จารณากิจกรรม, เทคโนโลยี, ทีมงาน และกระบวนการทั้งหมดร�วมกัน เพ�่อสร�างวัฒนธรรม DevOps ข�้นมา และเพ�่อให�ได�รับประโยชน�จากเทคโนโลยีใหม�ๆ, แนวทางที่รวดเร็วข�้น และการสื่อสารที่ ใกล�ชิดยิ�งข�้น องค�กรนั้นก็ต�องนำหลักการและคุณค�าของวัฒนธรรม DevOps มาใช�งานให�ได�อย�างแท�จร�ง และจัดการให�ตนเองได�รับคุณค�าจากสิ�งเหล�านี้ให�ได�

ความซับซ�อนในการบร�หารจัดการสภาพแวดล�อมที่หลากหลายและอยู�อย�างกระจัดกระจาย, ระบบ Application สมัยเก�าที่ ถูกปรับแต�งเป�นอย�างมาก และ Application Workload รูปแบบใหม�ๆ ในยุคสมัยที่เกิดนวัตกรรมทาง Digital อย�างรวดเร็ว นั้น DevOps ก็อาจกลายเป�นความท�าทายของบางองค�กรได� เนื่องจากยังมีประโยชน�อีกหลายประการที่องค�กรจะได�รับจาก การประยุกต�นำแนวทางของ DevOps ไปใช�ใน Application ที่มีอยู�ให�มากข�้น

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

ใน Red Hat Open Innovation Labs องค�กรต�างๆ นั้นได�รับการชี้แนะกระบวนการทางด�าน DevOps เพ�อ่ให�เกิดการ

ทดลอง, การล�มเหลวอย�างรวดเร็ว, การตัดสินใจอย�างโปร�งใส และใช�การรับรู�และการให�รางวัลเพ�่อสร�างความเชื่อใจและความร�วมมือให�เกิดข�้น ภายใต�สภาพแวดล�อมดังกล�าวนี้ที่ซึ่งถูกออกแบบมาเพ�่อเร�งให�เกิดนวัตกรรม แต�ละทีมนั้นก็ได�ใช� เทคโนโลยี Open Source เพ�่อเร�งสร�าง Prototype, สัมผัสประสบการณ�ของ DevOps และนำว�ถีการทำงานแบบ Agile ไป ใช�จร�งเร�ยนรู�เพ��มเติมว�า Red Hat Open Innovation Labs จะสามารถช�วยคุณในเร�่องของ DevOps ได�อย�างไร DOWNLOAD E-BOOK

ขั้นตอนที่ 2: เพ��มความเร็วให�กับ APPLICATION ที่มีอยู�ด�วยแนวทาง FAST MONOLITHSเมื่อเร��มต�นก�าวสู� Application แบบ Cloud-Natiove องค�กรนั้นไม�ควรจะมุ�งเน�นเฉพาะโครงการพัฒนา Application ใหม�ๆ เพ�ยงอย�างเดียว เพราะ Application ดั้งเดิมจำนวนมากนั้นก็ยังคงมีความสำคัญสูงต�อการดำเนินธุรกิจและการสร�างรายได� และไม�สามารถถูกทดแทนได�อย�างง�ายดาย อีกทั้ง Application เหล�านี้ก็ยังต�องถูกผสานรวมเข�ากับ Application แบบ Cloud-Native ที่จะเกิดข�้นมาในอนาคตด�วย แต�คุณจะเพ��มความเร็วให�กับระบบแบบ Monolith ที่มีอยู�เดิมได�อย�างไร? คำตอบก็คือการใช�แนวทางแบบ Fast Monolith ด�วยการย�ายสถาป�ตยกรรม Monolithic แบบเดิมให�กลายเป�นแบบ Modular มากข�้น, มีความเป�นสถาป�ตยกรรมแบบ Service-based มากข�้น และสื่อสารแบบ API-based มากข�้น

ก�อนที่จะเร��มต�นภารกิจอันใหญ�หลวงในการ Refator ระบบ Application แบบ Monolithic ให�กลายเป�น Microservices นั้น องค�กรควรจะเร��มจากการสร�างพ�้นฐานที่แข็งแรงสำหรับสถาป�ตยกรรมแบบ Monolithic เสียก�อน ถึงแม�ว�า Application แบบ Monolithic นั้นจะทำให�เรานึกถึงการขาดความยืดหยุ�นและชื่อเสียงที่ไม�ค�อยจะดีนักจากว�ธีการที่ Application เหล�านี้ ถูกสร�างข�้นมา แต�ในทางกลับกันนั้น Fast Monolith สามารถได�รับประโยชน�หลายประการจาก Agile ในรูปแบบเดียวกับ Microservices โดยไม�ทำให�ระบบซับซ�อนมากข�้นหร�อมีค�าใช�จ�ายที่สูงข�้นแต�อย�างใด

การประเมินแนวทางแบบ Fast Monolith ก�อนนี้จะทำให�มั่นใจได�ว�า Application นั้นจะถูกสร�างข�้นมาตามหลักการออกแบบ ที่แข็งแรงและอยู�ภายใต�ขอบเขตที่กำหนดเอาไว�เป�นอย�างดี แนวทางนี้สนับสนุนให�เกิดการเปลี่ยนแปลงไปสู�สถาป�ตยกรรม แบบ Microservices ได�แบบค�อยเป�นค�อยไปและมีความเสี่ยงต่ำได�ถ�าต�องการ การเปลี่ยนไปใช� Fast Monolith ด�วยว�ธีการ ดังกล�าวนี้จะช�วยสร�างรากฐานที่มั่นคงให�กับการก�าวไปสู�สถาป�ตยกรรมแบบ Microservices ได�อย�างประสบความสำเร็จ

มากกว�าคร�่งหนึ่ง (51%) ขององค�กรขนาดใหญ�ได�มีการใช�

แนวทาง DevOps แล�ว อย�างไรก็ดี องค�กรเหล�านี้

ส�วนใหญ�นั้นยังคงใช� DevOps กับ App เพ�ยงแค� 10-40%

เท�านั้น (เฉลี่ยเพ�ยง 20%)

IDC PaaS View for the DeveloperSurvey, November 2017

SIMON BROWNCODINGTHEARCHITECTURE.COM/

PRESENTATIONS/SA2015-MODULAR-MONOLITHS

“ถ�าคุณไม�สามารถสร�าง Monolith ที่มีรากฐานที่แข็งแรงได�

อะไรที่ทำให�คุณคิดว�าคุณจะสามารถสร�างกลุ�มของ

Microservices ได�อย�างมั่นคง?”

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 9redhat.com

ถ�า Application ไม�ได�ถูกออกแบบมาให�ใช�แนวทาง Fast Monolith ได� Application เหล�านั้นก็ยังสามารถถูกทำให�เร็วข�้นได�ด�วยการย�ายระบบ Monolith ที่มีอยู�ไปสู�ระบบ Container-based แทน การเปลี่ยนแปลงในรูปแบบนี้จะช�วยเร�งความเร็วให�กับการติดตั้งใช�งานและทำให�ได�รับผลบตอบแทนในการลงทุน (ROI) ที่สูงยิ�งข�้น การผสานระบบหร�อการพัฒนาความสามารถใหม�ๆ ให�กับ Monolith นี้ก็สามารถเกิดข�้นได�ด�วยการใช�เทคนิคและแนวทางแบบ Cloud-Native

นอกจากนี้ คุณยังสามารถเร��มต�นแยกระบบ Monolith ของคุณให�กลายเป�นส�วนประกอบย�อยที่มีขนาดเล็กลงได�ตามความเหมาะสม ด�วยการใช�แนวทางแบบแบ�งช�วงการทำงาน

ขั้นตอนที่ 3: ใช� APPLICATION SERVICE เพ�่อเร�งความเร็วให�กับการพัฒนาการใช�ซ้ำได�นั้นเป�นหนึ่งในหัวใจสำคัญสำหรับการเร�งความเร็วในการพัฒนา Software มาโดยตลอด และประเด็นนี้ก็ ไม�ได�เป�นข�อยกเว�นสำหรับ Application แบบ Cloud-Native แต�อย�างใด อย�างไรก็ดี ส�วนประกอบที่สามารถใช�งานได�ซ้ำสำหรับ Application แบบ Cloud-Native นั้นจะต�องถูกปรับแต�งและผสานเข�ากับโครงสร�างพ�้นฐานของระบบ Cloud-Native เพ�่อให�เกิดประโยชน�สูงสุด

ทำไมคุณถึงจะต�องสร�างบร�การ Caching ข�้นมาใหม�? กำหนดกฎการทำงานของระบบต�างๆ ใหม�? ผสานเชื่อมระบบเข�าด�วยกันใหม�? ติดตั้งตัวจัดการ Mobile และ API ใหม�? ติดตั้งบร�การ Data Virtualization ใหม�? ติดตั้ง Messaging Broker ใหม�? หร�อติดตั้ง Serverless Framework ใหม�? ในเมื่อคุณสามารถใช�ระบบเดิมที่มีอยู�ซึ่งถูกปรับแต�งและผสานระบบเข�ากับโครงสร�างพ�้นฐานของ Container ที่มีอยู�แล�วได� บร�การของ Application เหล�านี้ ไม�ว�าจะอยู�ในรูปแบบของ Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) หร�อ iPaaS ก็ตาม ต�างก็เป�นเคร�่องมือที่พร�อมให�เหล�านักพัฒนานำไปใช�งานได�ทันทีทั้งสิ�น

Application แบบ Cloud-Native นั้นอาจจะต�องการบร�การประเภทนี้อย�างน�อยหนึ่งชนิดหร�อมากกว�าเพ�่อช�วยให�นักพัฒนาสามารถทำงานได�อย�างรวดเร็วยิ�งข�้นและทำให� Application ออกสู�ตลาดได�เร็วยิ�งข�้น ซึ่งในขณะที่ DevOps และ Container ช�วยเร�งความเร็วในการส�งมอบและติดตั้งใช�งาน Application แบบ Cloud-Native อยู�นั้น บร�การต�างๆ ของ Application ก็จะช�วยเร�งความเร็วในการพัฒนาให�สูงข�้นไปพร�อมกัน

ตัวอย�างเช�น นักพัฒนา Application แบบ Cloud-Native นั้นสามารถใช�ประโยชน�จาก Application Service เพ�่อสร�างระบบที่ไม�ได�ทำงานได�ดีเฉพาะบนระบบโครงสร�างพ�้นฐานของ Container เท�านั้น แต�ยังใช�ข�อดีจากตัว Platform อย�างเช�นการทำ CI/CD Pipeline, การติดตั้งใช�งานแบบ Rolling และ Blue/Green, การเพ��มลดขนาดระบบโดยอัตโนมัติ, การเสร�มความทนทาน และอื่นๆ ได�ด�วย

ขั้นตอนที่ 4: เลือกเคร�่องมือให�เหมาะสมกับงานเนื้อหาที่เพ��มข�้นในการศึกษาทางด�าน Software อย�างเช�น Internet of Things (IoT), Machine Learning, Artificial Intelligence (AI), Data Mining, Image Recognition, Self-Driving Car และอื่นๆ นั้นได�ส�งผลให�เกิด Framework, ภาษา และแนวทางในการพัฒนา Software ที่หลากหลายยิ�งข�้น

การสร�าง Application แบบ Cloud-Native เองนั้นก็มีความหลากหลายมากข�้นเช�นกันเนื่องจากมีภาษาและ Framework ให�เลือกใช�งานได�หลากหลายเพ�่อตอบโจทย�ความต�องการเฉพาะของแต�ละ Application ซึ่งก็ส�งผลให�เกิดความซับซ�อนที่สูงข�้นในการใช�งานระบบ Application แบบ Container-based ที่สนับสนุนการใช�งาน Framework, ภาษา และสถาป�ตยกรรมตามที่ต�องการในการพัฒนาแบบ Cloud-Native ตามไปด�วย

นอกจากนั้น การพัฒนาแบบ Cloud-Native นั้นก็ยังต�องมีการเลือกใช�เคร�่องมือที่เหมาะสมสำหรับแต�ละงาน ไม�ว�า Application แบบ Cloud-Native นั้นจะถูกพัฒนาโดยใช�แนวทาง 12-factor, ใช�การออกแบบแบบ Domain-based, ใช�การออกแบบและพัฒนาแบบ Test-based, ใช� MonolithFirst, ใช� Fast Monolith, ใช� Miniservices หร�อใช� Microservices ก็ตาม ระบบ Cloud-Native นั้นก็จะต�องรองรับการผสมผสานระหว�าง Framework, ภาษา และสถาป�ตยกรรมที่หลากหลายให�ได�ตามความต�องการของแนวทางการพัฒนาที่เลือก อีกทั้งระบบ Container-based ที่ใช�งานนั้นก็ควรจะสนับสนุน Runtime และ Framework ที่มีการอัปเดตอย�างต�อเนื่องมีเทคโนโลยีเปลี่ยนแปลงไปได�

Serverless

JavaScript everywher Ce loud native Java

ReactiveLightweight/Embeddable

Figure 1. Cloud-native application development becomes even more diverse

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 10redhat.com

ขั้นตอนที่ 5: ให�บร�การระบบโครงสร�างพ�้นฐานแบบ SELF-SERVICE และ ON-DEMANDว�ถีแห�ง Agile นั้นได�ช�วยให�นักพัฒนาสามารถสร�างและอัปเดต Software ได�อย�างรวดเร็ว แต�ในขณะเดียวกันก็ขาดว�ธีการในการเข�าถึงระบบโครงสร�างพ�้นฐานได�อย�างทันทีเมื่อจำเป�น ในการนำ Application ข�้นสู�ระบบ Production นั้น ความเร็วในการออกสู�ตลาดก็จะได�รับผลกระทบ การสร�าง Ticket แจ�งป�ญหาและรอเวลานานเป�นสัปดาห�เพ�่อให�ผู�ดูแลระบบ IT ทำการเพ��มทรัพยากรให�นั้นไม�ใช�แนวทางที่ยั่งยืนอีกต�อไปในยุคสมัยที่ระบบโครงสร�างพ�้นฐานนั้นมีราคาไม�แพงแต�ผู�ที่มีทักษะทางด�านว�ศวกรรมเป�นอย�างดีนั้นมีค�าตัวสูง

การเป�ดให�เข�าถึงระบบโครงสร�างพ�้นฐานได�ในแบบบร�การตัวเอง (Self-Service) และตามต�องการ (On-Demand) ถือเป�นทางเลือกที่ดีซึ่งจะช�วยให�ไม�เกิดป�ญหา Shadow IT ข�้น โดยการอนุญาตให�นักพัฒนาสามารถเข�าถึงระบบโครงสร�างพ�้นฐานได�ตามที่ต�องการทุกเมื่อ แต�ว�ธีการนี้จะได�ผลดีก็ต�อเมื่อแผนกผู�ดูแลระบบนั้นสามารถควบคุมและตรวจสอบระบบที่มักจะเปลี่ยนแปลงอย�างรวดเร็วและมีความซับซ�อนสูงได�

เทคโนโลยีระบบ Container และระบบบร�หารจัดการ Container นั้นได�สร�างช�องทางเสมือนในการเข�าถึงระบบโครงสร�างพ�้นฐานเบื้องหลังอย�างง�าย และทำให�เกิดการบร�หารจัดการ Life-Cycle ของ Application สำหรับระบบโครงสร�างพ�้นฐานทั้งหมด ครอบคลุมทั้ง Data Center, Private Cloud และ Public Cloud ดังนั้นะบบ Container จ�งช�วยเพ��มความสามารถด�านการให�บร�การตนเอง, การทำงานแบบอัตโนมัติ และการบร�หารจัดการ Life-Cycle ของ Application ได� แนวทางนี้ได�เป�ดโอกาสให�เหล�านักพัฒนาและทีมผู�ดูแลระบบทำการสร�างระบบในรูปแบบเดียวกันได�อย�างรวดเร็ว ช�วยให�นักพัฒนาสามารถมุ�งเน�นไปที่การพัฒนา Application ได�โดยไม�มีอ�ปสรรคและความล�าช�าใดๆ ที่เกิดข�้นจากระบบโครงสร�างพ�้นฐานที่จัดเตร�ยมเอาไว�

การจัดการอย�างเป�นมาตรฐานนั้นก็เป�นอีกส�วนสำคัญสำหรับการบร�การตนเองที่จะช�วยให�องค�กรสามารถทำงานได�อย�างเป�นอัตโนมัติและส�งมอบสิ�งต�างๆ ได�อย�างสม่ำเสมอตามวัตถุประสงค�เชิงธุรกิจ การปรับกระบวนการให�เป�นมาตรฐานนั้นเกี่ยวข�องกับการกำหนดลำดับของเหตุการณ�และกิจกรรมต�างๆ ที่จำเป�นต�อการทำงานใดๆ ให�สำเร็จลุล�วง ตัวอย�างเช�น การติดตั้งใช�งาน Application บนระบบใหม� เป�นต�น

นอกจากนี้ Container นั้นก็ยังสนับสนุนให� Application สามารถถูกโยกย�ายได� ทำให�สามารถสร�าง Application แบบ Cloud-Native ที่สามารถติดตั้งใช�งานได�บนผู�บร�การ Cloud ทุกราย ความสามารถในการโยกย�ายได�นี้ทำให�เกิดอิสระในการเลือกใช�ผู�ให�บร�การ Cloud รายใดก็ได�ในยามที่ต�องการ, สามารถย�ายระบบจากผู�ให�บร�การ Cloud รายหนึ่งไปยังอีกรายหนึ่งได�, สามารถเลือกปรับปรุงค�าใช�จ�ายให�คุ�มค�าสูงสุดได� และสามารถพัฒนาระบบ Application แบบ Multicloud ได�โดยไม�ต�องเปลี่ยนโค�ดตาม API เฉพาะของผู�ให�บร�การ Cloud แต�ละราย

เร�ยนรู�เพ��มเติมเกี่ยวกับแนวปฏิบัติและเทคนิคที่ช�วยสนับสนุน Cloud-Nativeไปสู� OPEN PRACTICE LIBRARY

-

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 11redhat.com

ขั้นตอนที่ 6: ทำระบบ IT ให�เป�นอัตโนมัติเพ�่อเร�งความเร็วให�กับการส�งมอบ APPLICATIONIT Automation หร�อ Infrastructure Automation นั้นคือระบบสำคัญที่จะเร�งให�การส�งมอบ Application แบบ Cloud-Na-tive เร็วข�้นด�วยการกำจัดงานทางด�าน IT ที่ต�องทำเองให�น�อยลงไป การทำงานแบบอัตโนมัตินี้สามารถผสานและประยุกต�ใช�กับงานหร�อส�วนประกอบใดๆ ก็ได� ตั้งแต�การจัดเตร�ยมระบบเคร�อข�ายและระบบโครงสร�างพ�้นฐานไปจนถึงการติดตั้งใช�งาน Application และบร�หารจัดการการตั้งค�าทั้งหมด

เคร�่องมือในการบร�หารจัดการและการทำงานแบบอัตโนมัติสำหรับระบบ IT จะสร�างกระบวนการ, กฎ และ Framework ที่สามารถเร�ยกใช�งานซ้ำได�ซึ่งจะสามารถทดแทนหร�อลดงานของผู�ที่เกี่ยวข�องซึ่งจะส�งผลกระทบต�อเวลาในการออกสู�ตลาดลง เคร�่องมือเหล�านี้สามารถครอบคลุมตั้งแต�การจัดการเทคโนโลยีเฉพาะอย�างอย�างเช�น Container หร�อว�ถีทางอย�างเช�น DevOps ไปจนถึงเทคโนโลยีที่กว�างข�้นอย�างเช�นระบบ Cloud, ระบบรักษาความมั่นคงปลอดภัย, การทดสอบ, การตรวจสอบ และการแจ�งเตือน ซึ่งผลลัพธ�ก็คือ การทำงานแบบอัตโนมัตินั้นก็ได�กลายเป�นหัวใจของการปรับปรุงระบบ IT และการทำ Digital Transformation ด�วยการเร�งความเร็วในการออกสู�ตลาดให�สูงข�้น

แนวทางสำหรับการทำ IT Automation1. ใช�แนวทางการทำงานแบบอัตโนมัติสำหรับงานทางด�าน IT ทั่วทั้งองค�กร มีการสื่อสารกันในวงกว�างเพ�่อออกแบบความต�องการของบร�การต�างๆ ให�ชัดเจน2. พ�จารณาการทำ Sandbox สำหรับระบบงานแบบอัตโนมัติเพ�่อเป�นพ�้นฐานสำหรับการเร�ยนรู�ภาษาและกระบวนการที่เกี่ยวข�องในการทำงานแบบอัตโนมัติ3. ไตร�ตรองเกี่ยวกับการทำงานแบบอัตโนมัติให�ถี่ถ�วน ต�องมั่นใจว�าขั้นตอนที่ต�องลงมือทำเองซึ่งไม�จำเป�นนั้นจะถูกกำจัดออกไป แม�ว�าจะรู�สึกอยากลงมือทำเองเพ�่อความสบายใจกว�าก็ตาม4. พ�จารณาให�เพ��มการทำงานแบบอัตโนมัติทีละนิด ทำทีละขั้นไปอย�างเป�นระบบ โดยแต�ละขั้นนั้นมีการพัฒนาต�อยอดมาจากระบบเดิมเพ�่อนำไปสู�การทำงานแบบอัตโนมัติเป�นวงกว�าง5. เร��มต�นโดยการทำงานหร�อบร�การเดียวให�เป�นอัตโนมัติก�อน ไม�ว�าจะเป�นงานด�าน Compute, Network, Storage หร�อการจัดเตร�ยมระบบก็ตาม จากนั้นจ�งแบ�งป�นการทำงานแบบอัตโนมัตินี้ให�กับผู�อื่นและต�อยอดอย�างเป�นระบบ6. สร�าง Self-Service Catalog เพ�่อให�ผู�ใช�งานสามารถจัดการเองได� และเพ��มความเร็วในการส�งมอบระบบให�สูงข�้น7. สร�างนโยบายและกระบวนการด�านการวัดการใช�งาน, ตรวจสอบการทำงาน และการประเมินค�าใช�จ�าย

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

เร�ยนรู�เพ��มเติมเกี่ยวกับบทบาทที่สำคัญของการทำ IT Automation ใน “The Automated Enterprise”DOWNLOAD E-BOOK

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 12redhat.com

ขั้นตอนที่ 7: ทำ CONTINUOUS DELIVERY และใช�เทคนิคการติดตั้งใช�งานระบบชั้นสูงการออก Software รุ�นใหม�โดยใช�เวลานานนั้นหมายถึงการมีความล�าช�าในการค�นหาและแก�ไขบั๊กภายใน Software อีกทั้งยังเป�นการทำให�ไม�สามารถตอบสนองความต�องการของลูกค�าหร�อตลาดได�ทันเวลาด�วย สำหรับ Application ที่มีการใช�งานเป�นปร�มาณมหาศาล เช�น Mobile, Web หร�อ IoT นั้น บั๊กที่ยังไม�ได�ถูกแก�ไขจะส�งผลกระทบต�อผู�ใช�งานจำนวนมาก รวมถึงสำหรับ Application ทางธุรกิจที่มีการใช�งานภายใน การที่ระบบไม�สามารถใช�งานได�หร�อมีความล�าช�าในการแก�ไขบั๊กนั้นก็อาจทำให�เกิดความเสียหายมูลค�าสูงได�

ว�ถีการพัฒนาแบบ Agile ได�พัฒนาข�้นมาเพ�่อสร�างโมเดลในการออก Software รุ�นใหม�ให�เร็วและถี่ข�้น แนวทางการทำ DevOps และ Continuous Delivery ก็ได�ต�อยอดจากว�ถีนี้ด�วยการทำให�ทีมของนักพัฒนา, ผู�ดูแลระบบ, ผู�รับประกันคุณภาพ และผู�รักษาความมั่นคงปลอดภัยทำงานกันอย�างใกล�ชิดมากข�้นเพ�่อปรับปรุงกระบวนการการส�งมอบ Software ซึ่งผลลัพธ�นั้นก็คือการที่การเปลี่ยนแปลงใดๆ ที่เกิดข�้นกับโค�ดสามารถถูกส�งไปยังระบบ Production ได�อย�างรวดเร็วและสเถียร อีกทั้งยังทำให�นักพัฒนาได�รับฟ�งความคิดเห็นเร็วข�้นด�วย การทำงานแบบนี้ซึ่งมีการให�ความเห็นอย�างรวดเร็วหลายๆ รอบตลอดช�วงการทำ CI/CD ก็จะทำให�การทำ Infrastructure Automation นั้นครอบคลุมแบบครบวงจร ทำให�ระบบส�งมอบแบบอัตโนมัติครอบคลุมทุกแง�มุมของการส�งมอบ Application โดยเป�าหมายของการสร�างระบบส�งมอบแบบอัตโนมัตินี้ก็คือการอัปเดตระบบได�โดยไม�ส�งผลกระทบต�อความสามารถในการดูแลรักษาระบบ และลดความเสี่ยงในการส�งมอบ Software ให�น�อยลง

ขั้นตอนแรกสู�ความสำเร็จในการทำ Continuous Delivery (CD) ก็คือการสร�างระบบ Continuous Integration (CI) ข�้นมาให�สำเร็จ โดยระบบ CI นั้นก็คือระบบสำหรับการ Build ที่มีการตรวจสอบหาความเปลี่ยนแปลงที่เกิดข�้นใน Repository ของระบบ Source Control, มีการทดสอบระบบในตัว และทำการ Build ระบบ Software รุ�นล�าสุดข�้นมาโดยอัตมัติจากความเปลี่ยนแปลงในแต�ละระบบ Source Control อย�างเช�น Jenkins

เร�ยนรู�ว�าเทคโนโลยีระบบ Automation สมัยใหม�อย�างเช�น Red Hat Ansible Automation จะช�วยสนับสนุน CI/CD ได�อย�างไร DOWNLOAD WHITEPAPER

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

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

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

Rolling Deployment คือว�ธีการอัปเดตระบบ โดยแทนที่จะทำการอัปเดตทุกๆ Instance ของ Application เดียวกันพร�อมๆ กัน แนวทางนี้จะทำการอัปเดตทีละ Instance และให� Load Balancer ทำการกันระบบที่กำลังอัปเดตแยกออกไปเพ�่อไม�ให�มี Traffic ใดๆ ถูกส�งมายังระบบนี้ จนกระทั่งเมื่ออัปเดต Instance นั้นเสร็จแล�วจ�งค�อยนำกลับเข�ามารวมภายใต� Load Balancer ซึ่งกระบวนการนี้จะเกิดข�้นซ้ำๆ อย�างต�อเนื่องจนกว�าทุกๆ Instance จะถูกอัปเดตทั้งหมด

Continuous Delivery (CD) คือแนวทางทางด�านว�ศวกรรม

Software ซ่ึงทีมจะสร�าง Software ท่ีมีคุณค�าข�้นมาใน

ช�วงเวลาอันสั้น โดยที่ยังคงมั่นใจว�า Software น้ันจะ

สามารถถูกใช�งานได�อย�างสเถียรอยู�เสมอ โดยการเป�ดให�ใช�

Software ได�อย�างสเถียรและมีความเสี่ยงต่ำ CD ก็ทำให�การ

ปรับเปลี่ยน Software ไปตามความคิดเห็นของผู�ใช�งาน,

เปลี่ยนไปตามความต�องการของตลาด และเปลี่ยนไปตาม

กลยุทธ�ของธุรกิจได�อย�างต�อเนื่อง

นิยามจาก Gartner

BURR SUTTERDIRECTOR OF DEVELOPER

EXPERIENCE, RED HATREDHAT.COM/EN/ENGAGE/

TEACHING-AN-ELEPHANT-TO-DANCE

“เทคนิคการติดตั้งใช�งานระบบชั้นสูงนั้นได�นำความเป�นระเบียบและความชัดเจนมาสู�นวัตกรรม ว�ธี

การติดตั้งใช�งานที่ดีจะสร�างสภาพแวดล�อมที่เป�ดให�เกิด

การทดลอง, การให�ความคิดเห็น และการว�เคราะห�ได�อย�างแท�จร�ง

และการทดลองที่ดีข�้นก็จะนำไปสู�นวัตกรรมที่ดียิ�งข�้นตามไปด�วย”

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 13redhat.com

Blue/Green Deployment คือแนวทางในการเป�ดใช�งานระบบ 2 ระบบที่เหมือนๆ กันคู�กันไป โดยมีระบบหนึ่งทำงานเป�นระบบหลัก และอีกระบบเป�ดสำรองเอาไว� การเปลี่ยนแปลงใดๆ ที่จะส�งผลต�อระบบ Production จะถูกเปลี่ยนแปลงที่ระบบสำรองก�อน จากนั้น เมื่อการเปลี่ยนแปลงเกิดข�้นอย�างสมบูรณ�แล�ว Traffic ของระบบก็จะถูกส�งมายังระบบที่ถูกอัปเดตทั้งหมดแทน ว�ธีการนี้จะทำให�การย�อนระบบกลับมาสู�รุ�นก�อนหน�าสามารถทำได�อย�างง�ายดายด�วยการส�ง Traffic กลับไปยังระบบที่ยังไม�ได�ถูกอัปเดตเท�านั้น โดยประเด็นเร�่องการจัดการข�อมูลที่เปลี่ยนแปลงก็เป�นสิ�งที่ต�องพ�จารณาให�ดี

Canary Deployment คือระบบที่คล�ายคลึงกับ Blue/Green Deployment ในแง�ที่มีการใช�ระบบ 2 ระบบที่เหมือนกัน อย�างไรก็ดี จ�ดที่แตกต�างก็คือว�ธีการจัดการกับการอัปเดตระบบใหม� โดยหลังจากที่มีการติดตั้งใช�งาน Software รุ�นใหม�แล�ว จะมีผู�ใช�งานเพ�ยงกลุ�มน�อยเท�านั้นที่ถูกส�งไปทดลองใช�งานระบบใหม�ใน Production ซึ่งถ�าหากพบว�าระบบใหม�สามารถทำงานได�อย�างถูกต�องสมบูรณ� Traffic ทั้งหมดก็จะค�อยๆ ถูกส�งไปยังระบบใหม�เพ��มมากข�้นเร�่อยๆ ในขณะที่มีการเฝ�าระวังและตรวจสอบอย�างต�อเนื่องจนกว�าผู�ใช�งานทุกคนจะถูกส�งไปยังระบบใหม�ทั้งหมด

DOWNLOAD E-BOOK Teaching an Elephant to Dance

ขั้นตอนที่ 8: พัฒนาสถาป�ตยกรรมระบบให�เป�น Modular มากยิ�งข�้นไปอีกในการใช�สถาป�ตยกรรมแบบ Microservices-based เพ�่อพัฒนา Software นั้น Application จะถูกแยกย�อยออกเป�นส�วนประกอบที่เล็กที่สุดเท�าที่จะเป�นไปได� และทำงานโดยไม�ข�้นต�อกัน แทนที่จะดำเนินตามแนวทางแบบเดิมๆ อย�าง Monolithic ซึ่งทุกๆ อย�างถูกพัฒนาข�้นมาเป�นชิ�นส�วนเดียวกันนั้น Microservices คือระบบย�อยจำนวนมากที่ทำงานร�วมกันเพ�่อบรรลุเป�าหมายแบบเดียวกัน แนวทางการพัฒนาแบบนี้จะให�คุณค�ากับการแบ�งส�วนระบบให�เป�นระบบย�อย, ทำระบบให�เล็กที่สุด และใช�กระบวนการที่คล�ายคลึงกันระหว�าง Application ที่หลากหลาย ถึงแม�ว�าสถาป�ตยกรรมแบบ Microservices จะไม�ได�ระบุเจาะจงถึงระบบโครงสร�างพ�้นฐานเบื้องหลัง แต� Container นั้นก็นับเป�นระบบที่เหมาะสมตอบโจทย�ได�ดีที่สุดสำหรับสถาป�ตยกรรมนี้

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

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

อีกทางเลือกหนึ่งในการก�าวสู�สถาป�ตยกรรมแบบ Microservices ก็คือ Miniservices โดย Miniservice หนึ่งๆ นั้นก็คือกลุ�มของบร�การที่ถูกแบ�งตามขอบเขตและมักจะทำงานอยู�บน Application Server ซึ่ง Miniservices นั้นก็จะสามารถช�วยเพ��มความคล�องตัวและสามารถเพ��มขยายระบบได�โดยไม�มีความซับซ�อนในระดับเดียวกับการออกแบบและโครงสร�างระบบพ�้นฐานแบบ Microservices ทั้งนี้ Microservices ก็ยังคงต�องการการลงทุนทางด�านการทำ Agile, DevOps และ CI/CD เพ�่อให�ระบบ Application Server สมัยใหม�หร�อระบบที่มีการใช�งาน Framework หลากหลาย, สถาป�ตยกรรมหลากหลาย และภาษาหลากหลายสามารถทำงานร�วมกันในระบบเดียวภายในระบบโครงสร�างพ�้นฐานที่ใช� Container เป�นหลักได�เป�นอย�างดี

ระบบ Platform ที่สามารถสนับสนุน Framework, ภาษา และแนวทางที่แตกต�างกันให�ก�าวไปสู�การพัฒนา Application แบบ Cloud-Native ได�อย�างเช�น Microservices, Miniservices หร�อ MonolithFirst นั้น นับเป�นกุญแจสำคัญไปสู�ความสำเร็จของเหล�า Application แบบ Cloud-Native

-

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 14redhat.com

6. ผลลัพธ�เชิงธุรกิจสำหรับ APPLICATION แบบ CLOUD-NATIVEแต�ละธุรกิจนั้นก็จะมีลำดับความสำคัญในการทำ Digital Transformation ที่แตกต�างกันออกไป บางธุรกิจก็อาจมุ�งเน�นไปที่การปรับปรุงสถาป�ตยกรรมของ Application และระบบโครงสร�างพ�้นฐานให�ทันสมัยข�้นเพ�่อให�สามารถก�าวไปสู�หลักการของระบบแบบ Cloud-Native ได� ในขณะที่บางธุรกิจนั้นก็อาจมุ�งเน�นไปที่การสร�างนวัตกรรมใหม�ๆ ด�วยรูปแบบการดำเนินธุรกิจและระบบ Application แบบใหม� ไม�ว�าวัตถุประสงค�และผลลัพธ�เชิงธุรกิจจะเป�นอย�างไร ธุรกิจเหล�านี้ก็ยังคงมีวัตถุประสงค�ร�วมในประเด็นเร�องการเพ��มความเร็ว, เพ��มความยืดหยุ�น และการเตร�ยมความพร�อมเชิง Digital โดยกรณีการใช�งานที่คล�ายคลึงกันสำหรับ Application แบบ Cloud-Native เหล�านี้ก็สามารถถูกจัดหมวดหมู�โดยสังเขปภายใต�ความท�าทายเชิงธุรกิจได�ดังนี้:

“ในวันแรกที่เราเข�าซื้อกิจการของธนาคารแห�งใหม�มา ก็เกิดการ

เปลี่ยนแปลงระบบ 10 ส�วนภายในระบบ Production โดย

ไม�มีข�อผิดพลาดใดๆ เกิดข�้นเลย”

JOHN RZESZOTARSKIDIRECTOR OF DEVOPS, KEYBANK

ลดเวลาในการติดตั้งใช�งานลง:จาก 12 สัปดาห�เหลือเพ�ยง 1 สัปดาห�

ความท�าทายประการที่ #1: เพ��มความเร็วในการส�งมอบ APPLICATIONวัตถุประสงค�:เพ��มความเร็วในการส�งมอบ Application ที่มีอยู�เดิมและสำหรับ Application ใหม�สู�ลูกค�า

แนวทาง:Container นั้นทำให�มี Platform กลางที่รวมเอาทีมพัฒนา, ทีมดูแลรักษา, ทีมรักษาความมั่นคงปลอดภัย, ทีมทดสอบคุณภาพ และทีมอื่นๆ สำหรับทำ DevOps ได�ไม�ว�าจะใช�เทคโนโลยีระบบโครงสร�างพ�้นฐานหร�อ Application ใดๆ ก็ตาม ด�วยแนวทาง DevOps แต�ละทีมนั้นก็จะได�ใช� CI/CD และการทำ Automation เพ�่อส�งมอบ Software รุ�นล�าสุดได�อย�างรวดเร็วและมั่นใจ ด�วยการแก�ไขป�ญหาในการติดตั้งใช�งานโดยการทำ Automation ในระดับของ Container วงจรการส�งมอบ Application นั้นก็จะมีความรวดเร็วยิ�งข�้นและตอบรับต�อการเปลี่ยนแปลงที่รวดเร็วของธุรกิจได�ดียิ�งข�้น แทนที่จะทำให�ธุรกิจต�องชะลอลงตามความล�าช�าของระบบ IT

เร�่องราวของลูกค�า:KeyBank หนึ่งในธนาคาร 15 อันดับแรกของสหรัฐอเมร�กา ได�ร�เร��มโครงการปรับปรุง Digital Channel ให�มีความทันสมัยเพ�่ออัปเดตประสบการณ�การใช�งานเว็บไซต�และสร�างระบบเว็บสำหรับอ�ปกรณ� Mobile ข�้นใหม� ด�วยการใช� Red Hat OpenShift ในการสนับสนุนการย�ายระบบจาก Application แบบ Monolithic ไปสู� Microservices ก็ทำให� KeyBank สามารถทำ Continuous Delivery แบบอัตโนมัติและลดเวลาจากที่เคยต�องใช�ในการติดตั้งใช�งานระบบใหม�นานถึงไตรมาสเหลือเพ�ยงแค�รายสัปดาห�เท�านั้น

-

ความท�าทายประการที่ #2: ปรับปรุง APPLICATION ที่มีอยู�เดิมให�ทันสมัยยิ�งข�้นวัตถุประสงค�:เพ��มความเร็วในการเปลี่ยนแปลงด�วยการปรับปรุง Application ที่มีอยู�เดิมให�ทันสมัยยิ�งข�้น ปรับตัวเข�าหาตลาดและลูกค�า

แนวทาง:Application ที่มีคุณค�าทางธุรกิจหลากหลายระบบนั้นมักเป�นระบบ Application แบบเก�าที่ไม�ได�ถูกออกแบบมาเพ�่อรองรับต�อยุคสมัยแห�ง Digital อย�างไรก็ดี แนวทางการร�้อระบบใหม�อย�างทันทีนั้นก็ไม�ได�คุ�มค�าหร�อส�งผลดีทางด�านการเง�นเสมอไป นอกจากนี้แล�ว บาง Application เองนั้นก็ไม�สามารถทำการปรับปรุงให�ทันสมัยได�

ถ�าหากประเมินแล�วว�าการการย�ายระบบ Application แบบเดิมมาสู� Cloud นั้นเป�นไปได�และคุ�มค�า แนวทางนี้ก็สามารถถูกสนับสนุนได�โดย Container ซึ่งจะสามารถลดความเกี่ยวพันอันซับซ�อนที่เคยเกิดภายในระบบโครงสร�างพ�้นฐานลงไปได� และส�งผลให� Application ต�างๆ นั้นสามารถย�ายจากระบบโครงสร�างพ�้นฐานแบบ On-Premises ไปสู� Cloud ซึ่งหากจำเป�นก็อาจสามารถทำการเข�ยนโค�ดใหม�หร�อปรับสถาป�ตยกรรมใหม�ให�กลายเป�นแบบ Cloud-Native ได�ด�วย แนวทางการใช�ระบบ Container นี้ยังอาจทำให�ได�รับประโยชน�จากความสามารถในการทำงานแบบอัตโนมัติและการทำ DevOps เพ�่อให�การย�ายระบบ Application แบบเดิมง�ายข�้นได�ด�วย

เร�่องราวของลูกค�า:ในฐานะของตลาดการเง�นรายใหญ�ที่เป�ดแห�งแรกในแต�ละวัน Australian Securities Exchange (ASX) นั้นมีบทบาทเป�นอย�างมากในวงการการเง�นทั่วโลก ส�งผลให�ต�องมีการดำเนินการใดๆ อย�างมั่นคง, ปลอดภัย และมีประสิทธิภาพ แต�ด�วยระบบ Application Server แบบเดิมๆ ที่มีอยู�ก็เร��มที่จะทำงานได�อย�างไม�สเถียร และมีค�าใช�จ�ายในการดูแลรักษาที่สูง ASX จ�งได�ร�เร��มโครงการที่จะปรับปรุงระบบ Digital Platform ของตนเองให�มีความทันสมัยด�วยเทคโนโลยีสมัยใหม�และตัดสินใจที่จะเลือกใช� Red Hat JBoss Enterprise Application Platform เพ�่อเป�นพ�้นฐานอันแข็งแรงรองรับ Application Server ในอนาคต การติดตั้งใช�งานในช�วงแรกเร��มนั้นได�เร��มต�นจากระบบ ASX Online ซึ่งเป�นระบบ Business-to-Business (B2B) Web Application ที่มีความสำคัญสูงมาก ด�วยบทบาทในการให�ข�อมูลด�านราคา, การประกาศข�าวสารจากบร�ษัทต�างๆ และการนำเสนอรายงานสำคัญสู�ตลาดในขณะที่ยังต�องตอบโจทย�ด�านข�อบังคับทางกฎหมายไปพร�อมๆ กันด�วย

ความท�าทายประการที่ #3: การพัฒนา APPLICATION แบบ CLOUD-NATIVE ระบบใหม�ข�้นมาวัตถุประสงค�:เพ��มความเร็วในการพัฒนา Application ใหม�ๆ เพ�่อตอบรับต�อโอกาสใหม�ๆ ทางธุรกิจ

แนวทาง:ความเปลี่ยนแปลงที่เกิดข�้นในธุรกิจและความต�องการของลูกค�านั้นได�นำมาซึ่งโอกาสใหม�ๆ สำหรับองค�กรที่สามารถเปลี่ยนไอเดียต�างๆ ให�กลายเป�นบร�การและผลิตภัณฑ�ได�อย�างรวดเร็ว, ประเมินความคุ�มค�าของตลาดใหม�ได�อย�างรวดเร็ว และปรับตัวได�รวดรเว แนวทางแบบ Cloud-Native เพ�่อสร�าง Application ใหม�ข�้นมานี้เป�นขั้นตอนที่จะเร�งให�เกิดการสร�าง Application ซึ่งมีนวัตกรรมใหม�ๆ ข�้นมาจากไอเดียต�างๆ ได�ด�วยการสนับสนุนจากสถาป�ตยกรรมแบบ Service-based, การผสานระบบผ�านทาง API, บร�การที่ถูกนำเสนอผ�านระบบ Container และการจัดการแบบอัตโนมัติ ไปจนถึงแนวปฏิบัติ, การทำงานแบบอัตโนมัติ และเคร�่องมือของ DevOps

“จากการที่มีผู�เชี่ยวชาญคอยสนับสนุนการใช�งานระบบ

Red Hat JBoss EnterpriseApplication เราก็ไม�ต�องกังวล

เกี่ยวกับการดำเนินงานในแต�ละวันอีกเลย”

FORMER GENERAL MANAGERCORPORATE TECHNOLOGY,

AUSTRALIAN SECURITIES EXCHANGE

ทำการ Restart ระบบ Applicationได�เร็วกว�าเดิม 60 เท�า

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 15redhat.com

ลดเวลาและค�าใช�จ�ายในการสนับสนุนระบบลงมีทรัพยากรมากข�้นในการพัฒนา

บร�การอย�างมีนวัตกรรมได�

ภายในป� 2023 90% ของ Application จะยังคงถูกใช�งาน

ต�อไป แต�ส�วนใหญ�จะขาดงบประมาณในการปรับปรุงระบบ

ให�ทันสมัยข�้น

Gartner: Application Modernization should be business-centric,

continuous, and multiplatform,January 2018

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 16redhat.com

เร�่องราวของลูกค�า:Schiphol International Airport เป�นสนามบินที่คึกคักมากที่สุดเป�นอันดับที่ 3 ของยุโรปด�วยผู�โดยสารจำนวนมากถึง 64 ล�านคนต�อป� เป�าหมายของ Schiphol นั้นก็คือการมุ�งเป�นสนามบินแบบ Digital ที่ดีที่สุดในโลกให�ได�ภายในป� 2018 เพ�่อให�สามารถบรรลุถึงเป�าหมายดังกล�าว สนามบินแห�งนี้ก็ต�องเร�งการพัฒนา Application ด�วยระบบ Cloud เป�นหลัก ประเด็นสำคัญประการหนึ่งในกลยุทธ�ทางด�าน Digital ของ Schiphol นี้ก็คือการให�บร�การผ�านทาง API ซึ่งรวมถึงบร�การ Flight API ที่จะทำให�ลูกค�าได�รับข�อมูลต�างๆ อย�างเช�น Gate, Terminal และเวลา Check-in ด�วยการใช� Red Hat OpenShift Container Platform นั้น Schiphol ก็ ได�สร�างระบบ Platform ที่รองรับการทำ Self-Service และตอบโจทย� Multi-Cloud สำหรับทีมงานแผนก IT ภายในองค�กรและคู�ค�าทางธุรกิจ เพ�่อช�วยลดเวลาในการสร�างบร�การใหม�ๆ มานำเสนอแก�ลูกค�าและผู�โดยสารทุกราย

ความท�าทายประการที่ #4: ขับเคลื่อนวัตกรรมทางธุรกิจวัตถุประสงค�:เพ��มความเร็วในการสร�างนวัตกรรมใหม�ๆ ทั่วทั้งองค�กรเพ�่อให�ทันต�อความต�องการทางธุรกิจ

แนวทาง:ในโลกที่กำลังหมุนไปอย�างรวดเร็วนี้ การอยู�กับที่นั้นก็คือการถูกทิ�งไว�เบื้องหลัง แผนก IT นั้นต�องแข�งขันสร�างความสามารถและบร�การใหม�ๆ เพ�่อสร�างความพ�งพอใจให�แก�ลูกค�าและช�วยให�พนักงานภายในทำงานได�อย�างชาญฉลาดยิ�งข�้น ความสำเร็จนั้นข�้นอยู�กับการสร�างนวัตกรรมใหม�ๆ ได�อย�างสม่ำเสมอและต�องอาศัยมากกว�าเคร�่องมือหร�อเทคโนโลยีเท�านั้น เพราะการที่จะประสบความสำเร็จได�นั้นต�องอาศัยวัฒนธรรม, เคร�่องมือ และกระบวนการใหม�ๆ ที่มีมุมมองแบบใหม�เพ�่อสนับสนุนนวัตกรรมและการลองผิดลองถูกทั่วทั้งองค�กรให�ได�

เร�่องราวของลูกค�า:Heritage Bank เป�นธนาคารที่มีอายุยาวนานกว�า 142 ป� และเป�นหนึ่งในสถาบันการเง�นที่เก�าแก�ที่สุดของออสเตรเลีย การเผชิญหน�ากับการแข�งขันในตลาดและการเข�าสู�ตลาดใหม�ๆ นั้นเป�นสิ�งที่จำเป�น ซึ่ง Heritage Bank ก็ต�องมองหาว�ธีการใหม�ๆ ที่จะทำให�สามารถส�งมอบ Software ได�รวดเร็วยิ�งข�้น ด�วยการร�วมงานกับทีมงานภายใน Red Hat Open Innova-tion Labs ทาง Heritage Bank ก็สามารถสร�างโซลูชันนวัตกรรมสำหรับธนาคารข�้นมาได�ด�วยความสามารถของทีมงานที่มีประสิทธิภาพสูง ซึ่งเป�นทีมที่จะเป�นกำลังสำคัญในการพัฒนา Software ให�ดียิ�งข�้นและพัฒนาได�อย�างรวดเร็วยิ�งข�้นไปอย�างต�อเนื่องในอนาคต

ว�ดีโอของ Heritage Bank

“Red Hat OpenShift Container Platform ได�ใจผม

ไปเต็มๆ มันมีนวัตกรรมล้ำสมัยและช�วยให�เราสามารถติดตั้ง

ใช�งานระบบได�รวดเร็ว และควบคุม Container ของเราได�

อย�างง�ายดาย”

MICHAEL AALBERSSENIOR TECHNICAL

APPLICATION COORDINATOR,AMSTERDAM AIRPORT SCIPHOL

พัฒนา API ใหม�ได�เร็วกว�าเดิม 50%

“สิ�งทีน�าตื่นเต�นที่สุดในงานนี้ก็คือการที่เราจะเปลี่ยนแปลงว�ธีการทำงานของ IT ทั้งหมด

เราจะเปลี่ยนว�ธีการทำงานของเราทั้งหมดที่เราทำในฐานะ

ธุรกิจ และเราก็จะเร��มต�นกระบวนการเปลี่ยนแปลงว�ธีการ

ที่ธนาคาร�ทำงานทั้งหมด”

WAYNE MARCHANTCHIEF INFORMATION OFFICER,

HERITAGE BANK

Figure 2. The cloud-native journey with Red Hat

DIGITAL EVOLUTION DIGITAL REVOLUTION

CLOUD NATIVE USE CASES

RED HAT PRODUCTS AND SERVICES

Accelerateapp delivery

Modernizeexisting apps

Develop newcloud native apps

Drive businessinnovation

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications 17redhat.com

Red Hat จะช�วยคุณได�อย�างไรไม�ว�าคุณจะอยู�ในสถานะใดของการก�าวสู� Digital หร�อ Cloud-Native และมีลำดับความสำคัญในการทำงานอย�างไรก็ตาม Red Hat ก็มีเทคโนโลยีและบร�การที่จะสามารถช�วยสนับสนุนคุณได�ดังนี้

บางองค�กรนั้นอาจมุ�งเน�นไปที่รูปแบบการใช�งาน Cloud-Native เพ�ยงแค�กรณีเดียวเท�านั้น ในขณะที่องค�กรอื่นก็อาจให�ความสำคัญกับกรณีการใช�งานหลากหลายรูปแบบไปพร�อมๆ กัน ไม�ว�าคุณจะเลือกแนวทางที่จะว�วัฒนาการหร�อปฏิวัติระบบทั้งหมดก็ตาม เส�นทางของคุณนั้นก็จะแตกต�างกับธุรกิจรายอื่นๆ และอาจไม�ได�เป�นเส�นตรงเสมอไป ซึ่งไม�ว�าเส�นทางของคุณนั้นจะเป�นอย�างไร การส�งมอบ Application ออกสู�ตลาดให�ได�อย�างรวดเร็วนั้นก็ต�องอาศัยเทคโนโลยี, แนวทางแบบ DevOps และวัฒนธรรมที่ถูกต�องและเหมาะสม

Red Hat ช�วยสนับสนุนการเดินทางนี้ได�ด�วย Red Hat OpenShift ระบบ Platform สำหรับการพัฒนาบน Container แบบ Cloud-Native โดยภายใน Red Hat OpenShift Application Runtimes นี้จะประกอบไปด�วย Runtime และ Framework แบบ Open Source เพ�่อใช�สร�าง Application แบบ Cloud-Native ทำให�สามารถลดเวลาในการพัฒนาลงได�ด�วยการใช� Runtime บน Container ภายใน OpenShift อีกทั้งเทคโนโลยีของ Red Hat JBoss Middleware จำนวนมากเองนั้นก็สามารถใช�งานบน OpenShift ได� รวมถึงเทคโนโลยีการบร�หารจัดการและการทำงานอัตโนมัติจาก Ansible ด�วย

เพ�่อช�วยให�การจัดการกับความซับซ�อนที่เกิดข�้นในระหว�างการทำ Digital Transformation ทาง Red Hat Consulting เองก็พร�อมจะนำเสนอการให�คำปร�กษาเชิงกลยุทธ�และความเชี่ยวชาญทางเทคนิค จากทั้ง Red Hat Open Innovation Labs ไปจนถึง Discovery Sessions และการวางแผนดำเนินโครงการ ทีมงานให�คำปร�กษาของเราสามารถช�วยคุณได�ในทุกๆ ขั้นตอนการเดินทางสู� Cloud-Native ของคุณ

Copyright © 2018 Red Hat, Inc. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, OpenShift, Ansible, and JBoss are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

facebook.com/redhatinc @redhat

linkedin.com/company/red-hat

NORTH AMERICA 1 888 REDHAT1

EUROPE, MIDDLE EAST, AND AFRICA 00800 7334 2835 europe@redhat.com

ASIA PACIFIC +65 6490 4200apac@redhat.com

LATIN AMERICA +54 11 4329 7300info-latam@redhat.com

redhat.com #F12255_0518

E-BOOK แนวทางสู�การรองรับระบบ Cloud-Native Applications

คุณกำลังมุ�งหน�าสู� CLOUD-NATIVE อยู�หร�อไม�?เร�ยนรู�เพ��มเติมว�า Red Hat จะสามารถช�วยเหลือคุณในการมุ�งหน�าสู�การพัฒนา Application แบบ Cloud-Native ได�อย�างไร:

ค�นหาว�า Red Hat Consulting จะช�วยได�อย�างไรบ�าง: รู�จักกับแนวปฏิบัติที่ดีที่สุดและแนวทางการวางแผนใน Discovery Sessionเยี่ยมชม Services Speak Blog ของเราเพ�่อเร�ยนรู�ข�อมูลใหม�ๆ, คำแนะนำ และอื่นๆความพร�อมทางด�าน DevOps ของคุณอยู�ในระดับใด? คุณพร�อมแค�ไหนสำหรับการเดินทางสู� Cloud-Native? ทำแบบ ประเมิน Ready to Innovate เพ�่อหาคำตอบได�ทันที

เกี่ยวกับ RED HATRed Hat เป�นผู�นำเสนอโซลูชันทางด�าน Open Source Software ที่ใหญ�ที่สุดในโลก ด�วยแนวทางการสนับสนุนชุมชนต�างๆ เพ�่อพัฒนาเทคโนโลยี Cloud, Linux, Middleware, Storage และ Virtualization ซึ่งมีประสิทธิภาพสูงและมีความทนทาน นอกจากนี้ Red Hat ยังมีบร�การหลังการขาย, การฝ�กอบรม และการให�คำปร�กษาซึ่งได�รับรางวัลมามากมาย ในฐานะของผู�ที่ทำหน�าที่เป�นสะพานเชื่อมระหว�างองค�กร, พันธมิตรทางการค�า และชุมชน Open Source นั้น Red Hat ก็ ได�ช�วยสร�างเทคโนโลยีผสานนวัตกรรมซึ่งมีคุณค�าเพ�่อให�ธุรกิจสามารถเติบโตและช�วยให�ลูกค�ารายต�างๆ พร�อมที่จะเป�ดรับสู�อนาคตของโลก IT ได�