Cloud HM

MENU

AWS Lambda: การเพิ่มประสิทธิภาพแบบไม่มี Server ในโลกธุรกิจ

AWS Lambda: การเพิ่มประสิทธิภาพแบบไม่มี Server ในโลกธุรกิจ

Cloud HM - MKTCloud Variety, ,

ภาพโลโก้ของ AWS Lambda

ทักทายผู้อ่าน

สวัสดีครับผู้อ่านทุกๆท่าน ในบทความนี้ผมจะพาผู้อ่านทุกท่านไปทำความรู้จักกับ AWS Lambda ที่ทำงานในรูปแบบของ “Serverless Computing” ซึ่งแน่นอนว่าบางท่านอาจจะเคยได้ยินมาบ้างแล้ว แต่บางท่านอาจจะสงสัยว่ามันคืออะไร ซึ่งวันนี้เราจะมาแนะนำเจ้า AWS Lambda ว่าทำงานอย่างไรและรองรับการทำงานรูปแบบไหน และที่สำคัญจะช่วยให้เราสามารถพัฒนาธุรกิจของเราได้อย่างไรบ้าง?

ก่อนอื่นเรามาทำความรู้จักเจ้า AWS Lambda ให้มากขึ้นกันก่อน ‘AWS Lambda’ หรือเรียกสั้น ๆ ว่า Lambda ถูกพัฒนาออกมาและส่งต่อให้ถึงผู้ใช้งานในคอนเซ็ปต์ ของคำว่า Serverless นั่นคือการที่ผู้ใช้งานสามารถเรียกใช้ Lambda โดยที่ไม่ต้องคำนึงถึง Server โดยเราสามารถสร้างกระบวนการทำงานต่าง ๆ โดยไม่ต้องจัดการกับ Server เลย ซึ่งในที่นี้คือ เราไม่ต้องมาคอยดูแลบริการจัดการ ทำให้เราสามารถโฟกัสกับการเขียนโค้ดหรือการแก้ปัญหาต่างๆทางธุรกิจได้มากขึ้น ซึ่งเจ้า AWS Lambda นั้นถูกเรียกและนิยามว่า ​​FaaS (Function as a Service)

AWS Lambda เป็นบริการที่จะคอยช่วยให้เราจัดการ ประมวลผลการทำงานของระบบว่าต้องการทรัพยากรส่วนไหนเพิ่มหรือไม่ ถ้าหากว่าต้องการ ตัว Lambda ก็จะทำการปรับขนาดระบบของเราให้อัตโนมัติ (Auto Scaling) นอกจากนี้การใช้งาน AWS Lambda นั้นก็ง่าย เพราะว่าจริง ๆ แล้วไม่ใช่ภาษาคอมพิวเตอร์อันใหม่ แต่เป็นเพียงแค่ Library ซึ่งจะมี Lambda Function ให้เราสามารถใช้งานได้เลย และเราสามารถเขียนโค้ดเพื่อปรับแก้ฟังก์ชัน Lambda ด้วยภาษาที่เราถนัดได้ง่าย ๆ ซึ่ง Lambda ก็รองรับหลายภาษา (ดูรายละเอียดเพิ่มเติมด้านล่าง) 

ถ้าหากว่าพร้อมแล้วก็ลุยกันเลย !

ข้อดีของการใช้ AWS Lambda

ตัวอย่างการเรียกใช้งาน AWS Lambda function ที่ใช้ในการปรับขนาดของรูปภาพเมื่อมีการอัพโหลดรูปภาพเข้าไปยัง S3 Bucket

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

