กระบวนการ Deliver Software จาก Ideas จนถึงใช้งานบน Production ต้องผ่าน process อะไรบ้างเมื่อพิจารณากระบวนการ DevOps เข้ามาเกี่ยวข้อง สามารถสรุปเป็นแนวทางได้ดังนี้

เราควรมี Product Team ที่ประกอบด้วยผู้ที่เกี่ยวของกับการพัฒนา Product เช่น Product Owner, Designer และ Developer ทั้งนี้ทีมควรพิจารณาเรื่อง Balance Team ที่ต้องมีผู้ที่เกี่ยวข้องกับการพัฒนาและส่งมอบ Product อยู่ในทีม เพื่อให้การดำเนินการใดๆ สามารถทำได้เลย ไม่ต้องเสียเวลาในการขอความร่วมมือใดๆ ข้าม Team เช่นการมี Security และ Operation อยู่ใน Team ด้วย จะทำให้ทุกคนเข้าใจใน Product ที่กำลังพัฒนา การตัดสินใจ การร่วมไม้ร่วมมือตั้งแต่ต้น และตลอดการพัฒนา โดยใช้หลักการ Why (ทำไมเราต้องพัฒนา) What (ส่ิงที่ต้องพัฒนาคืออะไร) How (จะพัฒนาขึ้นมาได้ยังไง) เพื่อส่งเสริมความเข้าใจ และทำงานร่วมกันภายในทีม

เครื่องมือที่เกี่ยวข้อง

• Portfolio Management
• Application Lifecycle Management
• Team Collaboration and Work Tracking (Jira)
• Security Architecture and Design
• Threat Modeling
• Knowledge Sharing (Confluence)

สิ่งที่เป็น Output ของ Team คือ Source Code รวมถึง Application Code, Testing Code และ Infra Code จะถูกจัดการด้วย Code Repository (GitLab, GitHub, GitBucket) เพื่อให้สามารถจัดการเรื่อง Versioning และการ Peer Review กับผู้ที่เกี่ยวข้องได้ และต้องมีการจัดการเรื่อง Quality ของ Code เช่น จำนวน Test Coverage การ Follow ตาม Practice ของการเขียน Code เช่น Code Quality/Secure Coding Standards (SonarQube, Snyk) และมีการ Integrate Security Tool เพื่อตรวจสอบช่องโหว่ด้านความปลอดภัยในระดับ Code เช่น Open Source Security & License Tracking (BlackDuck, Snyk), Static Application Security Testing – SAST (Coverity, Fortify, SonarQube, Checkmarx, Veracode) เป็นต้น

เมื่อ Code ผ่านกระบวนการตรวจสอบแล้ว กระบวนการต่อไปคือการ Build (maven, npm, MSBuild) โดยจะได้ Binary File ที่สามารถทำงานได้ (Working Software) ทั้งนี้ขั้นตอนการ Build จะมีการเรียก Unit Test (junit, Nunit) และ Functional Test (Cucumber) หลังจากนั้นก็จะจัดเก็บ Binary File ไว้ใน Application Repository (jFrog, Nexus)

ถ้า Software จะต้องทำงานบน Container Platform ก็ต้อง Pack Binary File ไว้ใน Container Format (Containerize) ด้วยเครื่องมือ Container Build (Docker file, Buildpack) และจัดเก็บไว้ใน Container Registry (Habor, jForg, DockerHub) หลังจากนั้นจึงจะทำการสร้าง SBOM (Software Bill of Material) เพื่อเป็น metadata file อธิบายถึง ข้อมูล Components ต่างๆ ที่ใช้ในการสร้าง Software ขึ้นมา แล้วต่อด้วย Software Composite Analysis – SCA (Trivy, BlackDuck, Snyk, jFrog X-Ray) เพื่อหาช่องโหว่ด้านความปลอดภัยของ software components ต่างๆ ที่นำมาใช้

จากนั้นจะต้องมีการออก Release Number ของ Software เพื่อเป็น Reference ในระบบ Release Management ที่ประกอบด้วย Features หรือ Update ต่างๆ ของ Software Release และ Update ไปยังระบบ Work Tracking และทำการ Tag Release Version ใน Code Repository

