Griffin - ธนาคารที่มีการกำกับดูแลเต็มรูปแบบ สร้างด้วย Clojure และให้บริการผ่าน API

 (juxt.pro)
2 คะแนน โดย GN⁺ 2023-08-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นแพลตฟอร์ม banking-as-a-service ที่ช่วยให้ฟินเทคเชื่อมต่อการเปิดบัญชี การชำระเงิน และการ onboarding ได้โดยตรงเหมือนใช้ API ของธนาคาร และในเดือนมีนาคม 2023 ได้รับใบอนุญาตธนาคารในสหราชอาณาจักรจนกลายเป็นธนาคารที่อยู่ภายใต้การกำกับดูแล
  • ระบบทำงานบน Clojure on Kubernetes on AWS และผสานสถาปัตยกรรม event sourcing ที่แปลงอินพุตส่วนใหญ่ให้เป็น event เข้ากับ storage อย่าง FoundationDB
  • FoundationDB เป็น strict-serializable key-value store ที่รองรับ transaction และการเขียนพร้อมกัน โดย Griffin สร้างเลเยอร์คล้าย Datomic ด้วยการพอร์ต Datascript เพื่อจัดการการอ่าน/เขียนแบบ atomic
  • แยก business logic โดยยึด log processor ขนาดเล็กเป็นศูนย์กลาง ซึ่งรับ Clojure map แล้วส่งออก Clojure map และจำกัดการเข้าถึงระบบภายนอกผ่าน protocol กับ proc เฉพาะทาง
  • มองว่า immutability ของ Clojure และความเป็นมิตรต่อ audit log เหมาะกับข้อกำหนดของบริการการเงิน และเมื่อผสานกับการจ้างงานแบบ remote ก็ช่วยให้หาวิศวกรคุณภาพสูงได้ง่ายขึ้นแม้กลุ่มผู้สมัครจะเล็ก

แพลตฟอร์มธนาคารที่มีการกำกับดูแล ให้บริการผ่าน API

  • Griffin เป็นแพลตฟอร์ม banking-as-a-service ที่ช่วยให้บริษัทฟินเทคผสาน ฟังก์ชันธนาคาร ได้อย่างรวดเร็วและปลอดภัย
  • ในเดือนมีนาคม 2023 ได้รับ UK banking license จาก Financial Conduct Authority และกลายเป็นธนาคารสหราชอาณาจักรที่อยู่ภายใต้การกำกับดูแลอย่างเต็มรูปแบบ
  • Griffin เรียกตัวเองว่า “the bank you can build on” และตั้งเป้าเป็นโครงสร้างพื้นฐานแบบ AWS สำหรับงานธนาคาร
    • API สำหรับ onboarding ลูกค้า
    • API สำหรับสร้างบัญชีธนาคาร
    • API สำหรับการชำระเงิน
  • หากฟินเทคต้องการให้บริการฟังก์ชันเหล่านี้ ตามกฎหมายต้องร่วมมือกับธนาคาร และปัจจุบันมักทำงานกับ high street bank เดิมที่ใช้เมนเฟรม
  • Griffin ต้องการมอบทั้งใบอนุญาตธนาคารและแพลตฟอร์มเทคโนโลยี เพื่อเป็นฐานให้ฟินเทคในอนาคตสร้างบริการบนแพลตฟอร์มนี้
  • แม้ได้รับใบอนุญาตแล้ว แต่ในเวลานั้นยังอยู่ในระยะ mobilization และระยะนี้จะสิ้นสุดหลังการ audit เสร็จสิ้น ระดมทุนเพิ่มเติม และเขียนโค้ดเสร็จ
    • ช่วงเวลาที่ตั้งเป้าไว้คือ Q3 หรือ Q4 ของปีนั้น