โดย Serverless Platform ที่เด่นมาก ๆ นั้นก็คือ AWS Lambda ซึ่งถือได้ว่าเป็น Serverless ตัวแรกที่เปิดให้บริการมา โดยการจัดการกับ Serverless นั้นมีจุดเด่นคือ

  • 1. ประหยัดเวลาและค่าใช้จ่าย: ไม่ต้องเสียเวลาจัดการเซิร์ฟเวอร์เองซึ่งช่วยประหยัดเวลาของทีมได้ นอกจากนี้ยังช่วยเรื่องประหยัดค่าใช้จ่ายโดยจะคิดค่อใช้จ่ายเฉพาะเวลาที่ใช้งานจริง (Pay-as-you-go-model)
  • 2. ใช้งานง่าย: รองรับการเขียนโค้ดได้หลายภาษา จัดการและทำงานง่าย มีตัวอย่างโค้ดและเอกสารประกอบมากมายช่วยให้นักพัฒนาสามารถเรียนรู้และใช้งานได้อย่างรวดเร็ว
  • 3. มีประสิทธิภาพ: สามารถปรับขนาดได้อัตโนมัติ (Auto-scaling) โดยรองรับการทำงานแบบ Event-driven เหมาะกับงานที่ต้องการความรวดเร็ว
  • 4. เชื่อมต่อกับบริการอื่นๆ ของ AWS ได้ง่าย: เชื่อมต่อกับ S3, DynamoDB, API Gateway ช่วยให้นักพัฒนาสามารถใช้งานบริการต่างๆได้ง่าย โดยใช้งาน SDK ของ AWS ได้
  • 5. มีความปลอดภัย: รองรับการเข้ารหัสข้อมูล มีการตรวจสอบความปลอดภัยอย่างสม่ำเสมอ

Event-Driven Architecture การออกแบบสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์

ถ้าอธิบายให้เข้าใจง่าย ๆ อีกก็คือ AWS Lambda Function นั้นเป็น Serverless Technology ที่มีมานานแล้ว (เกิดขึ้นตั้งแต่ปี ค.ศ. 2014) โดยถือว่าเป็นรูปแบบการให้บริการแบบ FaaS (Function-as-a-Service) หรือการที่เราสร้าง Lambda 1 ตัวที่ขึ้นมาแบบชั่วคราวเพื่อมาใช้งาน โดยจะมีเพียง 1 ฟังก์ชัน (Function) หรือหนึ่งการทำงานเท่านั้นที่เราต้องการให้มันทำงาน (อาจจะคิดว่าเป็น Server 1 ตัวที่มีการเก็บแค่ 1 Function ก็ได้)

โดยการใช้งาน AWS Lambda นั้นสามารถเรียกใช้งานได้หลายแบบ โดยหนึ่งในการเรียกใช้งานนั้นแน่นอนว่าก็ต้องเรียกใช้งานเมื่อมี Event หรือเหตุการณ์ที่เราต้องใช้ฟังก์ชัน Lambda นั้น ๆ ดังนั้นจึงมีการออกแบบให้ AWS Lambda Function นั้นทำงานตาม Event เรียกเท่ ๆ ว่า Event-Driven Architecture (หรือ EDA) ก็คือต้องมี Event ไปกระตุ้นหรือ Trigger ตัวระบบของเราให้ไปเรียก AWS Lambda Function ขึ้นมาใช้งาน โดย Lambda ไม่สามารถทำงานได้ด้วยตัวเองได้ถ้าหากไม่มี Event ไป Trigger (แม้ว่ามันจะชื่อ Serverless แต่ว่าการทำงานเบื้องหลังนั้นก็มีการสร้าง Server เพื่อมารันโค้ดอยู่ดี)

สำหรับในปัจจุบันนี้ ตัว AWS Lambda Function รองรับการเขียนภาษาต่าง ๆ เช่น Python, Node.js, Java, Go, Ruby และ C# (.NET Core) และถ้าหากว่าใครใช้ PHP ถึงแม้ว่าภาษานี้จะยังไม่รองรับ แต่ก็สามารถทำ PHP Custom Runtime เองได้ นอกจากนี้ AWS Lambda ยังมี Runtime API ซึ่งเป็นเครื่องมือที่ช่วยให้เราสามารถใช้ภาษาคอมพิวเตอร์อื่น ๆ เพิ่มที่นอกเหนือจากที่ลิสต์มาตามด้านบนได้อีกด้วย

กรณีศึกษาของ Netflix องค์กรที่ประสบความสำเร็จด้วย AWS Lambda