หลังจากกระบวนการออก Release Version ของ Software เสร็จจะขึ้นอยู่กับการตกลงของทีม Delivery และ QA ที่จะนำ Software Release เข้าสู่กระบวนการทดสอบโดยทีม QA และ Security ที่ครอบคลุมทั้งที่เป็น Functional และ Non-Function Test โดยมีเครื่องมือ Quality Management และ Update ไปยัง Work Tracking

เครื่องมือที่ QA ใช้ในการทดสอบ Software เช่น

• Katalon Studio
• Selenium
• Appium
• Applitools
• Blazemeter
• Saucelabs
• Smartbear
• Wiremock

เครื่องมือสำหรับ Dynamic Application Security Test เช่น

• Fortify
• Aqua Sec
• OWASP ZAP
• Tanable Web App Scan

เครื่องมือในการทำ performance test เช่น

• JMeter
• Smartbear
• Postman
• Locust

การจะนำ software ที่ผ่านการทดสอบแล้วขึ้น production อาจจะมีกระบวนการ approval process และทำการ deploy ด้วยวิธีการที่เหมาะสมเช่น blue-green, cannary  หรือ a/b testing หลังจากนั้นอาจจะมีเครื่องมือสำหรับตรวจสอบความปลอดภัย เช่น Infra Valnerabilities (Tenable Nessus), Interactive application security testing – IAST (AquaSec, Twistlock, Synopsys Seeker) และ Chaos Testing (Chaos Monkey, Chaos Mash) เพื่อให้มั่นใจว่าระบบจะสามารถทำงานได้ในสถานการณ์ต่างๆ เช่น ช่วง peak time และบางส่วนของระบบมีปัญหา

สิ่งที่สำคัญที่ขาดไม่ได้คือ log, monitoring และเก็บข้อมูลสถิติต่างๆ (Metric Collection – Prometheus, InfluxDB) เพื่อนำมาใช้ในการปรับปรุงระบบ ให้ดีขึ้นเรื่อยๆ ด้วยการ Update ข้อมูลกลับไปยัง Product Team พิจารณาแก้ไขให้ดีขึ้น

เครื่องมือสำหรับ Log และ Monitoring เช่น

• Datadog
• Grafana
• Appdynamic
• Dynatrace
• Splunk
• Solarwind
• Elastic Stack (EFK, ELK)

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

devops เกิดขึ้นจากปัจจุบันที่แต่ละทีม มีการแข่งขันกันในการสร้าง Innovation และนำ technology ใหม่ๆ มาใช้เพื่อปรับปรุงการทำงาน และสร้าง service ต่างๆ ออกมาให้ตรงใจและพึงพอใจต่อผู้ใช้งาน

Development team มีการใช้ technology container ในการ package application ด้วยการ pack ความต้องการที่ application ต้องใช้ในการทำงานไว้ใน package เดียวทั้งที่เป็น OS, application dependency, lib และ configuration ที่จำเป็น ทำให้ container สามารถทำงานในสภาพแวดล้อมต่างๆ ได้ง่าย และการทำงานได้ผลลัพธ์ไม่แตกต่างๆกัน

ขณะเดียวกัน Operation team ก็ศึกษา Kubernetes เพื่อให้เป็น platform สำหรับ application team สามารถเรียกใช้ผ่าน APIs ในการ deploy และทดสอบ application โดยที่ไม่ต้องเสียเวลาในการขอบริการ Virtual Machine, Network, Storage ทำให้ประหยัดเวลาในการให้บริการกับทีม Developer (Kubernetes = Infra APIs)

จะเห็นว่าแต่ละทีมต่างก็เสนอ Innovation ใหม่ๆ สิ่งที่เกิดขึ้นคือเกิดการพูดคุย ร่วมด้วยช่วยกันมากขึ้นระหว่างทีม Development และ Operation เกิดเป็น Culture และมีเป้าหมายที่ชัดเจนในการที่จะทำยังไงเพื่อทีจะทำให้การสองมอบ application และบริการถึงมือผู้ใช้ได้ดีที่สุด

ดังนั้น DevOps จึงเป็น culture ไม่ใช่ tool หรือ technology

Culture

