Haliviq

ปรับปรุงระบบเดิม
โดยไม่หยุดธุรกิจ

ปรับระบบเดิมให้เป็น Platform แบบ API-first, พร้อม Cloud และดูแลรักษาง่าย โดยไม่ต้องหยุดธุรกิจ

migrate.log
1> strangler --route orders-v2
2✓ Traffic 12% เข้า Service ใหม่
3 
4> diff --parity legacy vs new
5✓ ไม่พบความแตกต่าง
6 
7> cutover --module orders
8✓ ปิด Module เดิมได้ปลอดภัย
ความคืบหน้า Migrate
ไม่มี Downtime ตลอดโปรเจกต์

เราปรับปรุง Application สำคัญผ่าน Assessment, Strangler-fig Migration, Refactoring และ Re-architecture โดยตั้งใจหลีกเลี่ยงการ Rewrite แบบยาวนานที่มีความเสี่ยงสูง หมายถึงการแตก Monolith ออกเป็นส่วนย่อย นำ API และ Event-driven Pattern เข้ามาใช้ Containerize Workload และดำเนินการย้ายข้อมูลด้วยกลยุทธ์ Cutover ที่รักษารายได้ไว้ ในขณะที่ผู้ใช้ของคุณยังทำงานได้ต่อเนื่องตลอดกระบวนการ ไม่ใช่หลังจากหยุดระบบ 6 เดือน

ความสามารถ

ความสามารถหลัก

ความสามารถที่จับต้องได้จริงที่เรานำมาใช้ในทุกโปรเจกต์ ไม่ใช่แค่คำสวยหรู

Legacy Assessment

วิเคราะห์ด้านเทคนิคและธุรกิจ เพื่อตัดสินใจว่าอะไรควร Rewrite, Wrap, Replace หรือ Retain

Incremental Refactoring

ปรับปรุงโครงสร้างและ Testability ทีละส่วน พร้อมรักษา Continuous Delivery

Cloud-Native Patterns

Container, Microservices, Serverless และ Event-driven Design เมื่อมีเหตุผลรองรับ

API Modernization

สร้าง API และ Integration Layer ที่มั่นคง เปิดช่องทางใหม่โดยไม่ต้อง Rewrite ทั้งหมด

แนวทางที่เราใช้

เทคโนโลยีที่เราใช้งาน

Architecture Pattern ที่พิสูจน์แล้ว เลือกใช้ตามโจทย์งานจริง ไม่ใช่ตามกระแส

MicroservicesContainersKubernetesAPI GatewayEvent-Driven ArchitectureServerlessCQRS

วิธีการทำงาน

แนวทางการทำงานของเรา

เส้นทางที่ชัดเจนจากระบบเดิมสู่ระบบสมัยใหม่ ปรับตามแต่ละระบบ ไม่ใช่สูตรสำเร็จตายตัว

01

Assess

Code, Data และสภาพการทำงานจริง

02

Strategy

Rewrite, Refactor หรือ Replace

03

Modernize

ปรับปรุงโครงสร้างแบบค่อยเป็นค่อยไป

04

Migrate

เปลี่ยนผ่าน Platform และ Data

05

Verify

Parity, Performance และไม่มี Regression

06

Optimize

ต้นทุน Scalability และการดูแลระบบ

คำถามที่พบบ่อย

คำตอบตรงไปตรงมาเกี่ยวกับวิธีที่เราปรับปรุงระบบ

ปรับปรุงระบบเดิมโดยไม่หยุดธุรกิจได้อย่างไร?

ปรับแบบค่อยเป็นค่อยไปครับ เราใช้ Strangler Pattern โดย Service ใหม่จะเข้ามาแทนที่ทีละความสามารถผ่าน API Gateway ในขณะที่ระบบเดิมยังทำงานต่อไป ธุรกิจจึงไม่ต้องหยุดเพื่อรอ Rewrite Traffic จะค่อยๆ ย้ายไปเมื่อแต่ละส่วนใหม่พิสูจน์ตัวเองบน Production แล้ว

Haliviq ปรับระบบเดิมให้กลายเป็นอะไร?

