เหตุใด Atlassian จึงใช้ PaaS ภายในเพื่อจัดการการเข้าถึง AWS ของพนักงาน

 (blog.developer.atlassian.com)
9 คะแนน โดย xguru 2019-08-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

มีบริการมากกว่า 1,000 รายการที่โฮสต์อยู่ผ่าน PaaS ที่ชื่อว่า Micros

ครอบคลุมตั้งแต่โค้ดที่สร้างขึ้นในแฮกกาธอน ไปจนถึงผลิตภัณฑ์เรือธงที่ใช้งานจริง

แม้จะเป็นบริการที่สำคัญมาก แต่โครงสร้างจริง ๆ กลับเรียบง่าย

  • Docker image : ลอจิกของบริการ

  • YAML ที่บรรยายบริการ

== กำหนดทรัพยากรที่ต้องใช้ เช่น DB, คิว, แคช เป็นต้น

== การตั้งค่าต่าง ๆ เช่นคุณสมบัติด้าน autoscaling

งานที่เหลือทั้งหมด Micros จะเป็นผู้จัดการ

= Log Aggregation, Monitoring, Alert

= Multi-AZ, การตั้งค่าแบ็กอัป/กู้คืน/การเก็บรักษาข้อมูล เป็นต้น

ส่วนที่พัฒนาขึ้นเองมีไม่มากนัก และส่วนใหญ่ใช้ความสามารถของ AWS

** เหตุผลที่สร้าง PaaS แบบนี้

  • การผสานเข้ากับเครื่องมือและกระบวนการมาตรฐานภายในองค์กรทำให้การพัฒนาง่ายขึ้น

  • การเปลี่ยนแปลงที่ต้องนำไปใช้กับบริการในวงกว้างทำได้ง่ายขึ้นและคาดการณ์ได้มากขึ้น

  • ความเชี่ยวชาญเฉพาะทางของวิศวกรจำนวนน้อยถูกขยายผลได้หลายเท่า (multiplied)

    ( ภายในองค์กรอาจมีผู้เชี่ยวชาญ PostgreSQL ไม่มาก แต่ถ้านำไปใช้กับ Micros ก็ทำให้ทั้งบริษัทได้ประโยชน์ )

  • ความพยายามเล็ก ๆ ในการปรับปรุงแพลตฟอร์มสามารถส่งผลต่อทั้งบริษัทได้

  • ฟีเจอร์ใหม่ของ AWS ก็สามารถค่อย ๆ เพิ่มเข้ามาได้ โดยยังคงรักษาความปลอดภัยและข้อกำหนดเดิมไว้

แน่นอนว่าวิธีนี้ไม่ได้มีแต่ข้อดีเสมอไป บางครั้งก็ทำให้ทดลองฟังก์ชันใหม่ของ AWS ได้ยาก และบางครั้งเครื่องมือ 3rd party อื่น ๆ ก็อาจเชื่อมต่อกับ Micros ไม่ได้ ดังนั้นจึงได้สร้างกระบวนการภายในสำหรับเพิ่มความสามารถใหม่ให้กับ PaaS นี้ไว้

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
xguru 2019-08-16

บทความยาวมาก เลยคัดมาลงไว้แค่บางส่วน

ถ้าคุณกำลังดูแล AWS ในองค์กรที่ค่อนข้างใหญ่ แนะนำให้ค่อยๆ อ่านดูครับ

เท่าที่ทราบ เมื่อก่อน KTH กับ Daum ก็เคยทำคล้ายๆ กัน โดยสร้างคลาวด์ภายใน (ถ้าจำไม่ผิดน่าจะเป็น OpenStack) ขึ้นมาใช้

วิธีเอามาครอบบางๆ ไว้บน AWS แบบนี้ก็ดูเป็นแนวทางที่ดีเหมือนกันครับ