DevOps เกี่ยวข้องกับการทำลายอุปสรรคระหว่างทีม เวลาที่เสียไประหว่างที่รอเพื่อให้ได้ resource ตามความต้องการ เอกสารและ process ที่ทำให้กระบวนการส่งมอบ software ไม่มีประสิทธิภาพ การที่ทีม Dev และ Operation มีการพูดคุยเพื่อทบทวนกระบวนการ และหา tool ที่สามารถลดขั้นตอน รวมทั้งลดอุปสรรค์ระหว่างการส่งมอบ software ให้น้อยที่สุด จะส่งผลดีโดยรวมต่อระบบ IT

Automation

เพื่อให้บรรลุเป้าหมาย การใช้ระบบอัตโนมัตินอกจากช่วยประหยัดเวลาแล้วยังป้องกันข้อบกพร่อง สร้างความสม่ำเสมอ รวมถึงการส่งเสริมการให้บริการในรูปแบบ self-service ในทีม

Measurement

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

Sharing

กุญแจสำคัญของความสำเร็จของ DevOps ในทุกองค์กรคือการแบ่งปันเครื่องมือ ความรู้ บทเรียนที่ค้นพบ เพื่อให้ทีมได้รับข้อมูลเกี่ยวกับวิธีการใหม่ๆ สร้างสรรค์สิ่งใหม่ๆ สร้างการเรียนรู้ในทีมร่วมกัน

ทุกองค์กร จำเป็นต้องมี DevOps การจะพัฒนา culture นี้ขึ้นมา จะช้าหรือเร็วนั้นขึ้นอยู่กับวัฒนธรรมองค์กรนั้นๆ ว่าเอื้ออำนวยขนาดไหน ไม่ช้าก็เร็วองค์กรก็จะต้องมี DevOps เกิดขึ้น เหมือนถนนที่ใช้เดินทางไปยังกรุงโรม ที่เมื่อออกเดินทาง ปลายทางก็จะเป็นกรุงโรม

Note:

DevOps = Developer + Operation

DevSecOps = Developer + Security + Operation เป็น term ใหม่ ที่ทีม security เข้ามาร่วมด้วยในกระบวนการส่งมอบ software โดยการใช้ทักษะและ tool ที่ทีม security มีมาใช้เป็นส่วนหนึ่งในกระบวนการส่งมอบ โดยการตรวจสอบช่องโหว่ด้านความปลอดภัยตั้งแต่เริ่มต้น develop software (shift-left security)

FinOps = Financial + Operation เป็นอีก term ที่ทีม financial ที่เป็นผู้ support เรื่อง budget ต่างๆ สำหรับทีม operation เพื่อใช้ manage application อยากรู้ข้อมูลเรื่องค่าใช้จ่าย และความสมเหตุสมผลการการลงทุน การมีข้อมูลที่ monitor เรื่อง IT spending อยู่ตลอดเวลาทำให้ทีม Finance สามารถ plan เรื่อง budget และควบคุมค่าใช้จ่ายได้ ขณะเดียวกัน operation team ก็สามารถใช้ข้อมูลนี้ในการ optimize resource ที่ใช้สำหรับ run application ได้เช่นเดียวกัน

สรุปมาตรฐานในการพัฒนา DevOps ในองค์กร เพื่อเป็นหลักพิจารณาในการเริ่มต้นสร้างวัฒนธรรม (culture) กระบวนการ (process) และเลือก technology ที่เหมาะสม โดยสรุปเป็นหลักการได้ดังนี้

12 Factors

Application ต้องถูกสร้างตามหลักการ 12 Factors ซึ่งเป็นหลักการในการพัฒนา cloud native application ที่สามารถทำงานในสถาพแวดล้อมที่แตกต่างๆ กันได้ง่าย โดยมีหลักการเช่น ไม่เขียน log ลง file โดยให้ผ่าน standard output สร้าง environment ที่มี component, version และ configuration เหมือนกัน (dev, sit, prod) จัดการ configuration แยกจาก application ผ่านทาง environment เป็นต้น

Git Pre-Commit Hooks