เหตุผลที่เลือก Clojure

  • Clojure ถูกเลือกเป็นภาษาของแพลตฟอร์มเพราะ immutability, ความสามารถในการสื่อความหมาย และความเหมาะสมกับบริการการเงินที่ต้องการ audit log
  • Allen Rohner ได้ชมการนำเสนอ Clojure ของ Rich Hickey ราวปี 2007 และตัดสินว่าดีกว่า Lisp ที่ตนกำลังสร้างอยู่
  • หลังจากก่อตั้ง CircleCI ในปี 2011 ก็ใช้ Clojure มาเป็นเวลานาน และเห็นว่ามันทำงานได้ดีใน CircleCI อีกทั้งยังเหมาะกับบริการการเงิน
  • สำหรับ JVM ในช่วงไม่กี่ปีแรกยังไม่ได้ตระหนักถึงข้อดีอย่างเต็มที่ แต่ภายหลังเปลี่ยนมาประเมินว่าเป็นข้อได้เปรียบอย่างมาก
    • niche startup language อื่นอาจเจอปัญหาขาดแคลนไลบรารี หรือปัญหาประสิทธิภาพของ compiler/runtime
    • JVM เป็นฐานที่ช่วยลดความเสี่ยงเหล่านี้
  • การเลือกภาษาแสดงให้เห็นตัวตนของบริษัท และมองว่า Clojure เป็นตัวเลือกที่ทรงพลังกว่า Python หรือ Java
  • มองว่าการใช้ niche language แม้จะทำให้จำนวนผู้สมัครลดลง แต่สัดส่วนของ ผู้มีความสามารถระดับสูง อาจเพิ่มขึ้น

เลเยอร์ข้อมูลที่สร้างด้วย FoundationDB

  • สถาปัตยกรรมของ Griffin ทำงานบน Clojure, Kubernetes และ AWS โดยเกือบทั้งหมดประกอบด้วย event sourcing
  • ฐานข้อมูลใช้ FoundationDB
  • FoundationDB เป็น strict-serializable key-value store ที่รองรับ transaction
    • เริ่มต้นจากสตาร์ทอัปใน Silicon Valley
    • ถูก Apple ซื้อกิจการในปี 2015
    • ราวปี 2018 Apple เปิดเป็นโอเพนซอร์สอีกครั้ง
    • Apple ใช้ใน production ของ iCloud
  • Apple เคยทำ benchmark ที่ FoundationDB ทำงานได้ประมาณ 1 ล้าน transaction ต่อวินาที
  • strict serializable ถือเป็น ระดับสูงสุด ในด้าน consistency ของฐานข้อมูล
  • API พื้นฐานใกล้เคียงกับ get a key, set a key และไม่ใช่ SQL
  • Griffin พอร์ต Datascript ไปยัง FoundationDB เพื่อสร้าง เลเยอร์คล้าย Datomic
    • ทำให้ query แบบ atomic ได้บน data store แบบ strict-serializable
    • รองรับการอ่านและเขียนแบบ transaction
  • FoundationDB ไม่ใช่ single writer แต่รองรับ concurrent writes
  • Griffin ต้องการมากกว่า 1,000 transaction ต่อวินาที และกำลังตอบโจทย์ข้อกำหนดนี้ได้

Event sourcing และ log processor

  • อินพุตทั้งหมดของระบบ Griffin จะกลายเป็น event
    • API request
    • webhook จาก third-party
  • event จะเข้าไปใน message log และใน Griffin event คือ Clojure map ที่มีฟิลด์ type, key/value และ spec
  • ระบบทั้งหมดประกอบขึ้นจากการตอบสนองต่อ event
  • log processor ขนาดเล็กเรียกว่า proc
    • proc ทำงานในลักษณะ “ฟัง message type A แล้วตอบสนองด้วยการ emit B หรือ C”
    • แต่ละ proc มี private state ของตัวเอง
  • message flow สามารถจัดเป็นกราฟได้ และ event จะเคลื่อนที่ไปจนถึง terminal node
  • ตัวอย่างเช่น web server รับ HTTP event แล้วบันทึกคำขอชำระเงิน จากนั้นรอ event payment created หรือ payment rejected ก่อนตอบกลับ client
    • flow นี้ใช้ Netty asynchronous HTTP handler
  • event ทั้งหมดถูกบันทึกลง FoundationDB
    • log processor แต่ละตัวมี private data คล้าย namespace ของตัวเองใน FoundationDB
    • proc เฝ้าดูการบันทึก event type เฉพาะ และบันทึก event ของตัวเองกลับลง FoundationDB
  • FoundationDB มีความสามารถในการเฝ้าดูการเปลี่ยนแปลงของ DB key จึงสามารถสร้าง reactive system ได้อย่างมีประสิทธิภาพ
  • หากใช้ฐานข้อมูลร่วมกับระบบ messaging แยกต่างหาก อาจเกิด race condition ได้
    • เช่น ในสถานการณ์ที่ message หนึ่งไปยังดิสก์ อีก message หนึ่งไปยังเครือข่าย ผู้สังเกตการณ์อาจเห็นทั้งสองในลำดับที่ต่างกัน
    • Griffin ใช้วิธีบันทึกลง FoundationDB เพื่อทำให้เหลือเส้นทางเดียวและเรียบง่ายขึ้น