แน่นอนว่าแพลตฟอร์มที่ให้บริการชมภาพยนตร์หรือซีรีย์ต่างประเทศอย่าง Netflix นั้นมีผู้เข้าใช้งานหรือบริการผ่านเว็บไซต์ในแต่ละวันนั้นเป็นจำนวนหลายล้าน Users และสิ่งที่ Netflix ต้องเจอนั้นก็คือจำนวน Requests จาก Users ในการดูภาพยนตร์อันมหาศาล แล้ว Netflix แก้ปัญหาในการ Scale หรือปรับขยายขนาดของ Infrastructure ได้อย่างไรโดยที่ทำให้เว็บไซต์ไม่เกิดปัญหาหรือว่าล่ม เราจะมาดูกรณีศึกษาของ Netflix ซึ่งใช้ AWS Lambda กันครับ

ตามที่เราทราบกันว่า AWS Lambda นั้นจริง ๆ แล้วหลัก ๆ ก็คือเป็นระบบ Serverless Computing ซึ่งมีการให้บริการฟังก์ชันที่เรียกว่า Lambda (Function as a Service หรือ FaaS) ซึ่งเป็นการให้บริการแบบ Serverless แบบหนึ่ง โดย Architecture ของการ Requests การเข้าไปดูมัลติมีเดียของ Netflix นั้นใช้บริการต่าง ๆ เหล่านี้

  1. Load balancers
  2. API Gateways
  3. AWS Lambda function

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

ภาพรวมสถาปัตยกรรมของ Netflix