ต้องมั่นใจว่ามีการใช้ pre commit hooks ของ GIT เพื่อ validate code ก่อนที่ code จะถูกจัดเก็บใว้ใน repository การทำ hook คือทุกครั้งที่ engineer ทำการ push code ไปยัง source control นั้น code จะถูกตรวจสอบและทำการ test ก่อน เพื่อป้องกัน code ที่ไม่สมบูรณ์​​ (poor quality code) ถูกเขียนลง repository การที่มี process นี้ก่อนกระบวนการ commit จะทำให้มั่นใจได้ว่า code ที่จัดเก็บจะเป็น code ที่มีคุณภาพเสมอ แนะนำตรวจสอบตามรายการดังนี้

• Linting เป็นการตรวจสอบ code ว่าตรงตาม coding standards หรือไม่ เช่น การตั้งชื่อ function หรือ variable การใช้ space การเขียน comment
• Unit Tests ทำการ execute test case
• Commit Message เช่น commit message จะต้องมีอย่างน้อย 80 ตัวอักษร เพื่อเป็นการบังคับให้ engineer สื่อความหมายของ code ที่จะเก็บใน repository ได้จัดเจน
• Jira มีการ reference ส่วนของ code กับ ticket ใน Jira เพื่อให้สามารถ trace ได้ว่า code ชุดนี้เกี่ยวข้องกับ requirement อะไร

Source Code Management

Source code จะต้องถูกจัดการผ่าน Gitlab หรือ git version control รวมถึง Infra code หรือ technical code อื่นๆ เป็นการจัดการ code ที่เดียวเพื่อความชื่อถือและถูกต้องเสมอสำหรับ development team (one source of truth) โดยมีหลักพิจารณาคือ

• Trunk Based Development เป็นการให้ engineer ทำงานอยู่บน development branch (main branch) ในระยะเวลาที่สั้น (short iterations) ดีกว่าให้มีหลายๆ release หรือ feature branch เพื่อลดปัญหาเรื่องความซับซ้อนและยากลำบากในการ merge code (merge conflicts)
• Feature Toggles สำหรับ code ที่ยังใช้งานไม่ได้ หรือพัฒนายังไม่เสร็จจะต้องถูกซ่อนไว้ โดยใช้ feature toggle เพื่อป้องกันหรืออนุญาติให้มีการนำ code ไปใช้
• Configuration in Environment ไม่เก็บ configuration ต่างๆ ใว้ใน source code เพื่อป้องกันไม่ให้ส่วนที่เป็น credential หรือข้อมูลสำคัญรั่วไหล อีกทั้งยังเป็นการทำให้ code ไม่มี dependency เรื่อง config สามารถจัดการ config ผ่านทาง environment ที่ง่ายกว่าและย้ายไปยัง environment ได้สะดวกด้วย

Continuous Integration and Delivery (CI/CD)

ทุกๆ commit ใน git จะมีการ start CD/CD pipeline เพื่อมั่นใจว่าทุก code จะมีการ run ขั้นตอนต่างๆ ที่เป็นมาตรฐานในการส่งมอบ Application ขององค์กร

• Validate code standard อย่างเช่น space และ brackets ที่อ่านง่าย
• Execute test case
• Code quality metric จะต้องมั่นใจว่า code ผ่านมาตรฐานที่กำหนดไว้ เช่น ไม่มีช่องโหว่ด้านความปลอดภัย (vulnerabilities) จำนวน coverage unit จะต้องมีมากกว่า 80% จำนวน smells bug หรือ code ที่เขียนโดยไม่เป็นไปตาม practices
• Automate end-to-end functional และ non-functional testing
• Deploy ไปยัง environment ต่างๆ ด้วยรูปแบบที่เหมาะสมเพื่อไม่ให้กระทบกับการทำงาน เช่น bluegreen, canary

Automated Testing

ทำการ automate test ในทุกระดับทั้งที่เป็น functional และ non-functional โดยเลือกใช้ tool ที่เหมาะสมในแต่ละ test case การใช้ automate test tool จะทำให้เห็นปัญหาก่อน User ประกอบด้วย

