Low Code != Low Effort

หลังจากที่เห็น Clip พูดถึง Low Code ว่าช่วยทำให้เขียนโปรแกรมได้ง่ายขึ้น เร็วขึ้น ก็รู้สึกว่าทำไมมันช่างต่างจากที่ผมเคยสัมผัสและได้ยินจากปากคนที่เคยใช้มาเสียเหลือเกิน ผมก็เลยอยากจะเล่าให้ฟังแบบ "อาศัยความรู้สึก" เป็นหลัก ไม่ได้ให้ใครจะมาคล้อยตาม เพียงแต่กระตุกให้คิดสักนิดนึง

ในโลกของ Low Code มีวิธีตั้งต้นการพัฒนา App อยู่หลายวิธี แต่ส่วนใหญ่จะเริ่มด้วยสองวิธีนี้คือ เริ่มต้นด้วย User Interface ซึ่งตัวที่เริ่มต้นด้วยวิธีนี้ ได้แก่ Microsoft Power App เข้าใจว่าอีกหลายตัวก็เริ่มแบบนี้เหมือนกัน แต่เนื่องจากไม่ได้ผ่านมาในงานที่เคยทำจึงไม่ขอพูดถึง การพัฒนาในเริ่มต้นด้วย UI เป็นเรื่องที่ Front-End Developer ส่วนใหญ่เข้าใจได้ง่าย

อีกวิธีคือเริ่มต้นด้วย Data Model ซึ่งวิธีนี้เป็นวิธีที่ดีถ้ามีการออกแบบโครงการอย่างครบถ้วนก่อนลงมือ Implement ตัวอย่างผลิตภัณฑ์ที่ไปในแนวทางนี้ได้แก่ Mendix ซึ่ง Front-End Developer มักจะมีปัญหากับการพัฒนาในแนวทางนี้ แต่คนที่ทำงานกับข้อมูลมากๆ จะชอบ

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

Low Code Platform เหมาะกับ Application ประเภทไหน

ประเภทแรกคือ Stand Alone App ที่มีเพียง App กับ Database หรือ Data Object ไม่ได้มีการ Integrate กับภายนอก ทั้งหมดจบอยู่ใน App ซึ่ง Low Code Platform จะเหมาะกับ App แบบนี้มากที่สุด

ประเภทที่สองคือ App ที่มี Integration กับภายนอกผ่านตัว Low Code Platform เองที่เรียกว่า Connector ไม่ว่าจะเป็นของเจ้าของ Platform หรือ Third-Party Connectors ก็แล้วแต่ ซึ่งการเลือกใช้ Low Code กับงานประเภทนี้ ต้องคำนึงเสมอว่าในอนาคตนั้น App ของเราไม่ควรจะมีการ Integrate กับบริการที่ไม่มี Connector รองรับ

Low Code Platform ไม่เหมาะกับ Application ประเภทไหน

ผมเจองานสองแบบที่ไม่เหมาะกับ Low Code Platform เลย งานเหล่านี้ประเภทแรกได้แก่ งานที่อยากใช้ความสามารถของ Hardware เช่นอยากให้กล้องมือถือสแกน Bar-code ไม่ว่าจะเป็นมิติเดียวหรือสองมิติอย่าง QR Code ก็ตาม แบบนี้ต้องอาศัยการพลิกแพลงที่เยอะมากเพราะ Platform ส่วนใหญ่ไม่รองรับ

ประเภทที่สองคือมีการ Integration กับหลายระบบ แม้ว่าหลาย Platform จะรองรับ Integration กับ In-House Service ก็ตาม พอทำงานจริงๆ เจอท่าแปลกๆ อย่าง Asynchronous Callback หลาย Platform ก็ไปลำบาก เหมือนกัน (แต่ก็อีกงาน Development ทั่วไปคงเป็นแต่ Synchronous)

แล้วทำไม Low Code != Low Effort

