Update 27 Sep 2019 – ทาง AWS ได้แก้ไขปัญหาเรื่อง Cold Start เนื่องจากใช้ VPC แล้ว ซึ่งมีผลกับ Region ดังนี้ US East (Ohio), EU (Frankfurt), and Asia Pacific (Tokyo) – ที่มา aws.amazon.com

…

ผมเชื่อว่าใครก็ตามที่ตัดสินใจทำ Serverless มักเจอปัญหาที่แก้ไม่ตกคือ เรื่อง Cold Start ซึ่งบล็อกนี้ผมขอแชร์ประสบการณ์ที่ได้แก้ปัญหาทั้งหมด 9 วิธี เผื่อจะเป็นประโยชน์กันนะครับ (ขออ้างอิงจากผู้ให้บริการ AWS Lambda และภาษาที่ใช้พัฒนา C# .NET Core)

ทำความเข้าใจ Cold Start คืออะไร

ขอเกริ่นถึงสั้นๆ ของการทำงาน Serverless คือ เมื่อมีการร้องขอ (Request) ไปที่ Instances (เข้าใจง่ายๆ คือ Server ตัวหนึ่ง) เพื่อให้มันทำงาน มันจะใช้เวลาช่วงหนึ่งเพื่อทำการ Initial Instances จากนั้นค่อยเรียกโค้ดที่เราเขียน ขึ้นมาทำงานตามคำสั่ง

เมื่อมีการเรียกซ้ำอีก มันก็จะทำต่อเนื่องได้ทันที ไม่ต้องเสียเวลา Initial Instances ใหม่ แต่เมื่อทำงานเสร็จและปล่อยไว้สักระยะหนึ่ง เจ้า Instances ตัวนั้นก็จะเข้าสู่โหมด Idle อีก (หรือบางคนเรียกว่า หลับ, sleep) ดังนั้นเมื่อมีการร้องขอ (Request) ใช้งานอีกครั้ง จะเกิดกระบวนการ Initial Instances แบบเดิม ก่อนที่จะทำงานโค้ดของเรา

การ Initial Server ในครั้งแรก หรือครั้งหลังจากโหมด Idle นี่เอง เราจะเรียกว่า Cold Start

และมากกว่านั้น ภาษาที่ต้องมีการ Compile จะมีขั้นตอน 1-3 นานกว่าภาษา Script หลายเท่า (ผมลองพ่น Hello World โดยใช้ Node ไม่ถึง 1 วินาที, เทียบกับ .Net Core ใช้เวลา 4-5 วินาที)

และมีคำถามบ่อยๆ ว่าจะเข้าสู่โหมด Idle ภายในกี่นาที คำตอบคือ ไม่มีใครสามารถตอบได้ชัดเจน บางแหล่งก็บอก 30-45 นาที บางแหล่งก็บอก 15 นาที แต่สำหรับผมที่เล่นเอง จะเจอแถวๆ 5 นาทีเป็นต้นไป เรียกได้ว่าลุกไปเข้าห้องน้ำแป๊บนึง พอกลับมา มันก็ช้าอีกแล้ว (ผมใช้ AWS Lambda ที่ ap-southeast-1)

อ่านพื้นฐานเรื่อง Serverless และ AWS Lambda ฉบับเต็มได้ที่

• มาทำความรู้จักกับ Serverless และ AWS Lambda ฉบับคนคิดจะใช้

9 วิธีเพื่อใช้ลดเวลา Cold Start

คราวนี้ Cold Start ได้เป็นเสี้ยนหนามของผมมาก สุดท้ายแล้ว ผมพบว่ามี 9 วิธี ที่จะลดเวลา Cold Start ได้ ผู้อ่านสามารถเลือกไปทำ หรือจะทำทั้งหมดเลยก็ได้ ลองดูกันว่ามีวิธีใดบ้าง

1. เพิ่ม Memory Allocated
2. Lean and Clean Code
3. ลด และ/หรือ เลือกใช้ Dependency ที่จำเป็นและเหมาะสม
4. Warm ตัว Server ของเราตลอดเวลา
5. Warm ตัว Server ของเราตามเวลาที่เหมาะสม
6. ใช้ Custom Runtimes และเลือกใช้ Runtimes ที่ทำงานได้เร็ว
7. ใช้ Custom Runtimes และทำเป็น Native App
8. หลีกเลี่ยงการใช้ VPC ถ้าไม่จำเป็น
9. เลือกภาษาเพื่อใช้ทำ Serverless ที่เหมาะสม

1. เพิ่ม Memory Allocated

วิธีง่ายที่สุดคือใช้เงินจอง Memory ให้กับ AWS Lambda Instances มากๆ (Memory Allocated) ซึ่งมันก็เห็นผลได้เร็วและชัดเจนซะด้วย

กรณีแบบนี้ผมคิดว่าเหมาะกับการคำนวณ (Compute) ที่ไม่ได้เกิดขึ้นบ่อย แต่ต้องทำงานได้ไว และไม่ต้องการแก้ไขให้ยุ่งยาก — หรือพูดสั้นๆ คือ ยอมจ่ายค่า Memory ที่แพงขึ้น แลกกับ Duration Time ที่ลดลง แต่นานๆที เรียกใช้

กรณีนี้ผมทดลองด้วย C# .NET Core 2.1 ดึงข้อมูลจาก MySQL จำนวน 3 รายการ

สังเกตได้ว่า ยิ่งเพิ่ม Memory Allocated มากเท่าไร ก็ยิ่งลดเวลา Cold Start ได้มากเป็นเท่าตัว

แต่วิธีการนี้อาจจะไม่ดี 100% กับทุกกรณี เช่น ทดสอบแสดงข้อความ “Hello World” ด้วยภาษา Javascript ตามรูปด้านล่าง

สังเกตว่า แม้เพิ่ม Memory Allocated ไปมากเท่าใด เวลาของ Cold Start ก็ไม่ต่างกันมากนัก และ Memory สูงที่สุด ก็ไม่ได้บ่งบอกว่าจะเร็วที่สุดด้วย ดังนั้นเราจึงควรหาวิธีอื่นเพื่อลด Cold Start แทน

ถ้าให้ผมแนะนำ กรณีเพิ่ม Memory Allocated นี้ เราไม่ควรจะคาดเดา ซึ่งผมเคยเขียนวิธีการทดสอบไว้แล้ว สามารถอ่านวิธีการได้ที่ จัดสรรทรัพยากร AWS Lambda อย่างไร ให้ราคาถูกและเร็วที่สุด

2. Lean and Clean Code

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

การเรียกใช้ Config จาก JSON File วิธีนี้จะทำให้เราต้องเรียกใช้ Package Dependency จัดการไฟล์ JSON ต่างๆ ซึ่งเราสามารถย้ายไปใช้ Environment Variable แทนได้ ซึ่งถูกต้องตามหลัก The Twelve Factors ด้วย

หรือการเรียกใช้ Package Dependency เกินความจำเป็น หรือไม่ได้ใช้แล้ว แต่ลืมลบ กรณีนี้เครื่องมือดีๆ สามารถช่วยเราได้ เช่น Visual Studio ที่จะทำการแจ้งเตือนให้เราลบตัวไม่ใช้ออก

ทั้งนี้ รวมไปถึงพวก Class, Function ต่างๆ ที่เขียนไว้ แต่ไม่ได้ใช้ ก็ต้องลบออกด้วย

ยิ่งเราทำให้ขนาดโค้ดเราเล็กลงได้เท่าไร ก็ทำให้ไฟล์ที่แพ็คขึ้นสู่ AWS Lambda (Deployment Package File) เล็กลงตามเท่านั้น มันจะส่งผลเรื่อง Cold Start ที่ลดเวลาลงไปด้วย

ลองดูได้จากสถติของเว็บ mikhail.io ที่เขาใช้ Javascript ในการแสดงคำว่า “Hello World” แต่ทดลองเพิ่ม NPM packages เข้าไปใน Deployment Package File ด้วย

ผลกระทบต่อมา ถ้าเราทำให้ Deployment Package File ใหญ่ขึ้น หมายถึงการทำให้ AWS Lambda Instances ใหญ่ขึ้นตามด้วย ถ้ามาถึงขั้นนี้แล้ว แม้จะเพิ่ม Memory เข้าไปช่วยเท่าไร ก็ไม่เห็นผลนะครับ เพราะ Cold Start ยังนานเหมือนเดิม แถมเสียเงินค่า Memory เพิ่มขึ้นด้วย

3. ลด และ/หรือ เลือกใช้ Dependency ที่จำเป็นและเหมาะสม

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

ปกติผมเขียน .NET Core ผมจะใช้ Entity Framework (EF) Core หรือ EF Core เพราะมันเหมือนชุดมาตรฐานที่ทำงานได้เข้ากันดี และมีเครื่องมือค่อนข้างครบ แต่ปรากฎว่า EF Core นี่เอง ทำให้ใช้เวลา Cold Start มากกว่าเดิมอย่างแสนสาหัส!!

ผมฝืนใช้มันอยู่นาน และไปหาทางแก้วิธีอื่นแทน จนกลับมาเอะใจตอนที่ Compile ว่า EF Core มันตัวใหญ่นี่หว่า ผมเลยลองเปลี่ยนไปใช้ ADO.NET หรือ Micro ORM อย่าง Dapper แทน ซึ่งผลปรากฎว่า เร็วขึ้นอีก 100% เลยทีเดียว

เรื่องนี้คงไม่ขอเขียนเยอะ กราฟมันบอกชัดเจนอยู่แล้ว หากใครสนใจลองเอาไปเปรียบเทียบ สามารถดาวน์โหลดโค้ดของผมได้จากที่นี่ (ต้องใช้ .NET Core 3.0, MySQL)

• ADO.NET – https://github.com/ifew/aws-lambda-db
• Dapper – https://github.com/ifew/aws-lambda-dapper
• Entity Framework (EF) Core – https://github.com/ifew/aws-lambda-efcore

กรณี Benchmark เทียบ Database Framework ดูเพิ่มเติมได้ที่

• Dapper vs Entity Framework vs ADO.NET Performance Benchmarking
• Fetch performance of various .NET ORM / Data-access frameworks
• Entity Framework Core 2.0 vs. Dapper performance benchmark, querying SQL Azure tables

4. Warm ตัว Server ของเราตลอดเวลา

หากเรามีความจำเป็นต้องใช้ Lambda อยู่บ่อยๆ มีผู้เข้าใช้กระจัดกระจายแบบกำหนดเวลาไม่ได้ รู้แต่เข้าเมื่อไร ต้องเร็ว เช่น การแสดงรายการสินค้าของหน้าเว็บไซต์ E-Commerce เป็นต้น ถ้าสุดท้ายแล้วเราไม่สามารถแก้ไขโค้ดได้อีก หรือไม่อยากเพิ่ม Memory อีก เราก็ต้องทำให้ Server ของเราตื่นอยู่เสมอนั่นเอง

วิธีการคือ การตั้งเวลาให้มี Cronjob ไปเรียก (Ping) Server ของเราอยู่เรื่อยๆ อย่างเช่น AWS Lambda ที่ผมเจอ จะ Idle ทุกๆ 5 นาทีไปแล้ว ผมก็ต้องหา Cronjob ไปทำการ Invoke Lambda ประมาณนาทีที่ 5 เสมอ

วิธีการแบบนี้จะเปลือง Request มาก เพราะแปลว่า 1 วัน ผมจะต้องปลุกมัน 288 ครั้ง ถ้าครั้งหนึ่งต้องใช้เวลาประมวลผล (Duration Time) 2 วินาที และจอง Memory 512MB คิดดูว่าเดือนหนึ่งผมจะต้องเสียเงินไปเท่าไร

ซึ่งหากใครสนใจลองทำ วิธีนี้ค้นเจอได้ตามเว็บทั่วไป ส่วนมากจะใช้ CloudWatch ในการทำ ซึ่งผมไม่รู้ว่าทำไมถึงแนะนำให้ทำกันแบบนี้ แต่มันก็ไม่ผิดนะ ถ้าเหมาะสมกับรูปแบบงาน คือ ถ้าตัว Server เราถูกเรียกบ่อยทั้งวัน กอปรกับใช้เวลาประมวลผลไม่มาก ใช้ Memory ไม่สูง ก็อาจจะเหมาะสม

สามารถดูเพิ่มเติมได้ที่

• How to Keep Your Lambda Functions Warm
• Tutorial: Schedule AWS Lambda Functions Using CloudWatch Events
• Lambda Warmer: Optimize AWS Lambda Function Cold Starts
• Lambda Warmer

5. Warm ตัว Server ของเราตามเวลาที่เหมาะสม

วิธีการนี้เหมือนกับข้อ 4 คือมี Conjob ไปเรียก (Ping) Server แต่ต่างกันที่ กำหนดเวลาในการเรียกให้ถี่มากน้อย ขึ้นกับการใช้งานจริง

เช่น 08:00-22:00 คนเข้าเว็บไซต์เยอะ ก็ให้เรียกทุก 5 นาที เพื่อให้ Instances ไม่เข้าโหมด Idle ส่วนเวลาตั้งแต่ 22:01-07:59 ให้เรียกทุก 10 นาที แทน เป็นต้น

หรือใคร Advance หน่อย ก็ทำสคริ้ปอัตโนมัติเพื่อ Edit Config Lambda ในช่วงเวลา 22:01-07:59 เพื่อปรับ Memory ขึ้นไป แต่ไม่ต้องทำการ Ping ซึ่งมันก็จะไปใช้สูตรแบบข้อ 1. เพิ่ม Memory Allocated แทนการใช้แบบข้อ 4. เพื่อ Warm ตัว Server ตลอดเวลา

สามารถดูเพิ่มเติมได้ที่

• AWS CLI – Modify the version-specific settings of a Lambda function
• How to trigger aws lambda at different schedule every day

6. ใช้ Custom Runtimes และเลือกใช้ Runtimes ที่ทำงานได้เร็ว

กรณีของผู้ให้บริการอย่าง Amazon ได้เพิ่มฟีเจอร์มาให้กับ AWS Lambda คือ การ Custom Runtimes ได้เอง โดยไม่จำเป็นต้องใช้ตัวมาตรฐานที่ให้มา

ตัวอย่างเช่น .NET Core Runtime ที่ทาง Amazon มีมาให้คือ version 1.0 และ 2.1 เท่านั้น

.NET Runtimes (ดูเพิ่มเติม ได้ที่ AWS Lambda Runtimes)

แต่ปัจจุบันมี 2.2 และ 3.0 แล้ว ซึ่งถ้าเราพบว่า 3.0 ทำงานได้ดีกว่า หรือไวกว่า เราก็สามารถสร้าง Runtimes ขึ้นมาเองได้ หรืออาจจะไปสร้างเป็น PHP Runtimes ก็ยังได้ ถ้าเราอยากจะใช้ แต่ Amazon ไม่ได้ทำรองรับ

ในประเด็นนี้ ผมพยายามทดสอบหลายครั้ง ผมพบว่าใน .NET Core เมื่อทำ Custom Runtimes แล้ว ไม่ได้ช่วยทำให้ไวขึ้นแต่อย่างใด แถมช้าลงด้วย มีดีอย่างเดียวคือ ได้ใช้ฟีเจอร์ใหม่ๆ ในเวอร์ชั่นใหม่ (แต่ในภาษาอื่นๆ ถ้าใครทำดูแล้วได้ผลที่ดีขึ้น ลองมาแชร์กันได้ครับ)

สังเกตว่า ตัวมาตรฐาน .NET Core 2.1 Runtimes ทำงานได้ไวกว่าที่ผม Custom Runtimes เอง ที่เวอร์ชั่น 3.0 (แม้ว่าจริงๆแล้วผล Benchmark ของ .NET Core 3.0 จะทำงานได้ไวกว่า 2.1 ในสภาพแวดล้อมที่ไม่ใช่ AWS Lambda ก็ตาม)

ใครอยากทดสอบ Custom Runtimes ลองดูโค้ดตัวอย่างที่ผมทำไว้ได้

• .NET Core 3.0 – https://github.com/ifew/aws-lambda-crt-example
• .NET Core 3.0 with ADO.NET – https://github.com/ifew/aws-lambda-crt-db
• .NET Core 3.0 with Dapper – https://github.com/ifew/aws-lambda-crt-db-dapper

เรื่อง Custom Runtimes สามารถศึกษาเพิ่มเติมได้ที่นี่ครับ

• Custom AWS Lambda Runtimes
• Benchmarking Lambda’s New Custom Runtime for .NET Core

7. ใช้ Custom Runtimes และทำเป็น Native App

แม้ว่าการทำ Custom Runtimes ผมจะไม่พอใจกับผลลัพธ์ที่เกิดขึ้น (กรณี C# .NET Core) แต่เราสามารถเอาวิธีการเดียวกันมาเรียกใช้ Binary Executable File แทนได้นะ ด้วยการทำโค้ดของเราให้เป็น Native Application ซะเลย

การแก้ไขปัญหาด้วยวิธีนี้ ผมภูมิใจนำเสนอมากๆๆๆ เรียกได้ว่า เป็นไม้ตาย ที่แก้ปัญหา Cold Start ได้อยู่หมัดจากทุกๆ วิธีที่ผมทำมาเลยทีเดียว แต่ก็ค่อนข้างทำยากและมีข้อจำกัดเยอะ

มาลองดูสถิติที่ผมทำบน C# .NET Core กัน ว่าผลแตกต่างแค่ไหน ซึ่งผมเทียบโดยใช้ Database Framework ต่างกัน 3 ตัว ที่ทำงานต่างกันบน Runtimes แบบปกติ (.NET Core 2.1), Custom Runtimes (.NET Core 3.0) และ Native (.NET Core 3.0 + CoreRT)

จากตาราง ตัว Lambda Native (ช่องสีเขียว) ชนะใสๆ แบบขาดรอย เพราะ Cold Start แค่ 1.3 วินาที ในขณะที่ตัวอื่นๆ ทำงานที่ 10-33 วินาที (เทียบกันที่ ADO.NET)

สังเกตว่าทำไมผมมี Lambda Native แค่ ADO.NET อย่างเดียว

เนื่องจาก Lambda Native ใช้ Runtimes ชื่อว่า CoreRT ซึ่งมันเป็น .NET Core runtime อีกตัวที่พัฒนามาเพื่อ AOT (ahead of time compilation) โดยเฉพาะ กล่าวคือ มันจะแปลงภาษาจาก High-Level Programming เช่น C#, Java ไปเป็นภาษาเครื่อง (Machine code) กันเลยทีเดียว

แต่ๆๆ เจ้าตัว CoreRT ยังไม่สมบูรณ์นัก และมีผู้ใช้งานไม่มาก หาข้อมูลได้ยาก จึงทำให้การพัฒนาได้ยากตาม รวมไปถึงหลายสิ่งยังไม่สามารถใช้งานได้ เช่น เมื่อมีการเอา Dapper มาใช้ แต่โดนแจ้ง Error ว่า “Operation is not supported on this platform” ด้วยเหตุผลนี้เอง ผมถึงบอกว่า ทำไมยังมีข้อจำกัดอยู่ และทำได้ยาก

ดูตัวอย่างที่ผมทำได้ที่นี่

• Hello World – https://github.com/ifew/aws-lambda-lambdanative
• ADO.NET – https://github.com/ifew/aws-lambda-lambdanative-db

สามารถดูข้อมูลการทำ Lambda Native เพิ่มเติมได้ที่

• LambdaNative – https://github.com/zaccharles/lambda-native
• CoreRT – https://github.com/dotnet/corert

8. หลีกเลี่ยงการใช้ VPC ถ้าไม่จำเป็น

Update 6 Nov 2019 – ทาง AWS ได้แก้ไขปัญหาเรื่อง Cold Start เนื่องจากใช้ VPC แล้ว ซึ่งมีผลกับ Region ดังนี้ US West (N. California), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and South America (San Paulo) – ที่มา aws.amazon.com

Update 27 Sep 2019 – ทาง AWS ได้แก้ไขปัญหาเรื่อง Cold Start เนื่องจากใช้ VPC แล้ว ซึ่งมีผลกับ Region ดังนี้ US East (Ohio), EU (Frankfurt), and Asia Pacific (Tokyo) – ที่มา aws.amazon.com

…

คำแนะนำจาก theburningmonk.com บอกว่า ควรหลีกเลี่ยง ถ้าไม่จำเป็น เพราะการใช้ VPC มันจะกำหนดให้ Lambda ต้องสร้าง ENIs ขึ้นมา (Elastic Network Interface) เพื่อใช้คุยกันภายใน VPC และในเว็บไซต์บอกว่า กระบวนการนี้มันจะทำให้เพิ่มเวลา Cold Start อีกประมาณ 10 วินาที!!

และในเว็บไซต์ epsagon.com ได้ให้ข้อมูลเพิ่มเติมว่า การกำหนด Memory ที่มากขึ้น ใน AWS Lambda ของภาษา C# , Java มันจะทำการสร้าง ENIs เพิ่มจำนวนขึ้นด้วย แม้ว่า AWS Lambda จะมีกระบวนการที่นำ ENIs เก่ามาใช้ใหม่ได้ก็ตาม โดยสังเกตได้จากสูตรที่ชี้แจงไว้ใน AWS Document

ดังนั้น สรุปได้คือ ถ้าเราใช้ VPS และยิ่งเพิ่ม Memory Allocate เข้าไปในตัว AWS Lambda มันก็จะยิ่งเพิ่ม ENIs ให้เหมาะสมกัน และจะส่งผลกับ Cold Start ที่ใช้เวลามากขึ้นตามไปด้วย

ปล. มีข่าวดีแว่วๆมา อ้างอิงจาก @jeremy_daly ที่เข้าร่วมงาน AWS re:Invent ว่า AWS มีแผนจะแก้ปัญหาเรื่องนี้ภายในปี 2019 นี่แหละครับ

9. เลือกภาษาเพื่อใช้ทำ Serverless ที่เหมาะสม

ข้อสุดท้าย ถ้าไม่ผูกติดกับภาษาในการพัฒนา Serverless แนะนำให้ใช้ตระกูล Scripting Language แทน Compiled language จะช่วยแก้ปัญหา Cold Start ได้อย่างมาก

ลองดูจากสถิติของเว็บไซต์ mikhail.io

พวก JavaScript, Python, Go, Java, และ Ruby จะทำงานเสร็จแถวๆ 500ms หรือไม่เกิน 800ms แต่สำหรับ C# จะใช้เวลาตั้งแต่ 0.8 จนถึง 5 วินาที เลยทีเดียว

ตัวอย่างสถิติอีกสักแห่ง จากเว็บไซต์ read.acloud.guru

สถิติจากเว็บไซต์นี้ ได้ผลใกล้เคียงกับที่แรกคือ พวก JavaScript, Python ยังคงทำงานได้เร็วแถวๆ 500ms ส่วน Java และ C# ใช้เวลา Cold Start นานมาก

และให้ข้อมูลเพิ่มเติมนิดนึงครับว่า แม้จะเปลี่ยนผู้ให้บริการ ก็ได้ผลไม่ต่างกัน ถ้าหากใครคิดว่า ใช้ C# บน Azure Function น่าจะเร็วกว่า AWS Lambda นั้น คิดผิดนะคร้าบบบ..

ให้สังเกตว่า C# บน Azure Function ทำงานได้ช้ากว่า AWS Lambda ประมาณ 500ms – 1 วินาที เลยทีเดียว

อ่านข้อมูลการเปรียบเทียบเพิ่มเติมได้ที่นี่

• Comparing AWS Lambda performance of Node.js, Python, Java, C# and Go
• How does language, memory and package size affect cold starts of AWS Lambda?

สรุป

ตอนนี้เราก็คงต้องต่อสู่กับ Cold Start กันต่อไป เพราะเราไม่สามารถแก้ไขอะไรมันได้มากนัก ส่วนผู้ให้บริการเองอย่าง Amazon, Azure, Google Cloud ก็รู้ปัญหานี้เช่นกัน และพยายามปรับปรุงมันให้ดีขึ้นอยู่เรื่อยๆ แต่ที่สำคัญ ก่อนที่เราจะตัดสินใจใช้ Serverless เราต้องคิดให้ดีก่อนว่าเหมาะสมกับงานของเราแล้วหรือยัง

—

ที่มาภาพหน้าปก http://www.drunktiki.com/2016/08/17/yoda-pug/yoda-pug-jpg/