• Unit เป็นการทดสอบส่วนไดๆ ใน code โดยต้องมี coverage ในการ test ที่เหมาะสม
• Integration เป็นการทำ end to end test ประกอบด้วยการทำ API test และ UI test เพื่อ simulate การใช้งานของ User
• Security ประกอบด้วย static และ dynamic security testing เป็น simulate การโจมตี application เพื่อหาช่องโหว่ด้านความปลอดภัย (vulnerabilities)
• Performance เป็นการ load test เพื่อให้มั่นใจว่า application สามารถทำงานได้ในภาวะการณ์ต่างๆ ได้ ทั้งกรณีที่มี request และมีการส่ง data (payload) เข้ามามากกว่าปกติ

Security Testing

Web app และ Mobile application จำเป็นต้องมีการตรวจสอบความปลอดภัยมากกว่าเดิม จากการเข้าถึงของผู้ใช้งานได้ทั่วไป ดังนั้นโดยทั่วไปจึงมีการทำ hardening และ end-to-end penetration test จากหน่วยงานภายนอกก่อนที่จะขึ้น production การทำ security testing สามารถทำได้หลายวิธี โดยการทำให้เป็นส่วนหนึ่งของ agile process และ devops

• Dynamic Application Security Testing (DAST) และ Static Application Security Testing (SAST) เป็นเครื่องมือและวิธีการที่อยู่ในกระบวนการ Continuous Integration pipeline เพื่อให้มั่นใจว่าทุกขั้นตอนในการบวนการ code change build และ release จะมีการตรวจสอบ security อยู่เสมอ (shift-left security)
• สำหรับการตรวจสอบจากองค์กรภายนอก (Third-Party Penetration) สามารถทำในบางจุดที่สำคัญเพื่อให้มีความคล่องตัว ลดเวลาและค่าใช้จ่ายในการตรวจสอบความปลอดภัยของ application ได้ โดยที่ไม่เป็นการเพิ่มความเสี่ยง

Dynamic App Security Testing – DAST

สามารถใช้ OWASP ZAP เพื่อ scan application ที่ทำงานอยู่ได้ (black box testing) โดยจะทดสอบความปลอดภัยด้วย test case พื้นฐานสำหรับ web application ที่เป็นมาตรฐานคือ OWASP Top 10 Vulnerabilities

ZAP สามารถเป็นขั้นตอนหนึ่งใน Continuous Integration Pipeline เพื่อให้ scan โดยอัตโนมัติเมื่อ code change, build และ release รวมถึงรายงานช่องโหว่ด้านความปลอดภัย (vulnerabilities) ให้กับทีม developer ทราบทันที ป้องกันไม่ให้ release application ที่ไม่ปลอดภัยไปยัง production

Static App Security Testing – SAST

ใช้ SonarQube เพื่อวิเคราะห์ source code และตรวจจับ code ที่อาจจะเป็นช่องโหว่ด้านความปลอดภัยของ application โดยให้ SonarQube เป็นส่วนหนึ่งของ Continuous Integration Pipeline จะทำให้มีความมั่นใจ และป้องกัน application ที่ไม่ปลอดภัยถูกใช้บน production

Independent App Penetration Testing

กระบวนการพัฒนา software ในแบบ waterfall project ส่วนใหญ่จะใช้ องค์กรอิสระที่เชื่อถือได้เพื่อตรวจสอบช่องโหว่ด้านความปลอดภัยของ software ก่อนขึ้น production ซึ่งส่งผลกระทบกับ cost ระยะเวลา และความถี่ในการ release software ทางเลือกที่เหมาะสมที่สามารถเข้าได้กับกระบวนการ agile และ devops คือรวมวิธีการของ DAST และ SAST เข้ามาใน process ก็จะทำให้ลดจำนวนที่ต้องใช้องค์การภายนอกได้ โดยมีหลักการพิจารณาคือ

• Schedule appropriately กำหนดกรอบระยะเวลาที่ชัดเจนในการทำ penetration test หลังจากที่ทุก function มีการ implement เรียบร้อย
• Lead time กำหนดให้ penetration test ทำในรอบ sprint ทำให้สามารถแก้ไขควบคู่กับการทดสอบ เพื่อไม่ให้ส่งผลกระทบกับการ release application
• Cost สำหรับการทำ penetration test จะลดลงเมื่อมีการทำ penetration test แค่ครั้งเดียวก่อนที่จะ release application โดยที่ไม่พบช่องโหว่ด้านความปลอดภัย