Monorepo และการแยก business logic

  • Griffin ใช้ monorepo
  • ปัจจุบันมี log process จำนวนมากรันอยู่ใน JVM เดียวกันเพื่อประสิทธิภาพ
    • แต่ละตัวเป็นอิสระ จึงสามารถรันเป็น JVM process แยกได้เช่นกัน
    • ปัจจุบันรัน proc จำนวนหลักร้อยต้น ๆ ใน JVM เดียว
  • รักษา business logic ให้เรียบง่ายและสะอาดที่สุดเท่าที่ทำได้
    • namespace ของ log processor แต่ละตัวเกือบทั้งหมดเป็น pure Clojure
    • แทบไม่มีไลบรารี third-party
    • side effect ก็มีน้อยมาก
  • log processor ใกล้เคียงกับฟังก์ชันที่รับ Clojure map เป็นอินพุต แล้วคืน Clojure map หนึ่งรายการหรือมากกว่า
  • proc state มี protocol ทำให้ไม่ต้องรู้ implementation อีกฝั่ง
    • ใช้เป็น in-memory database ตอนทดสอบได้
    • ใช้ FoundationDB ตอนรันจริงได้
  • interface กับโลกภายนอกถูกทำให้เล็กที่สุดเท่าที่เป็นไปได้
  • proc ส่วนใหญ่ทำได้เพียงเขียนลง internal state ของตนเองและ emit message
    • เรียก network ไม่ได้
    • เรียก AWS ไม่ได้
    • ไม่มีการกระทำภายนอกอื่น ๆ
  • เมื่อต้องสื่อสารกับระบบภายนอก จะมี proc พิเศษที่มี dispatch handler เฉพาะ
    • proc ที่สื่อสารกับ AWS
    • proc ที่สื่อสารกับ clearing bank
    • proc ที่สื่อสารกับ API อื่น

ระบบนิเวศ Clojure ที่ใช้

  • ภายใน business logic แทบไม่ใช้ไลบรารี
  • ในส่วนที่สัมผัสกับโลกภายนอก เช่น API web server หรือ service gateway ใช้สิ่งต่อไปนี้
    • ring
    • netty
    • reitit
  • ใช้ Clojure spec อย่างกว้างขวาง
  • การเชื่อมต่อ AWS ใช้ไลบรารี Cognitect aws-api
  • การจัดการ configuration และ resource ของแอปพลิเคชันใช้แนวทางจากบทความบล็อก closeable
    • เป็นแนวทางที่มองว่า with-open เพียงพอโดยไม่ต้องใช้ Component หรือ Integrant
    • ได้ lexical scope และลำดับการประกาศ binding จะบังคับลำดับการประกอบ configuration
    • ใช้ helper ขนาดเล็กเพื่อประกาศ state object ที่ไม่ได้ implement Closeable หรือ stateless object ภายในบล็อก with-open

การจ้างงานและการจัดทีม

  • Griffin มองว่าการจ้างงาน Clojure มีจำนวนผู้สมัครน้อยกว่า แต่สัดส่วนผู้สมัครที่ดีสูงกว่า
    • การจ้าง Java แม้มี CV เข้ามา 1,000 ฉบับ ก็อาจมีผู้สมัครที่ดี 10 คน
    • ส่วนการจ้าง Clojure แม้มี CV เข้ามา 13 ฉบับ ก็อาจมีผู้สมัครที่ดี 10 คน ตามคำอธิบายของพวกเขา
  • สำหรับ candidate pool ขนาดเล็ก การทำงานระยะไกล มีความสำคัญ
    • เมื่อลดข้อจำกัดด้านพื้นที่ ก็สามารถสร้าง pool ที่ใหญ่ขึ้นได้ เช่น ทั่วโลก ภายใน 3 time zone หรือในยุโรป
  • มองว่าสถานการณ์ที่ต้องจ้างวิศวกร 100 คนในระยะเวลาสั้นเป็น anti-pattern
  • จำนวนพนักงานทั้งบริษัทอยู่ที่ประมาณ 70 คน
  • ฝ่าย Engineering มีประมาณ 22–24 คน
    • ประมาณสองในสามอยู่ใน UK
    • ประมาณหนึ่งในสามอยู่ใน EU
    • มีระดับประมาณเยอรมนี 4 คน สวีเดน 4 คน ไอร์แลนด์ 1 คน
    • สำนักงานใหญ่อยู่ที่ลอนดอน แต่นักพัฒนาส่วนใหญ่ใน UK อยู่นอกลอนดอน