ถ้าคุณทำงานในองค์กรขนาดเล็กที่ไม่ได้มี Integration เยอะแยะไปหมด ไม่มีความต้องการแปลกๆ ในการทำงาน Low Code อาจทำให้ Low Effort ในการได้สักแอปขึ้นมา แต่ถ้าคุณอยู่ในองค์กรใหญ่ Low Code Platform ทำให้ Effort ในการทำงานอาจจะไม่ได้ Low จริงเช่น

1. ถ้าคุณต้องทำการเชื่อมต่อกับระบบอื่นๆ มากมาย แต่ไม่ได้มี Connector มากับ Platform นั้นๆ คุณคงต้องพลิกแพลงในการทำงานมาก บางกรณีอาจจะมากกว่าการเขียนแอปแบบปกติ
2. บางทีคุณจะพบว่า Feature ที่คุณอยากได้ ไม่ได้อยู่ใน Low Code Platform ที่คุณเลือก แต่มีใน Platform อื่น คุณจะเลือกใช้อีก Platform หรือไม่ หรือทนใช้ของที่มีอยู่
3. ตามที่ผมเข้าใจ Low Code Platform ไม่ได้ทำงานข้ามค่ายได้ ไม่เหมือนกับการเลือกใช้ Framework ต่างๆ ในการพัฒนา Software ตามปกติ

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

ต้องขอย้ำว่าบทความนี้เป็นความเห็นส่วนตัวล้วนๆ ถ้าใครมีประสบการณ์แบบอื่นลองมาเล่าสู่กันฟัง

Security ใน DevOps ต่างจาก DevSecOps อย่างไร

มีคำถามเรื่อง DevSecOps ว่า Dev กับ Ops ก็มี Security อยู่แล้วไม่ใช่หรือ ทำไมต้องมี DevSecOps เพิ่มขึ้นมา คำตอบของคำถามแรกคือทั้งใช่และไม่ใช่ ส่วนคำถามหลังต้องอธิบายเพิ่มเติม

ในการทำ DevOps ในส่วน Security ที่ควรจะมีอยู่แล้วด้าน Dev ก็คือเรื่องของ Secure Design และ Secure Coding ซึ่งเป็น Practice ที่จำเป็นต้องมีในการ Implementation เช่นการปฏิบัติตาม OWASP Application  Security Verification Standard เป็นต้น อีกด้านคือฝั่ง Ops ที่ควรจะมีโดยพื้นฐานก็เช่นการทำ Hardening หรือ Secure Deployment Process เป็นต้น

แล้ว DevSecOps มาช่วยอะไร

