การเปลี่ยนผ่านสู่ดิจิทัล
ปรับปรุงระบบเดิมให้ทันสมัยทีละขั้น
โดยไม่กระทบการดำเนินธุรกิจ
ระบบเดิมเก็บกฎทางธุรกิจและข้อมูลสะสมมาหลายปี และไม่อาจปิดทิ้งได้ทันที InterCloud ปรับปรุงระบบเหล่านี้ให้ทันสมัยทีละขั้น ย้ายขึ้น AWS เชื่อมต่อกับแอปพลิเคชันอื่นในองค์กร และนำข้อมูลในระบบมาใช้ประกอบการตัดสินใจ
การปรับปรุงแอปพลิเคชันให้ทันสมัย
เปลี่ยนระบบ Monolith เดิมเป็นแพลตฟอร์มที่ดูแลรักษาได้
งานเริ่มจากการประเมิน ได้แก่ การทบทวนโค้ดและฐานข้อมูล แผนผังการพึ่งพากันของระบบ และการวิเคราะห์ว่าฟังก์ชันใดถูกใช้งาน โดยใคร และบ่อยเพียงใด ผลลัพธ์คือแผนการปรับปรุงที่จัดลำดับส่วนประกอบตามคุณค่าทางธุรกิจและความเสี่ยง เพื่อให้การเปิดตัวช่วงแรกมุ่งไปที่ส่วนที่มีคุณค่าสูงสุด
การย้ายระบบใช้รูปแบบ Strangler Fig บริการใหม่ที่พัฒนาด้วย Spring Boot และ Next.js จะรับช่วงความสามารถทีละส่วนผ่านชั้นกำหนดเส้นทาง ขณะที่ระบบเดิมยังให้บริการฟังก์ชันที่เหลือ ผู้ใช้ทำงานกับแอปพลิเคชันเดียวตลอดเวลา และไม่มีส่วนประกอบใดถูกปิดจนกว่าส่วนที่มาแทนจะพิสูจน์ตัวเองบน Production แล้ว
ในกรณีที่โค้ดยังดีอยู่และล้าสมัยเฉพาะแพลตฟอร์ม เราจะย้ายแพลตฟอร์ม (Re-platform) แทน โดยนำแอปพลิเคชันขึ้น Container และย้ายไปยัง AWS ECS เปลี่ยน Middleware เฉพาะผู้ผลิต และปรับฐานข้อมูลเป็น PostgreSQL เวอร์ชันที่ยังได้รับการสนับสนุน
- การประเมินพร้อมแผนการปรับปรุงที่จัดลำดับความสำคัญ
- การย้ายระบบแบบ Strangler Fig ผ่าน API Gateway หรือ Reverse Proxy
- การย้ายแอปพลิเคชัน Java EE และแอปพลิเคชัน JVM อื่น ๆ ไปสู่ Spring Boot และ Container
- การย้ายข้อมูลพร้อมรายงานกระทบยอดในทุกการสลับระบบ
การย้ายระบบขึ้น Cloud
ย้ายขึ้น AWS เป็นระลอก โดยแต่ละระลอกมีแผนย้อนกลับ
การย้ายระบบเป็นมากกว่าการคัดลอกเซิร์ฟเวอร์ เราวางโครงสร้างบัญชี เครือข่าย และความปลอดภัยก่อน แล้วจึงย้าย Workload เป็นระลอก โดยแต่ละระลอกมีแผนย้อนกลับของตนเอง
เริ่มจาก Landing Zone
เริ่มจากโครงสร้างบัญชีที่ตรงกับข้อกำหนดด้านเครือข่ายและการปฏิบัติตามข้อกำหนดของคุณ ได้แก่ AWS Organizations ที่แยกบัญชีสำหรับ Production และ Non-production การรวมศูนย์ Log, IAM Role แทนการใช้คีย์ร่วมกัน และการออกแบบ VPC ที่เหมาะสม การตั้งค่าทั้งหมดกำหนดใน Terraform ผ่านการตรวจทาน และมีการจัดการเวอร์ชัน
ระลอกการย้ายระบบ
การหยุดให้บริการอยู่ภายในช่วงเวลาที่ตกลงกัน Workload ถูกจัดกลุ่มตามการพึ่งพากันและย้ายเป็นระลอก เริ่มจากส่วนที่สำคัญน้อยที่สุด แต่ละระลอกมีแผนการทดสอบ ช่วงเวลาสลับระบบ และขั้นตอนย้อนกลับ ฐานข้อมูลย้ายด้วยการทำสำเนาข้อมูล (Replication)
ปลายทางที่เหมาะสมสำหรับแต่ละ Workload
บริการของแอปพลิเคชันทำงานใน Container บน ECS ฐานข้อมูลบน PostgreSQL แบบ Managed และงานที่ขับเคลื่อนด้วยเหตุการณ์บนฟังก์ชัน Serverless การย้ายแบบ Lift-and-shift ใช้เฉพาะเมื่อการเขียนใหม่ยังไม่คุ้มค่า และมีการบันทึกเหตุผลของแต่ละทางเลือกไว้
ความปลอดภัยในทุกระลอก
ข้อมูลของคุณได้รับการปกป้องระหว่างการย้าย การเข้ารหัสข้อมูลทั้งขณะจัดเก็บและขณะส่งผ่าน การเก็บข้อมูลลับในที่จัดเก็บแบบ Managed, Role ที่ให้สิทธิ์น้อยที่สุด และ Cloudflare ที่ Edge สำหรับ TLS, WAF และการป้องกัน DDoS ใช้ในทุกระลอก และมีการทบทวนความปลอดภัยเป็นส่วนหนึ่งของแต่ละระลอก
มองเห็นต้นทุนได้ชัดเจน
ทุกสภาพแวดล้อมและทุกทีมเห็นค่าใช้จ่ายของตนตั้งแต่เริ่มต้น ผ่านมาตรฐานการติดแท็กและงบประมาณ หลังการย้ายระบบ จะทบทวนการปรับขนาดทรัพยากรและการจองความจุล่วงหน้าเมื่อทราบปริมาณการใช้งานจริงแล้ว
ส่งมอบให้ทีมของคุณหรือใช้บริการดูแลระบบ
ทีมของคุณจะได้รับโค้ด Terraform คู่มือปฏิบัติงาน และการฝึกอบรมที่จำเป็นในการดูแลสภาพแวดล้อม หรือ InterCloud ดูแลต่อภายใต้ข้อตกลงบริการดูแลระบบ
การเชื่อมต่อระบบ
การเชื่อมต่อที่ทดแทนการคีย์ข้อมูลซ้ำระหว่างระบบ
องค์กรใช้ทั้ง ERP, HR, CRM อีคอมเมิร์ซ และเครื่องมือของแต่ละแผนกอีกมาก และพนักงานมักต้องคีย์ข้อมูลซ้ำระหว่างระบบเหล่านี้ เราทดแทนการโอนข้อมูลด้วยมือด้วยการเชื่อมต่อที่มีเอกสารกำกับ มีการมอนิเตอร์ และองค์กรของคุณเป็นเจ้าของ
ความต้องการแบบ Synchronous ใช้ REST API ที่อธิบายด้วย OpenAPI ส่วนลำดับงานแบบ Asynchronous ใช้เหตุการณ์และคิว เพื่อไม่ให้ระบบที่ช้าหรือใช้งานไม่ได้ขัดขวางระบบอื่น บริการ SOAP เดิม การโอนไฟล์ และการเชื่อมต่อฐานข้อมูล จะถูกห่อด้วย Adapter เพื่อให้ระบบอื่นทั้งหมดทำงานผ่านอินเทอร์เฟซเดียวที่สอดคล้องกัน
การเชื่อมต่อทุกรายการบันทึกว่าโอนข้อมูลใดและเมื่อใด ลองใหม่ได้อย่างปลอดภัย และแจ้งเตือนเมื่อล้มเหลว การกระทบยอดจึงกลายเป็นขั้นตอนเฉพาะกรณียกเว้น แทนที่จะเป็นงานประจำเดือน
- ข้อตกลง REST และ OpenAPI ที่มีการจัดการเวอร์ชันและเผยแพร่ให้ทีมของคุณ
- การเชื่อมต่อแบบขับเคลื่อนด้วยเหตุการณ์ พร้อมคิวและ Consumer แบบ Idempotent
- Adapter สำหรับ SOAP, SFTP, Flat File และอินเทอร์เฟซฐานข้อมูลโดยตรง
- การเชื่อมต่อกับ GlowScale, Orbio และระบบ ERP, CRM และระบบชำระเงินของผู้ให้บริการรายอื่น
ข้อมูลและการวิเคราะห์
รายงานที่เชื่อถือได้สำหรับการตัดสินใจของผู้บริหาร
โครงการด้านรายงานมักล้มเหลวเพราะคุณภาพข้อมูลและจังหวะเวลา เราจึงสร้าง Pipeline และนิยามข้อมูลก่อน แล้วจึงสร้างแดชบอร์ดตามมา
คลังข้อมูล (Data Warehouse)
เปรียบเทียบแนวโน้มตามช่วงเวลาจากแหล่งจัดเก็บกลางแห่งเดียว คลังข้อมูลทำงานบน PostgreSQL หรือบริการวิเคราะห์ข้อมูลของ AWS และรับข้อมูลจากแอปพลิเคชันของคุณผ่าน Pipeline ที่ทำงานตามกำหนดเวลาและตามเหตุการณ์ โดยเก็บประวัติข้อมูลไว้
นิยามข้อมูลร่วมกัน
ฝ่ายการเงินและฝ่ายปฏิบัติการใช้ตัวเลขชุดเดียวกัน ตัวชี้วัดแต่ละตัว เช่น รายได้ สินค้าคงเหลือ หรือรอบเวลาดำเนินงาน มีนิยามเดียวที่ตกลงร่วมกัน จัดทำเป็นเอกสาร และใช้ในทุกรายงาน
แดชบอร์ดและรายงาน
แต่ละบทบาทเห็นตัวเลขที่ตนต้องใช้ ด้วยแดชบอร์ดตามบทบาทสำหรับผู้บริหารระดับสูง ผู้จัดการ และพนักงานปฏิบัติการ รายงานที่ส่งทางอีเมลตามกำหนดเวลา และการส่งออกข้อมูลเพื่อวิเคราะห์ต่อในสเปรดชีต
พร้อมสำหรับ AI
ผู้ช่วย AI และการพยากรณ์ต้องอาศัยข้อมูลที่สะอาดและมีการกำกับดูแล คลังข้อมูลเดียวกันนี้ป้อนข้อมูลให้ InterCloud AI และโมเดลต่าง ๆ ที่อธิบายไว้ในหัวข้อโซลูชันด้าน AI และข้อมูล
แผนงาน
แผนงานการเปลี่ยนผ่านโดยทั่วไป
ในทางปฏิบัติ ขั้นตอนต่าง ๆ ซ้อนทับกัน ลำดับด้านล่างสะท้อนสิ่งที่ต้องมีก่อน จึงจะดำเนินขั้นตอนถัดไปได้อย่างปลอดภัย
- 1
ประเมินและจัดลำดับความสำคัญ
จัดทำบัญชีรายการแอปพลิเคชัน ข้อมูล และการเชื่อมต่อ สัมภาษณ์เจ้าของกระบวนการทางธุรกิจ และจัดทำแผนงานที่ระบุการปรับปรุงระยะสั้น งานรากฐาน และการเปลี่ยนระบบในระยะยาว
- 2
สร้างรากฐาน
วาง AWS Landing Zone, CI/CD Pipeline การมอนิเตอร์ และ API Gateway ส่วนประกอบเหล่านี้ใช้ร่วมกันในทุกงานที่ตามมา และมักเป็นผลงานแรกที่เห็นได้ชัด
- 3
ย้ายและปรับปรุงให้ทันสมัยเป็นระลอก
ย้าย Workload ขึ้น AWS เปลี่ยนส่วนประกอบเดิมทีละความสามารถ และเชื่อมต่อระบบต่าง ๆ ผ่านอินเทอร์เฟซที่มีเอกสารกำกับ แต่ละระลอกจบลงเมื่อผู้ใช้ทำงานบนเวอร์ชันใหม่
- 4
รวมศูนย์ข้อมูล
ส่งมอบ Pipeline เข้าสู่คลังข้อมูล นิยามข้อมูลที่ตกลงร่วมกัน และแดชบอร์ดชุดแรก ปัญหาคุณภาพข้อมูลที่พบในขั้นตอนนี้จะถูกเพิ่มเข้าในรายการงานของแอปพลิเคชัน
- 5
ดูแลและปรับปรุง
สภาพแวดล้อมเข้าสู่บริการดูแลระบบ หรือส่งมอบให้ทีมของคุณ พร้อมการทบทวนรายไตรมาสว่าจะปรับปรุง ปลดระวาง หรือทำให้เป็นอัตโนมัติในส่วนใดต่อไป
รู้ความเสี่ยงและต้นทุนก่อนตัดสินใจ
การประเมินเพื่อปรับปรุงระบบให้ทันสมัยให้แผนงานที่จัดลำดับความสำคัญ และภาพความเสี่ยงและต้นทุนที่ชัดเจน ก่อนที่องค์กรของคุณจะตัดสินใจดำเนินโครงการเต็มรูปแบบ