การทดสอบ operational resilience ระดับธนาคาร

  • ในฐานะธนาคาร Griffin ต้องมี operationally resilient และมองว่านี่ใกล้เคียงกับข้อกำหนดที่ต้องไม่มี downtime
  • เพราะเกี่ยวข้องกับเงิน จึงต้องพิสูจน์ให้ได้จริงว่าแม้เกิดปัญหาก็จะไม่สูญเสียเงินของลูกค้า
  • แนวทางการทดสอบที่สนใจคล้ายกับวิธีของทีม FoundationDB
    • ทีม FoundationDB สร้าง simulator ของฐานข้อมูล
    • เขียน process type หรือบทบาทภายใน cluster ประมาณ 20 แบบเป็นแอป C++ แบบ single-threaded
    • สร้าง actor-model concurrency compiler บน C++
    • ทำให้ system call และ network call ทั้งหมดผ่าน protocol เพื่อให้สามารถ inject error ได้
    • multi-threading ก็จัดการผ่าน actor model ที่อิง message sending
  • ใน environment นี้สามารถ inject error ได้แบบ deterministic
    • ส่ง message A และ B แต่ปลายทางได้รับเป็นลำดับ B, A
    • เกิดข้อผิดพลาดในการเขียนดิสก์ระหว่างประมวลผล message
  • สิ่งนี้คล้ายกับ generative testing ของ test.check โดยมองว่า nondeterminism ทั้งหมดของระบบถูก seed จาก random number เดียวที่ควบคุมได้
  • สิ่งที่ต้องการควบคุมคือ disk errors, network errors และ message reordering
  • ปัญหาปัจจุบันคือไม่มีวิธีควบคุมพฤติกรรมของ Java threading libraries, NIO และ disk write
  • มีจิตวิญญาณร่วมกับ Jepsen แต่มีความต่าง
    • Jepsen ถูกมองว่าใกล้กับ brute force เช่น ใช้ VM หลายตัวแล้ว kill process
    • ตรวจสอบสถานะฐานข้อมูลจากภายในได้ยาก จึงรู้ coverage ได้ยาก
    • ใน environment ที่ควบคุมได้ทั้งหมด สามารถ enumerate system call หรือ message interleaving ได้ และเพราะเป็น in-memory จึงตรวจสอบได้เร็วมาก
  • ทีม FoundationDB สร้าง environment สำหรับทดสอบแบบนี้ตั้งแต่ช่วงแรก และนี่เป็นปัจจัยที่ช่วยสร้างความเชื่อมั่นต่อ FoundationDB
  • Griffin กำลังเปิดรับสมัครงาน และดูข้อมูลได้ที่ Griffin careers page

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

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

 
GN⁺ 2023-08-30
ความคิดเห็นจาก Hacker News

  • James Trunk ซึ่งเป็น VP of Engineering คนปัจจุบันของ Griffin เคยนำเสนอ บทนำเทคโนโลยี Clojure ที่ชัดเจนและสนุกที่สุดเท่าที่ผมเคยเห็นมา แนะนำเลย
    https://youtu.be/C-kF25fWTO8?si=PnjMNLdBLJ8zqSu-

  • ปัญหาตอนนี้คือเราไม่มีวิธีควบคุมไลบรารีเธรดของ Java, NIO และพฤติกรรมการเขียนลงดิสก์ที่เป็นฐานอยู่ และด้วยลักษณะของระบบแบบนั้น ก็ดูเหมือนว่าในอนาคตก็คงทำไม่ได้อยู่ดี
    ระบบที่ใช้ลำดับคำขอหรือการจัดตารางงานแบบไม่กำหนดแน่นอน จะไม่สามารถได้ การรันแบบกำหนดแน่นอน ได้ การใช้ OS thread หลายตัวเสมอ หรือการเปิดโปรเซสแยกหลายตัวในการทดสอบ ก็ทำให้เกิดสถานการณ์แบบนั้น
    อาจฝืนทำให้กำหนดแน่นอนได้ แต่ยากมาก เพราะต้องฝัง จุดซิงโครไนซ์ ที่การทดสอบควบคุมได้ไว้ในทุก transition ของ state machine ของแอปพลิเคชัน
    ในทางปฏิบัติ ดูเหมือนมีทางเดียวคือออกแบบแกนหลักของระบบให้เป็นแบบ synchronous ทั้งหมด แล้วค่อยเพิ่ม concurrency ในเลเยอร์ที่สูงกว่า ณ ตอนรัน

    • ถึงจะยากแต่ก็เป็นไปได้ สิ่งสำคัญที่สุดคือการลดพื้นที่ผิวของแอปพลิเคชันลง business logic ของเราแทบทั้งหมดเป็น pure function และ procs ไม่มี side effect ยกเว้นสิ่งที่เกิดขึ้นอีกฝั่งของ Clojure protocol (Java interface)
      ดังนั้นระหว่างทดสอบ เราสามารถแทนที่ side effect ทั้งหมดด้วย stub ได้ โค้ด “ผู้ใช้” ของเราเข้าถึงไลบรารีเธรดไม่ได้ และการทำเธรดเกิดขึ้นในโค้ด “kernel”
      ตัวอย่างที่ดีซึ่งนำแนวทางนี้ไปใช้จริงแล้วดูได้ที่ https://www.youtube.com/watch?v=4fFDFbi3toc
    • ผมจะไม่บอกว่าทำไม่ได้เด็ดขาด ผมคิดว่าอาจเป็นไปได้ถ้าปรับ missionary ซึ่งเป็น DSL สำหรับ structured concurrency และใช้ implement การกำกับดูแลโปรเซสสำหรับ Clojure/ClojureScript
      ตอนนี้ก็มีการ instrument flow ของ missionary และตรวจสอบ state transition เพื่อทดสอบ missionary เองอยู่แล้ว

  • ค่อนข้างเจ๋งที่ผู้ก่อตั้งสองคนร่วมกันเขียนหนังสือชื่อ Learning ClojureScript
    https://www.packtpub.com/product/learning-clojurescript/9781...

    • เห็นว่าผู้เขียนคนที่สามของหนังสือคือ Allen Rohner เคยทำงานด้วยกันที่ Compass Labs เขาเป็นนักพัฒนาที่มีพรสวรรค์มาก ๆ และเขายังก่อตั้ง CircleCI ด้วย

  • ประโยคที่ว่า “เรามักล้อกันว่าเราเป็นบริษัทเทคโนโลยีที่มีใบอนุญาตธนาคาร” เป็นคำพูดที่ในภายหลังอาจดูแย่มากถ้ามีอะไรผิดพลาด

    • ผมคงไม่ใช้ธนาคารที่มีทัศนคติแบบนี้ ป้ายชื่อว่าเป็น บริษัทเทคโนโลยี มักมาพร้อมความหยิ่งที่ไม่สมเหตุสมผล คือหลงคิดว่าทำทุกอย่างได้ดีเพียงเพราะเขียนโค้ดได้
      นายจ้างของผมเรียกตัวเองว่าเป็นบริษัทวิจัยด้านการศึกษาที่ทำให้ผลงานวิจัยกลายเป็นธุรกิจด้วยซอฟต์แวร์ ซึ่งสำหรับผมฟังดูสมเหตุสมผลกว่ามาก และยังทำให้วัฒนธรรมดีขึ้นด้วย
    • สิ่งหนึ่งที่ได้เรียนรู้จากฟินเทคคือ แม้ โค้ด COBOL ที่ธนาคารใช้อยู่จะเก่าและดูแลรักษายาก แต่ก็มีความรู้มีค่าจำนวนไม่น้อยที่ถ้าสร้างใหม่จะต้องเรียนรู้กันใหม่
      ในธุรกิจธนาคาร ต้นทุนของการเรียนรู้ความรู้เหล่านั้นใหม่อาจแพงมาก

  • ถามจริง ๆ และขอโทษที่พูดแรง แต่ทำไมผมต้องสนใจว่าบริการที่ผมใช้เขียนด้วยภาษาอะไร? ทำไมการที่มันเขียนด้วย Clojure ถึงสำคัญ? ในฐานะนักพัฒนา Clojure โดยอาชีพ การได้เห็นของแบบนี้เขียนด้วย Clojure ก็เจ๋งดี แต่ผมไม่เข้าใจว่าทำไมผมต้องสนใจเรื่องนั้น
    นี่เป็นหนึ่งในส่วนที่ผมไม่ชอบจริง ๆ ในชุมชนนี้ Clojure เป็นภาษาที่ทรงพลังและผมก็ใช้มันอย่างสนุก แต่ในชุมชนเหมือนมี impostor syndrome บางอย่าง ที่ต้องคอยบอกและอธิบายให้คนอื่นยอมรับว่ามีโปรเจกต์ไหนใช้ภาษานี้ ซึ่งรู้สึกแปลก

    • นี่คือบล็อกโพสต์ที่บริษัท Clojure สัมภาษณ์บริษัท Clojure อีกแห่งโดยโฟกัสที่ tech stack บทความแบบนี้ไม่ใช่เรื่องหายากใน ecosystem ของภาษาใด ๆ และแน่นอนว่าเขียนและอ่านโดยคนที่สนใจเทคโนโลยีนั้น
      ผมไม่ค่อยเข้าใจประเด็น นี่ถือเป็นพฤติกรรมที่ไม่เหมาะสมในสังคมศิวิไลซ์หรืออย่างไร?
      ฟังดูค่อนข้างไม่รู้เรื่องนะ ถ้า “ไม่สนใจ” ก็ไม่จำเป็นต้องเข้าไปยุ่ง และปล่อยให้ผู้เขียนเขียนสิ่งที่เขาอยากเขียนไป
    • โดยปกติเรื่องแบบนี้จะสำคัญที่สุดกับภาษาที่ยังไม่ได้รับการยอมรับมากพอ จนต้องกังวลเรื่องการขออนุญาตใช้
      ยังจำได้ว่าในยุค 90 นักพัฒนา PHP และ Python เคยแชร์ตัวอย่างแบบนี้เพื่อใช้ตอบ คำถามทางธุรกิจ อย่าง “ทำไมไม่ใช้ Microsoft ASP”
    • ถ้าโครงสร้างอนุญาตให้ส่งโค้ดไปรันภายใน transaction ฝั่งเซิร์ฟเวอร์ได้ นักพัฒนาอาจต้องพัฒนาด้วย Clojure เพื่อใช้ API นั้น
      หรือไม่ก็อาจเป็นการดึงดูดนักพัฒนาให้มาร่วมงานกับบริษัทของตน

  • ธนาคาร API แบบนี้ทำไมถึงมักอยู่ในสหราชอาณาจักรตลอด? อยากทำ ธุรกรรมธนาคารด้วย curl มาหลายปีแล้ว แต่ในสหรัฐฯ ไม่มีใครให้บริการเลย

    • ภาคธนาคารของสหรัฐฯ ล้าหลังอย่างน่าประหลาดใจ และไม่ได้เป็นผู้นำโลกในแง่เทคโนโลยีหรือนวัตกรรมมาหลายทศวรรษแล้ว
      ในทางกลับกัน สหราชอาณาจักรส่งเสริมธนาคารใหม่และเทคโนโลยีใหม่อย่างจริงจัง การโอนเงินระหว่างบัญชีบุคคลแบบทันทีและฟรีมีมาเกือบ 20 ปีแล้ว การจ่ายเงินแบบไร้สัมผัสก็อย่างน้อย 10 ปี โมบายแบงก์กิ้งก็หลายสิบปี และ API ธนาคาร ที่รัฐบาลบังคับใช้ก็เกือบ 5 ปีแล้ว
      สรุปคือ ตามมาตรฐานของวงการธนาคาร สหราชอาณาจักรมีภาคธนาคารที่คึกคักมากและสร้างนวัตกรรมได้รวดเร็ว อีกทั้งมีสภาพแวดล้อมและระบบนิเวศที่พัฒนาดีสำหรับการสร้างนวัตกรรมให้เร็วขึ้น
      ในสหรัฐฯ ดูเหมือนว่าธนาคารจะเลิกสร้างนวัตกรรมทางเทคโนโลยีไปตั้งแต่หลายสิบปีก่อน และเลือกไปสร้างนวัตกรรมด้านค่าธรรมเนียมกับการปฏิบัติต่อลูกค้าแบบลงโทษแทน ดังนั้นจึงไม่มีสภาพแวดล้อมใหม่สำหรับนวัตกรรม และธนาคารเดิมๆ ก็พบว่าการกดคู่แข่งให้จมง่ายกว่าการแข่งขันกันมาก
      จนกระทั่งไม่นานมานี้ สหราชอาณาจักรก็มีจำนวนธนาคารอิสระน้อยอย่างน่าประหลาดใจเช่นกัน แต่สาเหตุที่เรื่องแบบเดียวกันไม่เกิดขึ้น น่าจะเป็นเพราะลักษณะของกฎหมายและกฎระเบียบที่รับรองสิทธิของลูกค้าไว้มาก และลงโทษธนาคารที่ไม่ปฏิบัติตามอย่างจริงจัง
    • การขอใบอนุญาตธนาคารใหม่ในสหรัฐฯ นั้นยาก แต่ในสหราชอาณาจักร เส้นทางสู่การเป็น challenger bank ค่อนข้างชัดเจน Jarvis เองก็ย้ายจาก SF กลับไปลอนดอนเพื่อเริ่ม Griffin
      ธนาคารในสหรัฐฯ ที่มี API มักจะเน้นพาร์ตเนอร์ชิพกับฟินเทครายใหญ่ ดังนั้นแม้แต่ API แบบง่ายๆ ก็น่าจะแพงกว่าบัญชีธนาคารทั่วไป ตัวอย่างเช่น Grasshopper Bank ในสหรัฐฯ เป็นหนึ่งในไม่กี่ธนาคารที่ให้ API บนบัญชีธนาคารพาณิชย์ทั่วไป
      ผมทำงานที่ Treasury Prime ซึ่งรองรับธนาคารสหรัฐฯ หลายแห่งที่ให้บริการ API
    • หลังวิกฤตการเงินปี 2008 และสแกนดัลธนาคารที่ตามมา รัฐต้องใช้เงินภาษีประชาชนอุ้มธนาคารชื่อดังหลายแห่ง และรัฐบาลสหราชอาณาจักรในตอนนั้นก็ออกมาตรการหลายอย่างเพื่อส่งเสริม ธนาคารขนาดเล็ก
      ฝั่งบัญชีบุคคล Monzo และ Starling เป็นชื่อที่รู้จักกันดีที่สุดในกลุ่มที่เรียกว่า challenger bank[1]
      [1]: https://en.wikipedia.org/wiki/Challenger_bank
    • สหราชอาณาจักรกำหนดให้ธนาคารต้องมี ข้อกำหนดด้าน API โดยรัฐบาลเป็นผู้บังคับใช้ ส่วนสหรัฐฯ ปล่อยให้เป็น “ตลาดเสรี” ซึ่งในทางปฏิบัติหมายความว่าต้องเชื่อใจบุคคลที่สามที่ไม่น่าไว้วางใจนักอย่าง Yodlee หรือ Plaid
    • ตอนนี้มี https://column.com แล้ว ปีที่แล้วที่นี่ก็เคยพูดถึง
      Column – ธนาคารที่ได้รับใบอนุญาตสำหรับนักพัฒนา
      https://news.ycombinator.com/item?id=31109170

  • “ยังมีเทคโนโลยีกรรมสิทธิ์อีกชิ้นที่ควรโอเพนซอร์ส เราพอร์ต Datascript ไปยัง FoundationDB แล้ว” นี่ขอเถอะ เปิดเผยออกมาเถอะ
    อยากรู้ว่ามันจะทำงานเป็น ทางเลือกแทน Datomic ได้อย่างไร

    • บทความทั้งชิ้นอ่านเหมือนคู่มือ “วิธี ออกแบบเกินจำเป็น ให้โปรเจกต์เล่นๆ”

  • ประโยคที่ว่า “ในทางกฎหมาย ฟินเทคต้องร่วมมือกับธนาคารเพื่อทำเรื่องพวกนี้ และตอนนี้นั่นหมายถึงธนาคารใหญ่แบบดั้งเดิมที่ใช้เมนเฟรม Griffin คือธนาคารและแพลตฟอร์มเทคโนโลยีที่ฟินเทคทั้งหมดในอนาคตจะสร้างอยู่บนมัน” นี่เขียนในปี 2016 หรือเปล่า
    ตลาดเคลื่อนไปแล้ว Griffin ดูดี แต่ตามหลังหลายเจ้าหลายปี และผู้เล่นที่ตั้งหลักได้แล้วอย่าง ClearBank ก็ให้ API ธนาคาร ได้ดีอยู่แล้ว
    ยังมีที่ว่างให้ผู้เล่นเพิ่มเข้ามาอีก ดังนั้นการที่ Griffin เข้าสู่ตลาดก็น่ายินดี แต่อยากให้ pitch ไม่อ่อนแบบนี้

    • ตัวเลือกในตลาดยังไม่ได้มีเยอะมากขนาดนั้น ClearBank เป็นหนึ่งในสามธนาคารที่มีผลิตภัณฑ์ดีจริง
      และแค่ API ที่ดีอย่างเดียวไม่พอ ต้องมี โมเดลปฏิบัติการ ทั้งชุดที่เข้ากับกลุ่มลูกค้าด้วย ซึ่งการสร้างสิ่งนี้ยากกว่ามาก
    • คำว่า “ที่ฟินเทคทั้งหมดในอนาคตจะสร้างอยู่บนมัน” ฟังเหมือน single point of failure และเหมือนสะท้อนปัญหาของ ทุนนิยมยุคปลาย ที่การแข่งขันกลายเป็นแค่ภาพลวงตา

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

  • ผมไม่ชอบจริงๆ เวลาบทความเริ่มด้วย “ในสตาร์ทอัพ คุณควรใช้ภาษาที่ทรงพลังที่สุดเท่าที่ใช้ได้ และนั่นคือ Clojure”
    นั่นก็แค่ความเห็นของคุณเอง ในสตาร์ทอัพควรใช้ภาษาที่ทำให้ทีมสร้างและปล่อย MVP ได้เร็วที่สุด เพื่อให้ได้ลูกค้ารายแรกหรือเงินลงทุน ภาษาแบบนั้นสำหรับสตาร์ทอัพทั่วไปอาจเป็นแพลตฟอร์ม low-code หรือ no-code ก็ได้ แม้ในฟินเทคน่าจะไม่ใช่ก็ตาม
    ถ้าจะพูดให้สุดๆ เพราะ LLM และแมชชีนเลิร์นนิง อาจบอกได้ด้วยซ้ำว่า Python เป็นภาษาที่ทรงพลังที่สุด และผมเองปกติเป็นนักพัฒนา PHP Python อาจทรงพลังขึ้นไปอีกเพราะ Mojo ที่ supposedly ทำให้ Python เร็วขึ้น 36,000 เท่า
    แต่ผมจะไม่มีวันบอกว่าภาษา X ใดๆ เป็นภาษาเดียวที่ทรงพลังที่สุดสำหรับสตาร์ทอัพ นั่นเป็นเรื่องโกหกเต็มๆ และเป็นแค่ความเห็นเท่านั้น

    • แน่นอนว่าเป็นความเห็น ทุกครั้งที่ใครพูดอะไร มันก็คือความเห็นของคนนั้น
      เช่น ในความเห็นของผม ผมเห็นด้วยกับความเห็นนั้น :-) ธุรกิจที่ผมก่อตั้งคนเดียวคงเป็นไปไม่ได้ถ้าไม่มี Clojure และ ClojureScript และนี่แสดงให้เห็น “พลัง” ของภาษานี้
      ผมมองว่ามัน “ทรงพลัง” เพราะมันทำให้นักพัฒนาคนเดียวสามารถเขียนและดูแลแอปที่ซับซ้อนได้นานหลายปี มันมอบพลังให้ผม
    • ประโยคนั้นจะเข้าใจได้มากขึ้นถ้าคิดว่า JUXT เป็นบริษัทสาย Clojure ที่โด่งดังที่สุดรองจาก Nubank และเป็นบริษัทที่โลโก้ไปอยู่ท้ายงานประชุมแทบทุกงานที่เกี่ยวข้องกับหัวข้อ Clojure แม้เพียงเล็กน้อย
      Clojure มีคอมมูนิตี้ที่ค่อนข้างหันเข้าหากันเอง และทับซ้อนกับ Lisp อื่นๆ มากกว่าภาษายอดนิยมอย่าง Python หรือ PHP ดังนั้นคลิเช่ที่ว่า Clojure เป็นภาษาที่ทรงพลังที่สุด แม้จะมีความจริงอยู่บ้าง แต่สำหรับคนที่ไม่ได้ใช้ก็อาจฟังดูน่าตกใจ
      พวกเรานักพัฒนา Clojure ชินกันแล้ว และตอนนี้การพูดโดยตั้งสมมติฐานว่ามันเหนือกว่าก็แทบจะกลายเป็นคำทักทายไปแล้ว
    • Python ทรงพลังจริงๆ โดยเฉพาะเมื่อดูจากปี 2023 แต่แปลกดีที่ผมใช้ Clojure ในการออร์เคสเตรต LLM และ diffusion model
      ผมยังชอบใช้ Clojure จัดการเอาต์พุตจาก LLM มากกว่า แน่นอนว่าตรงไหนที่ Python เหมาะพอดี ผมก็ยังใช้ Python