ในการพัฒนา Software นั้นถ้าอ้างอิงตาม Microsoft Security Development Lifecycle (SDL ดู https://www.microsoft.com/en-us/sdl/) การทำ Automation ของ DevSecOps นั้นอยู่ที่ Implementation และ Verification

Microsoft Security Development Lifecycle

• 
  

ในขั้นตอนหลังจาก Implementation จะต้องมีการทำ Security Practice ก็คือตรวจสอบว่าใช้เครื่องมือในการพัฒนา (Tool Chain) และ Library ที่ได้รับการอนุมัติแล้วหรือเปล่า รวมทั้งการทำ Static Code Analysis  เป็นต้น นี่เป็นขั้นตอนก่อนการ Compile และ Build เพื่อทำ Automate Testing

ขั้นตอน Verification ประกอบด้วยการทำ Dynamic Analysis เช่นทำ Vulnerability Assessment Scanning ทำ Fuzz Testing โดยการลองป้อนข้อมูลที่ไม่อยู่ในรูปแบบที่ถูกต้อง (Malformed Data) เพื่อทดสอบว่าแอพพลิเคชั่นสามารถจัดการกับข้อมูลเหล่านี้ได้โดยไม่ก่อให้เกิดปัญหาทางด้าน Security ไปจนถึงการทํา Penetration Testing ซึ่งขั้นตอนนี้ควรทำหลังจากทำ Automate Testing เสร็จเรียบร้อยแล้ว และก่อน Deployment

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

สำหรับท่านที่สนใจสามารถหาอ่านรายละเอียดได้จากเอกสาร White Paper ตามลิงค์ด้านล่าง

http://www.devseccon.com/wp-content/uploads/2017/07/DevSecOps-whitepaper.pdf

ก็เขียนโปรแกรมตลอดมา และจะเขียนโปรแกรมตลอดไป

เมื่อยี่สิบกว่าปีก่อนตอนเป็นพนักงานขายซึ่งภายหลังเปลี่ยนมาเป็นพนักงานสนับสนุนการตลาดของบริษัทแห่งหนึ่ง ได้รู้จักพี่คนหนึ่งซึ่งเป็นผู้บริหารระดับ VP ของบริษัท ซึ่งงานที่ทำตามหน้าที่รับผิดชอบของเขาไม่น่าสนใจเท่าไรหรอก แต่ผมสนใจสิ่งที่พี่เขาทำตอนนั้นมากกว่า วันๆ เอาแต่นั่ง Download File มาทำการ Compile สิ่งเล็กๆ ที่เรียกว่า Linux บนเครื่อง 386 ด้วย Modem สุดหรู 9600 bps ยี่ห้อ Nokia และเริ่มได้ยินคำว่า Internet

จากที่เคยคิดกับตัวเองว่าเรียนจบจะไม่เขียนโปรแกรมอีก ก็เริ่มคิดใหม่ ตอนช่วงนั้นก็เลยกลับมาเขียนภาษา C พร้อมกับ VBA บน MS Access 2.0 ทั้งไปรับงานเขียนโปรแกรมที่โรงหนังแห่งหนึ่งมาทำ จากนั้นก็แยกย้ายกันไป ต่อมาพี่คนนั้นก็ไปเป็นถึง President บริษัท ISP แห่งหนึ่ง ก่อนจะออกไปและได้ข่าวว่าก็ยังเขียนโปรแกรมอยู่

ส่วนผมก็ทำงานจับฉ่ายไปทั่ว ไปขาย Router เขียน Web Application บน Windows และ Red Hat ขายของ ขายซอฟต์แวร์ กระโดดมาจับ Embedded System ออกแบบ Hardware และเขียน Firmware พอเจอระบบซับซ้อนก็เลยต้องมาใช้สิ่งเล็กๆ ที่เรียกว่า Linux ต้อง Compile Kernel และ Build Image เอง ดีกว่าพี่เขาหน่อยตรงที่เป็น 512 kbps แล้ว เขียน shell script เขียน C เปิด Socket ทำ Service ไปตามเรื่องตามราว มีบางโครงการต้องเขียน UDP/IP Stack เองบน ARM (Atmel SAM7X)

จากนั้นมีปัญหาสายตาก็ตัดสินใจว่าจะหยุดเขียนโปรแกรม ไปขายของ ไปทำ Information Security จนมาถึงจุดที่ต้องทำงานเกี่ยวกับ Log เครื่องมือในท้องตลาดมันไม่ได้ดั่งใจ เลยต้องมานั่งเขียน Filter เอง ทำ Data Analytics กับชุดข้อมูลที่ใหญ่เกินกว่า Excel จะรับไหว คือเกิน ล้านสองแสน Row ยิ่งต้องมาแตะ Application Security จากที่เคยคิดว่าจะไม่เขียนโปรแกรมอีก  ก็กลับมาเขียนจนได้ ไม่งั้นโปรแกรมเมอร์ก็ไม่ยอมเชื่อ

ไม่รู้ว่าข้างหน้าจะเป็นยังไงแต่น่าจะได้ข้อสรุปล่ะว่าก็เขียนโปรแกรมตลอดมา และจะเขียนโปรแกรมตลอดไป