เพื่อจัดการคำขอดูหนังของ Users เป็นอย่างรวดเร็ว (ได้รับการจัดการ) ทาง Netflix นั้นมีสถาปัตยกรรมที่ปรับขนาดได้ซึ่งถูกจัดการด้วย AWS Lambda

  • Load Balancers หรือ โหลดบาลานเซอร์: คำขอดูที่เข้ามา (Request) จะถูกแบ่งออกเป็นอินสแตนซ์ต่าง ๆ โดยไปดูว่า Instance แบ่งโหลดยังของบริการของ Netflix ผ่านทางโหลดบาลานเซอร์ เพิ่มประสิทธิภาพทรัพยากรให้สูงสุดและเพิ่มความน่าเชื่อถือ
  • API Gateways หรือ เกตเวย์ API: เกตเวย์ API ทำหน้าที่เป็นจุดเริ่มต้นสำหรับคำขอดูหนัง ( การจัดการการรับรองความถูกต้องต่าง ๆ (ดูหนังได้ถูกเรื่องตามที่เรา Request ไป) รวมถึงการกำหนดเส้นทางคำขอ และการจัดการการรับส่งข้อมูล ซึ่งทำให้เรามั่นใจได้ว่า Connection ระหว่าง Users กับ Netflix นั้นมีความปลอดภัยและมีประสิทธิภาพ 
  • AWS Lambda หรือ Service Lambda: แล้วก็มาถึงพระเอกของเรา Netflix ใช้ AWS Lambda เพื่อจัดการงานต่าง ๆ เช่น การตรวจสอบสิทธิ์การเข้าถึงตัวไฟล์หนัง: AWS Lambda จะตรวจสอบว่าผู้ใช้มีสิทธิ์ในการเข้าถึงไฟล์หนังหรือไม่ โดยใช้ข้อมูลการสมัครสมาชิกและสิทธิ์การเข้าถึงที่เก็บไว้ในระบบ, การดึงเนื้อหาของไฟล์เพื่อนำมาเปิด: AWS Lambda ดึงเนื้อหาของไฟล์หนังจาก Amazon S3 และส่งไปยังอุปกรณ์ของผู้ใช้, การให้คำแนะนำเฉพาะบุคคล: Lambda ทำงานร่วมกับระบบ Recommendation System ของ Netflix ซึ่งใช้ Machine Learning วิเคราะห์ประวัติการดูหนังของผู้ใช้ และแนะนำหนังที่ผู้ใช้น่าจะสนใจ รวมไปถึงการแปลงรหัสวิดีโอของไฟล์หนังโดย Lambda แปลงรหัสวิดีโอของไฟล์หนังให้เป็นรูปแบบที่เหมาะสมกับอุปกรณ์ของผู้ใช้
  • Event-Driven Architecture หรือ สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์: เราจะทำการ Trigger หรือทำให้ AWS Lambda นั้นเริ่มต้นการทำงานตาม Event ต่าง ๆ ที่เกิดขึ้น เช่น คำขอของผู้ใช้งานที่อยากจะดูหนังเรื่องนี้, การเปลี่ยนแปลงข้อมูล Meta, หรือเหตุการณ์ของระบบใน Event-driven Architecture ของ Netflix ทำให้สามารถรันโค้ดได้อย่างมีประสิทธิภาพและอัตโนมัติ ช่วยให้ประมวลผลคำขอดูหนังนั้นเป็นไปอย่างราบรื่น

จะเห็นได้ว่าเมื่อ Netflix นั้นนำ AWS Lambda เข้ามาใช้งาน ทำให้ระบบนั้นมีความยืดหยุ่นขึ้นมากเพราะว่าระบบที่ทาง Netflix นั้นจะปรับขนาดสอดคล้องไปตาม Requests ที่ถูกขอเข้ามาจาก Users ทำให้ไม่ต้องเตรียมระบบที่มีขนาดใหญ่เกิดไปช่วงหน้าไว้ ทำให้ลดต้นทุนหรือค่าใช้จ่ายได้เยอะมาก ๆ เพราะว่า AWS Lambda นั้นคิดค่าใช้จ่ายตามจริงที่ใช้งาน นั่นก็คือคิดเป็นต่อนาที 

มาเรียนรู้เทคนิคในการสร้าง AWS Lambda กัน

ในหัวข้อนี้ผู้อ่านจะได้เรียนรู้วิธีการสร้างฟังก์ชัน AWS Lambda กันครับ โดยหนึ่งในข้อดีของ AWS Lambda นั้นก็คือเราไม่จำเป็นต้องห่วงเรื่องของ Server หรือ Infrastructure Management เลย นั่นหมายความว่าทาง AWS นั้นจะจัดการปริมาณโหลดต่าง ๆ ให้เราเอง ซึ่งเราไม่ต้องจัดการเองก่อนการสร้าง Lambda Function โดยเราสามารถใช้ประโยชน์จาก Architecture นี้ได้ด้วยเทคนิคต่อไปนี้

Tip 1: ทำให้ Lambda Function เป็นการเชื่อมต่อผ่าน VPC

Lambda Functions นั้นจะทำการเรียกใช้งานจาก AWS-owned VPC ตลอดเวลา โดยปกติแล้ว ฟังก์ชันของเรานั้นจะมีความสามารถในการสร้าง Network Request ไปยัง Public Internet Address อยู่แล้ว โดย Address เหล่านี้นั้นรวมไปถึงการเชื่อมต่อไปยัง Public AWS APIs ด้วย ยกตัวอย่างเช่น ฟังก์ชันของเรานั้นสามารถที่จะมี Interaction กับ AWS DynamoDB API ได้ แล้วก็ยังสามารถเชื่อมต่อกับ Query สำหรับการบันทึกข้อมูลได้อีกด้วย แต่สิ่งนึงที่ควรทำก็คือเราควรที่จะอนุญาตหรือกำหนดให้ฟังก์ชันของเรานั้นเชื่อมต่อไปยัง VPC ได้ ก็ต่อเมื่อเราสั่งเท่านั้น โดยเฉพาะตอนที่เราอยากให้มันเชื่อมต่อไปยัง Private Subnet ที่อยู่ใน Network อื่น ๆ 

RDS instance: When to VPC enable a Lambda function

รูปภาพด้านบนคือการทำให้ Lambda Function นั้นเชื่อมต่อกับ VPC โดย network ทั้งหมดนั้นมาจากฟังก์ชันของเรา ถ้าหากว่าฟังก์ชันของเราต้องการที่จะมี interaction กับ Public resource เราจะต้องทำการเชื่อมต่อหรือวางเส้นทาง (Route) ผ่านตัว NAT gateway ภายใน Public subnet

Tip 2: ใช้งาน Code ไปยัง Lambda Layer (เช่น AWS SDK)

ถ้าหากว่าผู้อ่านอยากที่จะเรียกใช้งาน Code ที่มีอยู่แล้วซ้ำ ๆ มากกว่า 1 ฟังก์ชัน ก็สามารถลองสร้าง Layer ขึ้นมาเพื่อทำการ deploy ข้างในได้ ตัวอย่างที่ดีอันนึงก็คือ AWS SDK ซึ่ง AWS นั้นรวม AWS SDK สำหรับ NodeJS และ Python Functions เข้ามาด้วย อย่างไรก็ตาม เราควรทำการรวม SDK ของเราทั้งหมด แล้วก็ Fix เวอร์ชันของ SDK ที่เราทดสอบไว้แล้วให้เข้ากับ Function ของเรา เพื่อป้องกันข้อผิดพลาดกรณีที่เวอร์ชันของ SDK นั้นเปลี่ยนไป 

Tip 3: สังเกตขนาดของแพคเกจและ Dependencies ตลอดเรื่อย ๆ

ตัว Lambda นั้นปกติแล้วมักจะต้องการให้เราทำการรวม Package หรือ Dependencies ที่ต้องใช้ไว้ก่อน ยิ่งถ้าหากเรามี Deployment Package ที่ใหญ่ ก็จะทำให้ Lambda Function ของเรานั้นทำงานช้าตามไปด้วย ดังนั้นเราควรตรวจสอบหรือเฝ้าติดตามดูขนาดของ Package อย่างสม่ำเสมอ และทำการลบ Items ที่ไม่จำเป็นทิ้งไปเพื่อทำการลดขนาด เช่น Documentation หรือ Libraries ต่าง ๆ ที่ไม่ได้ใช้งาน ถ้าหากว่าผู้อ่านใช้ Java Functions กับ AWS SDK ก็สามารถใช้เพียงแค่ modules ที่ต้องการใช้งานจริง ๆ เท่านั้นก็พอแล้ว ไม่ต้องใช้ SDK ทั้งหมด 

โดยมีตัวอย่างโค้ดให้ดูด้านล่าง

ตัวอย่างที่ดีของการเตรียม Dependencies:

<dependency>

    <groupId>software.amazon.awssdk</groupId>

    <artifactId>dynamodb</artifactId>

    <version>2.6.0</version>

</dependency>

ตัวอย่างที่ไม่ดีของการเตรียม Dependencies:

<!– https://mvnrepository.com/artifact/software.amazon.awssdk/aws-sdk-java –>

<dependency>

    <groupId>software.amazon.awssdk</groupId>

    <artifactId>aws-sdk-java</artifactId>

    <version>2.6.0</version>

</dependency>

Tip 4: ติดตาม Concurrency และกำหนดการแจ้งเตือนกรณีฉุกเฉิน

สำหรับคนที่เคยใช้ Lambda มาก่อนแล้ว ก็คงรู้แล้วว่า Concurrency นั้นสามารถมีผลกระทบต่อการทำให้ระบบล่มได้ เนื่องจากว่า Lambda Functions นั้นสามารถทำการ Scale หรือปรับขยายหรือลดขนาดตัวเองได้อย่างรวดเร็วแบบเร็วมาก ๆ นั่นหมายความว่าเราควรจะต้องควบคุมให้ Lambda function นั้นทำงานอยู่ในคอนดิชั่นที่เหมาะสม ซึ่งควรมีการกำหนดการแจ้งเตือนในกรณีที่มีการเกิด Spike ของ Concurrency หรือเหตุการณ์ที่ Concurrency นั้นพุ่งสูงหรือโดดจนเกินไป เพื่อป้องกันไม่ให้ระบบล่ม 

ไอเดียอันหนึ่งที่สามารถนำไปใช้ได้ก็คือการ Deploy บริการที่ชื่อว่า CloudWatch Alarm ซึ่งเป็นตัวที่จะเข้ามาช่วยในการแจ้งเตือนทีมของเราเมื่อ Function ของเรานั้นมีการทำงานที่ผิดปกติ ขึ้นอยู่กับ Metric ที่เรากำหนดไว้ เช่น ConcurrentExecutions หรือ Invocations เกิดค่าที่เราตั้งไว้ นอกจากนี้เราสามารถใช้ AWS Budget ในการกำหนดหรือสอดส่องค่าใช้จ่ายที่เกิดขึ้นแบบรายวันได้อีกด้วย 

Tip 5: การใช้ Over-Provision Memory 

Lambda นั้นจะทำการจัดแบ่งระบบ Computer Resource ให้สอดคล้องกับปริมาณของหน่วยความจำหรือ Memory สำหรับใช้ในการ Allocate ตัว Function ของเรา นั่นหมายความว่าเราสามารถ Provision หน่วยความจำเพื่อใช้รันฟังก์ชันของเราให้เร็วมากขึ้นได้แล้วก็ลดค่าใช้จ่ายได้เยอะมาก ๆ ด้วย โดยเราควรทำการ Benchmark กรณีของเราตามเหตุการณ์ที่เราต้องการ เพื่อหาจุดคุ้มที่สุดที่จะให้เกิดจุด Breaking Point ที่เราให้ฟังก์ชันเราทำงานได้ดีที่สุดก่อนที่ระบบจะเกิดปัญหา เทียบกับการหากรณีที่ใช้งาน memory น้อยที่สุดแต่ว่าก็รันได้ช้าที่สุดเช่นกัน 

อย่างไรก็ตาม ผมแนะนำว่าเราไม่ควร Over-provision หน่วยความจำเยอะเกินไป แล้วก็ต้องทำความเข้าใจประสิทธิภาพของโค้ดของเราด้วยเพื่อที่ว่าเราจะได้กำหนดระยะเวลาที่จะใช้ในการรันฟังก์ชันได้อย่างเหมาะสม ไม่สั้นหรือนานเกินไป ซึ่ง Over-provisioning Function นั้นมักจะทำให้ Lambda Function นั้นรันนานกว่าปกติ ซึ่งจุดนี้ผู้อ่านอาจจะต้องระวังด้วย 

สรุปแนวคิดของ AWS Lambda

1. เขียนโค้ดแล้วก็ใช้งาน

นักพัฒนาไม่จำเป็นต้องจัดการ Infrastructure หรือ Networking พื้นฐานด้วยตัวเอง จะได้มีเวลาไปโฟกัสกับ Application Development แทน

2. ปรับขนาดได้ด้วยตัวเอง (Autoscaling)

รองรับคำขอ (Request support) แบบ On-the-fly หรือ Whenever needed หรือขึ้นกับตามจำนวนที่ใช้งานจริง มีการปรับลดจำนวนของฟังก์ชันได้อย่างอัตโนมัติ โดยทาง AWS จะทำการสร้าง Instance มาเพิ่มให้ตามจำนวน Request ที่เพิ่มขึ้น ทำให้ไม่ต้องกังวลเรื่อง Scalability ที่จะต้องรับ Traffic จำนวนมากในอนาคต

3. Event-based trigger

Scale up from zero: สร้าง Instance สำหรับรันโค้ดก็ต่อเมื่อมี request (event) เข้ามา

Scale down to zero: ทำลาย Instance เมื่อไม่มี request เข้ามาเป็นช่วงระยะเวลาหนึ่ง 

ทิ้งท้าย (Bottom Line)

อ่านมาจนถึงตรงนี้ถ้าหากผู้อ่านมีความสนใจในบริการของ AWS โดยเฉพาะถ้าอยากจะปรึกษาเกี่ยวกับการให้บริการ AWS การสร้างแอปพลิเคชั่นของบริษัทโดยใช้เทคโนโลยีหรือแนวคิดของการใช้ AWS Lambda สำหรับการทำ Serverless-based Application โดยเน้นไปที่ Event-Driven Architecture (EDA) นั้นสามารถติดต่อ Cloud HM เพื่อให้คำปรึกษาได้โดยตรงเลยครับ เพราะเรามีผู้เชี่ยวชาญที่สามารถให้คำแนะนำได้สอดคล้องกับรูปแบบของบริษัทและเรามีการให้บริการ Cloud Platform ครบวงจร ทั้ง Domestic Cloud และ Global Cloud เพื่อตอบสนองความต้องการรอบด้านของลูกค้าครับ

อ้างอิง

  1. AWS Lambda – Getting Started (amazon.com)
  2. Event-driven architectures – AWS Lambda (amazon.com)
  3. AWS Lambda – Wikipedia
  4. https://blogs.oracle.com/developers/post/functions-as-a-service-evolution-use-cases-and-getting-started
  5. https://www.linkedin.com/pulse/unleashing-power-serverless-computing-revolutionise-your/
  6. https://www.prolim.com/the-power-of-serverless-computing-exploring-aws-lambda/

เรียบเรียงบทความโดย รังสิมันต์ เกษแก้ว

— Cloud HM