OWASP Dependency-Check

เป็นการทำ Software composition analysis ด้วยการตรวจสอบข้อมูลของ File (file name, POM files, ZIP files, native libraries, .NET assemblies, package name ..) แล้วตรวจสอบกับฐานข้อมูล National Vulnerability Database – NVD เพื่อแจ้งเตือนถึงความเสี่ยงในการใช้งาน package หรือ library ใน source code ปัจจุบัน OWASP Dependency-Check สามารถใช้ร่วมกับหลายๆ tool เช่น

• Ant Task
• Command line tool – Windows, *nix
• Gradle plugin
• Jenkins plugin
• Maven plugin

Semantic Versioning

ใช้ Semantic versioning เพื่อจัดการ version ของ release สำหรับหลาย ๆ microservice และ application โดยการ tag version number ที่ release branch ที่สร้างใน git repository

version ของ release ใช้หลักการที่ง่ายเพื่อให้ผู้ใช้ microservice หรือ application เข้าใจ change ที่เกิดขึ้น รวมถึงทีม tester การจัดการ version สามารถใช้หลักการดังต่อไปนี้

• Major เป็นการเปลี่ยนแปลงที่สำคัญ หรือส่งผลกระทบต่อภายนอกเช่นการเปลี่ยนการเรียกใช้ API หรือ Interface
• Minor การแก้ไขเพิ่มเติม function ที่มีอยู่แล้ว หรือเพิ่มความสามารถของ function เดิมให้สมบูรณ์และดียึ่งขึ้น
• Patch เป็นการแก้ข้อผิดพลาดของ code (bug)
• Chore เป็นการเปลี่ยนแปลงไดๆ ที่ไม่จำเป็นต้องเปลี่ยน version เช่นการทำ code refactoring

ข้อมูลเพิ่มเติมเกี่ยวกับ semantic version ได้จาก https://semver.org

Application & Platform Monitoring

Application ที่ทำงานบน environment มีการตรวจสอบสถานะการทำงานของ application และ platform และแจ้งเตือนเมื่อมีปัญหาไดๆ เกิดขึ้นแบบ realtime ด้วยการเก็บข้อมูลในรูปแบบ matrics อาจจะใช้ Prometheus และแสดงผลใน grafana dashboard เพื่อให้ทีมสามารถเห็นการทำงานของ application ที่เป็นปัจจุบันและสถิติที่ผ่านมาได้ ขอมูลจำเป็นที่ต้องจัดเก็บเช่น

• Uptime/Downtime
• CPU memory utilization
• Failed network request 4xx 5xx response
• Latency slow running request
• Request Frequency (DDoS Protection)
• Error message logged by application
• Disk space usage

Collaboration

ช่องทางการติดต่อสือสารในทีม ทั้งที่เป็น internal และ external เป็นสิ่งสำคัญ และต้องใช้ tool ที่เหมาะสม เช่น

• Slack ทีมสามารถ share ข้อมูลเกี่ยวกับ project พวก knowledge ต่างๆ ระหว่างทีม และสามารถใช้แจ้ง alert ได้กรณีที่ pipeline มีปัญหา อีกทั้งยัง invite business หรือ stakeholder เข้ามาในทีมด้วยเพื่อการรับรู้ข่าวสารต่างๆ ภายในทีม
• Jira เป็น tool ที่ใช้ในการจัดการ product backlogs จัดการ sprint รวมถึง report ต่างๆ เพื่อให้ทีมเห็นถึง progress ในแต่ละงานได้

Cloud Platform

การทำ devops ให้สะดวกราบรื่นจำเป็นต้องมี platform ที่ช่วยอำนวยสะดวกในการ release, deploy, run และ manage application ได้ง่าย ปัจจุบันจะใช้ container technology ในการ packaging software และ run บน kubernetes environment เพราะสะดวกในการใช้งานเพราะการใช้งานจะผ่าน APIs ไม่มี manual process โดยใช้ Cloud Environment เป็น infrastructure เพื่อให้ platform สามารถ scale ได้ง่าย และ cloud environment ยังช่วยในเรื่องการจัดการ high availability , consistency และ resilent ของ application ได้ง่ายอีกด้วย