Platform ที่ดูแลรักษาง่าย, API-first และพร้อม Cloud โดยทั่วไปคือ Service บน Container ใน Kubernetes, Event-driven เมื่อช่วยได้จริง และ Serverless เมื่อง่ายกว่า Architecture เป้าหมายจะตามทีมและ Workload ของคุณ ไม่ใช่ตามกระแส เราไม่ Default ไปที่ Microservices เพียงเพราะฟังดูทันสมัย

ระบบเดิมของเราไม่มีเอกสารเลย ยังทำงานด้วยได้ไหม?

ได้ครับ เป็นเรื่องปกติ ไม่ใช่อุปสรรค เราเริ่มจากทำแผนที่สิ่งที่ระบบทำจริงจาก Code, Data และ Traffic บน Production แล้วล็อค Behavior ปัจจุบันด้วย Test ก่อนเปลี่ยนแปลงอะไร เพื่อให้รู้ทันทีถ้าการเปลี่ยนแปลงทำให้อะไรพัง

เมื่อไหร่ควรเลือก Rewrite ทั้งหมดแทนการปรับปรุงแบบค่อยเป็นค่อยไป?

น้อยครั้งมาก และเฉพาะเมื่อต้นทุนของการเปลี่ยนแบบค่อยเป็นค่อยไปสูงกว่าการสร้างใหม่จริงๆ มักเกิดขึ้นเมื่อเทคโนโลยีเดิมไม่มีใครรองรับแล้ว หรือ Domain Model เองผิดตั้งแต่ต้น เราจะบอกตรงๆ ว่าระบบคุณอยู่ฝั่งไหนหลัง Assessment ไม่ใช่ขาย Rewrite เป็น Default

โปรเจกต์ Modernization ทั่วไปใช้เวลานานแค่ไหน?

Migrate หนึ่ง Module ด้วย Strangler Pattern มักใช้เวลา 2-4 เดือนตั้งแต่ Assessment ถึง Cutover เต็มรูปแบบ ส่วนการแตก Monolith ทั้งระบบสำหรับระบบขนาดใหญ่ แบ่งเป็น Phase ตลอด 6-18 เดือน แต่ละ Phase ส่งมอบ Software ที่ใช้งานได้จริงและความคืบหน้าที่วัดผลได้ ไม่ใช่โปรเจกต์ยาวๆ ที่ไม่มีอะไรให้เห็นจนจบ

Application Modernization มีค่าใช้จ่ายเท่าไหร่?

ต้นทุนขึ้นอยู่กับขนาดและความซับซ้อนของระบบเดิม และปริมาณที่ต้องเปลี่ยนแปลง การ Assessment แบบเจาะจงมักเริ่มต้นที่หลักหมื่นปลายๆ (บาท) ส่วนโปรแกรม Modernization แบบแบ่ง Phase จะเสนอราคาต่อ Phase หลัง Assessment นั้น เพื่อให้คุณ Validate คุณค่าก่อนตัดสินใจ Phase ถัดไป

ทีมของเราจะเป็นอย่างไรระหว่างกระบวนการ Modernization?

เราทำงานเคียงข้างทีม Engineer ของคุณ ไม่ใช่แยกทำเงียบๆ โดย Pair กับส่วนของระบบที่พวกเขาเข้าใจดีที่สุด และ Transfer Knowledge ไปตลอดทาง เมื่อถึงตอนส่งมอบ ทีมคุณจะเข้าใจ Architecture ใหม่เพราะพวกเขาช่วยสร้างมันขึ้นมา ไม่ใช่เพราะอ่านเอกสารทีหลัง

Code และ Infrastructure เป็นของใครหลังจบโปรเจกต์?

เป็นของคุณทั้งหมดครับ Service ใหม่, Infrastructure Code และเอกสารทั้งหมดอยู่ใน Repository และ Cloud Account ของคุณเองตั้งแต่วันแรก เราทำงานในสภาพแวดล้อมของคุณ จึงไม่มีระบบแยกที่ต้อง Migrate ออกจากเราตอนส่งมอบ

มีโปรเจกต์ในใจแล้วใช่ไหม?

เรายินดีรับฟังสิ่งที่คุณกำลังสร้างครับ