Category Archives: Cloud Native

Cloud-Init file to create jumphost

ตัวอย่าง file cloud-init สำหรับสร้าง jumphost โดยใช้ rocky linux os

file นี้จะทำการสร้าง user nutanix ติดตั้ง docker, kubectl และ code server เพื่อให้สามารถใช้ shell ผ่าน vscode

Shell
#cloud-config
ssh_pwauth: true
users:
  - name: nutanix
    passwd: nutanix/4u  
    groups: users,wheel    
    shell: /bin/bash      
    lock-passwd: false    
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
chpasswd:
  list: |
    nutanix:nutanix/4u
    root:nutanix/4u
  expire: False
runcmd:
  - echo "Configuring SSH..."
  # Ensure PasswordAuthentication is enabled
  - sed -i '/^PasswordAuthentication/d' /etc/ssh/sshd_config # Delete existing line
  - echo "PasswordAuthentication yes" >> /etc/ssh/sshd_config # Add new line
  # Ensure PermitRootLogin is set to yes
  - sed -i '/^PermitRootLogin/d' /etc/ssh/sshd_config # Delete existing line
  - echo "PermitRootLogin yes" >> /etc/ssh/sshd_config # Add new line
  # Restart SSH Service
  - systemctl restart sshd
  - echo "SSH configuration updated and service restarted."
  - '[ ! -f "/etc/yum.repos.d/nutanix_rocky9.repo" ] || mv -f /etc/yum.repos.d/nutanix_rocky9.repo /etc/yum.repos.d/nutanix_rocky9.repo.disabled'
  - dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
  - dnf -y install git docker-ce docker-ce-cli containerd.io
  - systemctl --now enable docker
  - usermod -aG docker nutanix
  - 'curl -Lo /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl'
  - chmod +x /usr/local/bin/kubectl
  - 'curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash'
  - 'su - nutanix -c "curl -fsSL https://raw.githubusercontent.com/pkhamdee/nkp-tools/main/install-tools.sh | bash"'
  - eject

สำหรับ https://raw.githubusercontent.com/pkhamdee/nkp-tools/main/install-tools.sh จะเป็นการ deploy code server เพื่อใช้ linux terminal และจัดการไฟล์ผ่านทาง vscode ได้

App Modernization Approach – Swift Process

หลักการในการพัฒนา modern app นั้นมีค่อนข้างหลากหลาย และถูกใช้ในแบบที่แตกต่างกันในแต่ละที่ แต่ละสภาพแวดล้อมของ App และทีม Development ส่วนตัวชอบ process การออกแบบโดยใช้ Swift เพราะเป็นวิธีการที่ prove แล้วว่าใช้ได้จริงในองค์กรใหญ่ๆ โดยใช้ concept DDD และมีขั้นตอนคร่าวๆ ดังนี้

  1. กำหนด OKR เพื่อให้ทีมเข้าใจในทิศทางเดียวกันว่ากำลังจะทำอะไร เพื่ออะไร แล้วจะวัดผลด้วยอะไร
  2. ทำ session Event Storming เป็นการร่วมกัน explore ว่าในเรื่องที่ทำนั้น (context) มีเหตุการณ์ (event) อะไรบ้างเรียงตามเวลาที่เกิดขึ้น session นี้จะทำให้ทั้งทีมเข้าใจในสิ่งที่จะ build ขึ้นมาว่ามีกระบวนการทำงานยังไง
  3. เลือกตัดส่วนที่เข้าใจชัดเจนที่สุด หรือมี impact มากสุดมาทำก่อน
  4. สร้าง diagram เพื่ออธิบาย architect ของแต่ละ module ที่อยู่ใน system (BORIS) ว่ามีความสัมพันธ์กันยังไง มีการแลกเปลี่ยนข้อมูล หรือให้บริการอะไรบ้าง รวมทั้งระบบภายนอกที่เกี่ยวข้อง (external system)
  5. ลงรายละเอียดเบื้องต้นของแต่ละ service (SNAP) เช่น APIs, Data, PUB/SUB, External System, User stories, UI และ Risk แล้วใช้ Project Management tools (Jira) เพื่อขยายรายละเอียดพร้อมสำหรับการนำไป Implement และเข้าสู่กระบวนการ agile
  6. พัฒนา Code
  7. Document กระบวนการ วิธีการพัฒนา ปัญหา วิธีการแก้ไข เพื่อให้ครั้งแต่ไปสามารถนำไปใช้ได้และ ไม่ต้อง research อีกครั้ง อีกทั้งช่วยทำให้คนใหม่ที่เข้ามาในทีมสามารถเรียนรู้ และ follow สิ่งที่ทำผ่านมาแล้วได้

สรุปรูปแบบข้างต้นจากบนลงล่าง

DDD in Action

Leave a reply

หลังจากที่ได้เรียนรู้ Domain Driven Design (DDD) แล้ว ลองเอา concept ของ DDD มาใช้เพื่อออกแบบ Software Architect โดยใช้หลักการของ Swift Method ซึ่งเป็น framework สำหรับการพัฒนา Modernization Software

เริ่มจากสิ่งที่เราเข้าใจ และอธิบายความหมายของคำว่า Item อย่างไร

Item สำหรับแต่ละคนมีความหมายที่แตกต่างกัน แล้วแต่ประสบการณ์และมุมมอง

Item เมื่อไปอยู่ในแต่ละ context ที่แตกต่างกัน ก็จะมีลักษณะไม่เหมือนกัน หรือเป็นคนละอย่างกันเลย เช่น Item ที่อยู่ใน Cart ก็อาจจะเป็นสินค้า แต่ Item ที่อยู่ใน Order ก็จะหมายถึงคำสั่งซื้อ โดยที่อาจจะมีข้อมูลและลักษณะใช้แทนกันไม่ได้เลยทีเดียว ดังนั้นการออกแบบ Software ที่หลายๆ Application ใช้ share data model เดียวกันจึงเป็นการออกแบบที่ไม่เหมาะสม เพราะจะมีปัญหาเรื่องของการ scale หรือแก้ไขเพิ่มเติม จะส่งผลกระทบกับหลายๆ Application ในภายหลัง

สิ่งสำคัญต่อมาคือการพัฒนาการสื่อสารที่เป็น common language ระหว่าง Business และ IT เพราะปัญหาของนักพัฒนา Application ส่วนใหญ่จะเป็นเรื่องของความเข้าใจที่คลาดเคลื่อน (misaligned) จากผู้ที่เป็น Business หรือเจ้าของ Project (Domain Experts) เพราะคนกลุ่มนี้จะไม่ค่อยเข้าใจเรื่อง IT ดังนั้น Software Developer จะต้องใช้ภาษาที่ Business เข้าใจง่าย รวมถึงการออกแบบจะต้องใช้รูปแบบที่แสดงให้เห็นถึงสิ่งที่เกิดขึ้นในชีวิตจริง จึงจะสามารถพัฒนา Code ตาม Business Concept ได้อย่างถูกต้อง

ซึ่งก็คือการใช้ ubiquitous language หรือที่เรียกว่าการใช้ภาษาเดียวกันภายใน bounded context ที่ทีมได้ร่วมกันพัฒนาอยู่

นอกจากนี้ยังต้องพิจารณาเรื่องของ integration ระหว่าง context อื่นๆ ที่ต้องมีรูปแบบการสื่อสารและความสำพันธ์ขึ้นอยู่กับ context นั้นๆ

และกรณีที่ต้องมีการแปลงการสื่อสารเพื่อให้สื่อสารได้ตรงกัน ก็จำเป็นต้องมี Anti-Corruption Layer ACL เข้ามาร่วมด้วย เช่นการสื่อสารระหว่าง 2 ทีม ที่เป็น upstream และ downstream โดยที่ downstream มีส่วนของ ACL เพื่อให้การสื่อสารสามารถเข้ากันได้ เป็นต้น

บางกรณีอาจจะพิจารณาใช้ Aggregates เพื่อให้ข้อมูลถูกนำไปใช้ได้เลย

อาจจะมองเป็นลักษณะของ transaction ที่ข้อมูลประกอบด้วยหลายๆ business entity เช่น Policy, Order, Customer, Account ที่ถูก Aggregates ไว้ด้วยกัน ซึ่งแสดงความสัมพันธ์เป็นลำดับชั้นของกราฟที่มี Root entity และ entity อื่นๆ รวมถึง value object

ตัวอย่างของ Aggregate ของ Item

Item เป็น transaction ที่ประกอบด้วยหลาย entity ภายใต้ขอบเขตเดียวกัน (consistency boundary) สามารถมีได้มากกว่าหนึ่ง entity และ value object โดยมีการ reference ผ่าน ID (ไม่ใช่ reference object) ดังนั้นเมื่อมีการเปลี่ยนแปลงใดๆ กับ Item ก็จะทำให้ผู้ที่เรียกใช้ Item นี้เห็นการเปลี่ยนแปลงนี้ด้วยเช่นกัน (eventually consistent)

Domain Events เป็นเหตุการณ์ที่เกิดขึ้นใน Business เนื่องจากเป็นเหตุการณ์ที่เกิดขึ้นแล้ว จึงนิยมใช้ในรูปแบบ Past Tense การเขียนจะต้องใช้ภาษาที่เข้าใจง่ายทั้ง dev และ domain expert โดยชนิดของ event มีทั้งที่เป็น การแจ้งเตือน (Notification) และ การเปลี่ยนสถานะ (State transfer)

Command ใช้เพื่อระบุว่าเกิดการ request หรือ trigger เพื่อให้เกิดเหตุการณ์ใดๆ ขึ้นใน Business

เมื่อนำ item, domain event และ command เพื่อแสดงสิ่งที่เกิดขึ้นใน domain มารวมกันจะทำให้ทั้ง business expert และ developer เข้าใจตรงกัน สื่อสารกันได้ง่ายและถูกต้อง

Event Storming

ในการออกแบบ software ควรต้องเริ่มต้นจาก events ที่เกิดขึ้นในแต่ละ business โดย event เองเป็น common language ที่ทั้ง business และ IT สามารถสื่อสารและเข้าใจกันได้ง่าย

ข้อดีของการทำ Event Storming

  • ทำให้ Business และ IT เข้าใจในทิศทางเดียวกัน
  • เป็นวิธีที่มีประสิทธิภาพในการทำงานกับ Business
  • ทำให้เข้าใจรายละเอียดของ Domain และ Sub Domain
  • พูดคุย แลกเปลี่ยนความคิดเห็น
  • วิธีการที่เร็ว ทำให้เห็นปัญหา แก้ไข และปรับปรุงให้ดีขึ้น
  • สามารถมองเห็นว่าควรจะทำอะไรก่อนหลัง (priority) และการ deliver
  • สามารถมองเห็นปัญหาได้แต่เนินๆ
  • ตัดสินใจเริ่มทำสิ่งใดสิ่งหนึ่งได้ง่าย

ในการทำ session Event Storming จำเป็นต้องจัดสถานที่ที่เหมาะสม เพื่อให้ business และ IT ได้ทำกิจกรรมด้วยกัน โดยมีกระดาน (board) ที่มีเนื้อที่ขนาดใหญ่ และ sticky note สำหรับแต่ละคนใช้เพื่อเขียน event ลงใน sticky note เพื่อแปะบนกระดาน (board) มีการอธิบายรูปแบบของสีที่ใช้ ว่าสื่อความความหมายถึงอะไร

ในการแปะ event ลงใน board จะต้องเรียงตามลำดับเวลาจากสิ่งที่เกิดขึ้นก่อน แล้วตามด้วยสิ่งที่เกิดขึ้นภายหลัง

ตัวอย่างการแปะ event โดยแบ่งตามสี ถ้าสีส้มคือ event ส่วนสี ชมพู หมายถึง note และแปะตามเวลาก่อนหลัง

ทั้งนี้อาจจะมีสีอื่นๆ เพื่ออธิบาย event ที่เกิดขึ้นได้ชัดเจน เช่น

ตัวอย่างการแปะ event เพื่อแสดง aggregate และ command ด้วย

Value Stream Scenario

ตัวอย่างของการใช้ Event Storming สำหรับระบบ E-Commerce ที่ลูกค้าสามารถเลือกสินค้าเข้าไปยังตะกร้า (cart) ทำการสั่งซื้อ (checkout) มีการส่ง order ไปยังระบบส่งของไปยังที่อยู่ปลายทาง (Shippping)

ลำดับเหตุการณ์ของระบบ purchase แบะ fulfillment จากการทำ Event Storming

จากลำดับเหตุการณ์ทำการ Grouping ให้ event ประเภทเดียวกันอยู่ด้วยกันเพื่อให้เข้าใจง่ายขึ้น และแปะชื่อกลุ่ม รวมถึง note ถ้ามี

แต่ละ group คือ sub domain ใน DDD ที่เคยเรียนมา ทำการแปะเพิ่มเติมในแต่ละกลุ่ม เพื่อให้ event มีความสมบูรณ์มากขึ้น โดยใช้สีแทนความหมาย (DDD – Tactical design)

หลังจากนั้นนำแต่ sub domain มาสร้างเป็นความสัมพันธ์ว่าในแต่ context นั้นมีการเรียกใช้ data หรือบริการอะไรจาก context อื่น เรียกแบบ Sync call หรือ Async event ด้วยวิธีการนี้จะทำให้เราเห็นภาพรวมของระบบ รวมถึงปัญหาที่อาจจะเกิดขึ้นจากการ integration ข้อมูลที่จำเป็นที่จำเป็นจะต้องรู้จากระบบภายนอก (external sytem) เป็นต้น

ตัวอย่างข้างต้นคือการทำ BORIS ซึ่งเป็นกระบวนการหนึ่งใน Swift Method

ขั้นตอนสุดท้ายคือการลงรายละเอียดของ APIs, Data, Pub/Sub, External System/UI, Agile Stories และ Risk เพื่อให้เข้าใจว่าในแต่ sub domain มีกระบวนการ ขั้นตอนการทำงานที่เป็น specification คร่าวๆ เพื่อนำไปเข้าระบบ project management tool (Jira) และทีม developer ก็สามารถจะเริ่มทำการ develop software ได้ตาม sprint หรือ agile process

ขั้นตอนนี้เรียกว่า SNAP ในกระบวนการของ Swift Method

ภาพรวมของทุก sub domain

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

และการมี diagram ที่ติดไว้ใน board จะทำให้ทีมที่เกี่ยวข้อง เข้าใจในส่ิงที่กำลัง develop และไม่เสียเวลามากนักในขั้นตอน document

Cloud Native Design – 12 Factors

Leave a reply

หลักการพิจารณาเพื่อให้การออกแบบ Application สามารถทำงานบน Cloud Environment ได้อย่างราบรื่น และใช้ความสามารถของ Cloud ใด้อย่างมีประสิทธิภาพ ประกอบด้วย 12 ข้อดังนี้

  1. Codebase ใช้ code base เดียว เพื่อ track ในแต่ละ revision control และ deploy ไปยังแต่ละ environment ต่าง

2. Dependencies ระบุความต้องการ lib และ dependencies อื่นๆ ใน project และไม่ share

3. Configuration เก็บ configuration ของ application ใน environment ของระบบ แยกจาก code

4. Backing services สร้าง resource adapter ไปยัง external service อื่นๆ โดยมองว่าเป็นหนึ่ง resource ที่ application เรียกใช้งาน ทำให้การสลับแต่ล่ะ resource ทำได้ด้วยการ attach resource ใหม่ โดยไม่กระทบกับ code

5. Build, release, run แยกขั้นตอน build และ run จากกัน ทำให้ build ครั้งเดียวสามารถ deploy ไปยังหลายๆ ที่

6. Processes ต้อง run app ในรูปแบบ stateless process กรณีที่ต้องมีการจัดเก็บ state การทำงานสามารถเก็บไว้ใน cache โดยใช้หลักการ Backing Services

7. Port Binding ต้อง expose service ออกมาในรูป service port ให้ภายนอกเรียกใช้

8. Concurrency สามารถรอบรับปริมาณงานด้วยการเพิ่มจำนวน process

9. Disposability กระบวนการ start/stop service ต้องทำได้ด้วยความรวดเร็ว โดยไม่ต้องการ manual process หรือ script

10. Dev/Prod Parity สร้าง environment dev และ prod โดยใช้ config และ components version เดียวกัน

11. Logs ใช้ระบบเพื่อจัดการ application log ไม่เป็นส่วนหนึ่งของ application

12. Admin Processes แยก process สำหรับงาน admin และจัดการอื่นๆ

Ref:

the twelve-factor app

Domain Driven Design (DDD)

Leave a reply

เป็นรูปแบบการออกแบบ Software System ที่แก้ปัญหาความซับซ้อน (complexity) โดยเทียบเคียงกับหน่วยงานหรือองค์กรที่การดำเนินงานธุรกิจ ที่มีความถนัดในเรื่องใดเรื่องหนึ่งเฉพาะ (expert domain) การใช้วิธีการนี้เป็นการนำไปสู่การออกแบบ microservice application ได้อย่างดีรวมถึงเป็นการสื่อสาร สร้างความเข้าใจกับทีม Business อย่างมีประสิทธิภาพ (Business first approach)

Domain Driven design แบ่งออกเป็น 2 ส่วนคือ Strategic design และ Tractical Design โดยที่ Strategic Design เป็นการออกแบบเชิงกลยุทธ์ เน้นถึงสิ่งที่สำคัญเชิงกลยุทธ์ต่อธุรกิจ โดยแบ่งตามความสำคัญและผสมผสานตามความจำเป็น

Strategic Domain Driven Design ประกอบด้วย

  • Domain
  • Sub-Domain
  • Bounded Context
  • Ubiquitous Language
  • Context Map

Tactical Domain Driven Design เป็นวิธีปฏิบัตที่จะทำให้บรรลุเป้าหมายตามกลยุทธ์ ส่วนนี้จะลงลึกถึงขั้นตอนในเชิงปฏิบัติ

ประกอบด้วย

  • Entities
  • Value Objects
  • Aggregates
  • Services
  • Modules
  • Factories
  • Repositories

Domains ประกอบด้วย sub-domains และ bounded context

Core Domain คือส่วนของธุรกิจหลัก ซึ่งเป็นสิ่งที่มีคุณค่าและโดดเด่นกว่าคู่แข่ง ไม่ต้องการแชร์หรือให้ใครก็ตามใช้โมเดลหลักนี้ รวมถึงการทำให้โมเดลนี้ไปติดกับ framework ใดๆ (Hibernate Entities) โดยจะมีการพัฒนาในส่วนนี้เองทั้งหมด

Supporting Domain เป็น domain ที่ช่วยทำให้ธุรกิจสามารดำเนินการได้โดยปกติ ตัวอย่างเช่น ในการอนุมัติสินเชื้อ เราต้องการข้อมูลเครดิตบูโรร่วมด้วยในการพิจารณา ทั้งนี้ควรพิจารณาเครื่องมือที่มีอยู่แล้วเพื่อเป็นส่วนเสริมให้กับธุรกิจหลัก หรือนำจากแหล่งอื่นๆ มาใช้ หรือไม่ก็พิจารณาสร้างเท่าที่เห็นว่าจำเป็น

Generic Domain เป็นสิ่งที่มีทั่วไป หรือกระบวนการธุรกิจทั่วไป ที่เราไม่ควรสร้างขึ้นมาใหม่ เช่น SMTP server สำหรับส่ง email หรือ cloud platform สำหรับ run application ควรพิจารณาลงทุนในส่วน core domain เป็นหลัก

Bounded Contexts

  • เป็นขอบเขตบริบทเชิงความหมาย ซึ่งเมื่อพูดถึงสิ่งไดสิ่งหนึ่งแล้วคนฟังจะเข้าใจทันทีว่าเป็นเรืองอะไร
  • เมื่อเป็นคนละเรื่อง สามารถมองได้ว่าจะต้องใช้ software package แยกกัน
  • ในแต่ละ Bounded Context จะมี components อยู่ข้างในที่มีความหมายและทำงานเฉพาะตัว
  • มีการพัฒนาเพื่อให้องค์กรมีความแตกต่างและแข่งขันกับองค์กรภายนอกอื่นๆ
  • ต้องมีหลักในการพิจารณาว่าอะไรควรหรือไม่ควรจะเป็นส่วนหลักของ core domain

ยกตัวอย่างทีม Developer ที่ทำงานกับเรื่องไดเรื่องหนึ่ง เช่น Bounded Context A

โดยที่ทีมนี้สามารถทำงานกับ Bounded context อื่นได้ แต่ไม่ควรให้หลายทีมทำงานบน Bounded Context เดียวกัน เพราะจะส่งปัญหาเรื่องความเข้าใจกับ Bounded Context ที่แตกต่างกันได้

ทำไม Bounded context จึงสำคัญ ถ้าเราพิจารณาเรื่อง Account ในความหมายของ Account สำหรับ Banking ก็จะหมายถึงบัญชีธนาคาร ยอดเงินฝาก ดอกเบี้ย แต่ถ้าในมุมมอง Security จะหมายถึง User Login สิทธิการเข้าถึง service ต่างๆ ดังนี้การมีหลายทีมที่ทำเรื่องเดียวกัน สิ่งเดียวกันแต่อาจจะเป็นคนละอย่างกันได้

Ubiquitous Language

เป็นพัฒนาภาษาที่คุยทั่วไปภายในทีม เช่นคำย่อ เพื่อให้การสื่อสารได้ด้วยความรวดเร็ว และเข้าใจตรงกัน ซึ่งมีทั้งที่เชิงเทคนิค และในเชิงธุรกิจ ของบริบทและในขอบเขตของเรื่องนั้นๆ (Bounded context) แต่ต้องระวังเมื่อนำไปคุยสื่อสารในกลุ่มอื่นๆ เพราะอาจจะเกิดความไม่เข้าใจได้

Context Maps

เป็นภาพรวมความสัมพันธ์ของธุรกิจระหว่าง bounded contexts ต่างๆ ในองค์กร (domain) ซึ่งเป็นส่วนสำคัญ ทำให้ทราบการเชื่อมโยงและวิธีการจัดการในแต่ละ contexts อย่างเช่น Banking ที่เชื่อมโยงไปในหลาย context ตามรูป

Context mappings ประกอบด้วย

  • Partnership
  • Shared kernel
  • Customer-Supplier
  • Conformist
  • Anti-corruption layer
  • Open host service
  • Published language
  • Big ball of mud
  • Separate ways

Context Mapping – Partnership

เป็นความสัมพันธ์ที่มีการร่วมือ และยอมรับอย่างเติมที่ contexts ทั้งสองขึ้นอยู่กับกันและกัน สามารถสื่อสารอย่างเปิดเผย เป็นกรณี success หรือ fail ไปด้วยกัน

Context Mapping – Shared Kernel

เป็นความสัมพันธ์ที่ทั้งสองทีมแบ่งส่วนใดส่วนหนึ่งเพื่อใช้ร่วมกัน ส่งผลให้เกิดการแยกส่วนร่วมนี้เป็นก้อนใหม่ (artifact) เพื่อการ deliver

Context Mapping – Customer-Supplier

เงื่อนไขความสำเร็จของ Supplier บางส่วนขึ้นอยู่กับความสำเร็จของ Customer เช่นระบบกู้ยืมจำเป็นต้องได้ข้อมูลทางด้านการเงินเพื่อพิจารณา

Context Mapping – Conformist

เป็นความคล้อยตาม (conform) ที่โมเดล upstream มีทุกอย่างที่ downstream ต้องการ โดยที่ upstream ไม่ได้สนใจ downstream

Context Mapping – Anti-Corruption Layer

เป็นลักษณะที่ context ไม่สามารถปฏิบัติตามได้ จึงต้องมีส่วนสำหรับการแปลงการสื่อสารภายใน

Context Mapping – Open Host Service

เป็นการกำหนด protocal ในการสื่อสารไว้เพื่อให้ context อื่นสามารถใช้ integrate เข้ามาได้

Context Mapping – Published Language

เป็นการกำหนดภาษากลางไว้สำหรับการติดต่อ เช่น JSON, YAML, XML

Context Mapping – Big Ball of Mud

เป็นอีกประเภทของความสัมพันธ์แบบ ACL ที่ Bounded Context ได้ให้ส่วนของ model ต่างๆ มาใช้ มักจะพบเมื่อต้อง integrate กับระบบเก่ามากๆ (Lagacy)

Context Mapping – Separate ways

เป็นการยกเลิกความสัมพันธ์ที่มีอยู่ และสร้างขึ้นมาใหม่ใน context ทั้งนี้อาจจะง่ายกว่าที่ต้องใช้ความสัมพันธ์ในแบบเดิม

Tactical Design

เป็น design ที่มี scope ใน context ประกอบด้วยหลายส่วนดังนี้

  • Entity ส่วนใดๆ (things) ใน model ที่มีความจำเพาะ (unique identity)
  • Value Object ใช้ในการให้ความหมาย และจำนวนของ Entity เช่น สี และ จำนวน โดยจะไม่มีการเปลี่ยนรูป
  • Aggregates เป็นการรวมหรือเชื่อมข้อมูล เช่น Entity และ Value Object
  • Services การทำงาน หรือ Function
  • Factories สำหรับสร้างส่วนเสริมต่างๆ หรือส่วนสนับสนุน
    • Repositories ตัวแทนสำหรับการ access data ทำให้ model และ data แยกจากกันได้ ทั้งยังเป็นถังสำหรับ Entity และ Aggregates
    • Modules เป็นการ grouping ของสิ่งต่างๆ ใน Bounded context ที่อาจจะมีหลาย module โดยไม่สัมพันธ์กัน
    • Event เป็นตัวแทนของการเปลี่ยนแปลงใดๆ ใน domain จากสถานะหนึ่งไปเป็นอีกสถานะหนึ่ง ปกติเขียนในรูป Noun + past-tense verb เช่น ClaimCreated, ClaimSettled เป็นต้น

The Monolith

Leave a reply

ลักษณะของ software architecture ที่รวมทุก modules ไว้ใน project หรือ package เดียว เพื่อความง่ายในการเรียกใช้ function หรือ service ใน project โดยไม่ต้องแยก deploy ที่ต้องเรียกใช้งานผ่าน interface อย่างเช่น API อีกทั้งการส่งมอบงาน และ deploy ก็ง่ายเพราะ deploy ทั้ง package และการ reuse ในส่วนของ code ก็ทำได้สะดวกสบาย ถือเป็นหลักนิยมของการพัฒนา software ในยุคที่ผ่านมา จนกระทั้ง software ได้ถูกนำมาใช้เป็นบริการหลักของธุรกิจ ความต้องการใหม่ๆ ที่เพิ่มและแก้ไขตลอดเวลา รวมถึงการรองรับจำนวนผู้ใช้จำนวนมาก ทำให้รูปแบบการพัฒนาแบบเดิมเริ่มจะส่งผลในทางลบมากกว่า กล่าวคือ การเพิ่มทีมพัฒนาเข้าไปจะทำได้ยาก เพราะการวาง code ภาษาที่ใช้ จะรู้จักดีในเฉพาะทีมเท่านั้น แต่ละ module ที่มีการเรียกใช้งานเริ่มมีความซับซ้อน และต้อง share หรือรับงานที่มากขึ้น (overloaded) ความต้องการเพิ่มจำนวน process (scalability) ที่ต้องขยาย resource ทั้ง server การที่ทำให้ระบบทำงานได้อย่างต่อเนื่อง (availability) ด้วยประสิทธิภาพของการให้บริการที่ดีตลอดเวลา (reliability) รวมถึงการให้บริการได้แม้ในขณะที่ระบบเกิดปัญหา (Resiliency) การส่งมอบ software อย่างต่อเนื่อง (Continuous Delivery) โดยไม่ทำให้การบริการหยุดชะงัก ทำให้เกิดอัตราเร่งให้ต้องเปลี่ยนแปลงไปสู่ microservice architect

Forces

  • Developer หลายคนทำงานใน project เดียว
  • Developer ใหม่ของทีมสามารถเริ่มต้นทำงานได้อย่างรวดเร็ว
  • Application จะต้องง่ายในการทำความเข้าใจ และแก้ไข
  • ต้องการ apply continuous deployment practices
  • ความต้องการเรื่อง Scale up – Scalability, Availability และ Resiliency
  • ต้องการใช้ประโยชน์จาก technology ใหม่ใน project เช่น framework และ programming language

Solutions

  • สร้างหลายๆ module แล้ว pack ไว้ใน package เดียว เช่น WAR หรือ EAR
    • Deploy ทุกอย่างอยู่ในรูปแบบของ directory เดียว
    • อาจจะแยกหน้าที่ออกเป็นหลายๆ Tier (N-Tier Architechy)
    • ออกแบบเป็นลักษณะลำดับชั้น (Layered Architecture)

Resulting Context

  • การพัฒนา application มีรูปแบบที่ซับซ้อน (Complexity)
  • Web Server ทำงานหนัก ด้วยการทำงานทุกอย่างใน Server เดียว
  • การ deploy ส่ิงใหม่ๆ (continuous deliver) จะทำยากเพราะเกี่ยวพันกับหลาย module
  • การ scale out ใช้เวลามากเพราะต้องการ resource และ scale ทั้ง server
  • การแก้ไข เพื่อให้ใช้งานได้ไปก่อน (Technical debt) ไม่ได้เป็นแนวทางระยะยาว
  • ทำงานได้ใน scope อย่างไดอย่างหนึ่ง มีความยากในการต่อยอด

Business Outcomes Lean Canvas

Leave a reply

Lean Canvas เป็นเครื่องมือที่จะทำให้ Team เข้าใจปัญหาและเลือกแนวทางที่เหมาะสมสำหรับการเปลี่ยนแปลง ด้วยการวิเคราะห์อย่างปัญหารอบด้าน ตัวอย่างนี้จะเป็นการนำ Lean Canvas มาใช้สำหรับการ Change ในกระบวนการพัฒนา Software โดยพิจารณาถึงสิ่งที่องค์กรจะได้รับจากการเปลี่ยนแปลง (Business Outcomes)

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

Problem

Risk

Current State

Operating Model

People

Process

Technology

Metrics

Future State

Operating Model

People

Process

Technology

Business Outcomes

Enablers/Partners

Costs (Operation efficiency)

Revenue (Innovation/Productivity)

รายละเอียดในแต่ละแผ่น

PROBLEM

  • ทำไมเราต้องทำสิ่งนี้ สิ่งที่เป็นเบื้องหลัง หรือแรงผลักทำให้ต้องทำ
  • สิ่งที่เป็นปัจจัยทั้งภายในและภายนอกองค์กร ที่ส่งผลกระทบกับ Business ทำให้ต้องทำสิ่งนี้ หรือต้องพัฒนาให้ดีขึ้น
  • คู่แข่งหลักๆ ที่มองว่าจะกระทบกับผลดำเนินการ และเหตุผลว่าทำไมต้องเปลี่ยน
  • อะไรที่เป็นความยากหรือความท้าทายที่จะทำให้ผลการดำเนินการไม่ตรงตามเป้า
  • อะไรที่เป็นอุปสรรคต่อการเริ่มต้นส่ิงใหม่ๆ (initiatives) วิสัยทัศน์ (vision) ความคืบหน้า (progress) และพัฒนาการ (evolution)

Risk

  • ทีมงาน และองค์กรจะมีผลกระทบอะไรบ้าง ถ้าเราไม่ทำสิ่งนี้
  • อะไรที่เป็นความเสี่ยงในกลุ่มองค์กรและหน่วยงาน IT ถ้าต้องทำสิ่งนี้
  • กลยุทธ์ในการรักษาความปลอดภัยในอันดับต้นๆ คืออะไร
  • ในการเปลี่ยนแปลงครั้งนี้ต้องมีการปรับเปลี่ยนข้อกำหนด หรือมาตรฐานขององค์กรหรือไม่
  • อะไรที่เป็นความเสี่ยง และผลกระทบกับองค์กร จากความเสี่ยงเรื่องการละเมิดความปลอดภัย (Security Breach)

Current State

Operating Model อธิบายสภาพที่เป็นอยู่ในปัจจุบัน

People หน่วยงานและองค์กร (ผังองค์กร ตำแหน่ง และความรับผิดชอบ)

Process ความซับซ้อนของกระบวนการ และสายงาน ระยะเวลาในการส่งมอบบริการ ความจำเป็นต้องเปลี่ยนให้ดีขึ้น รวมถึงการเสียโอกาสทางธุรกิจ (concept to cash)

Technology อธิบายโครงสร้างพื้นฐานของ IT และ Tools ที่ใช้ในปัจจุบัน ธุรกิจสามารถใช้ความสามารถของระบบได้อย่างเต็มประสิทธิภาพหรือไม อะไรที่เป็นปัญหาหรืออุปสรรคในการให้บริการของระบบ IT

Metrics

  • เป้าหมายและวิธีการวัดผล
  • การประเมินผลสำหรับโดยรวมในทางธุรกิจ
  • หน่วยวัดที่สำคัญสำหรับประเมินทีม IT
  • หน่วยวัดเพื่อประเมินผลลัพธ์ร่วมกันระหว่างหน่วยงาน IT และธุรกิจ
  • หน่วยวัดเพื่อประเมินประสิทธิภาพ สำหรับเป็นส่วนหนึ่งในการประเมินตาม KPI ส่วนบุคคล

Future State

Operating Model วิสัยทัศน์ และแนวทางดำเนินงาน

People เป้าหมายที่ต้องการบรรลุ ความสนใจและประโยชน์ที่ได้รับจากโมเดลในการจัดการในแบบ Agile/Lean ทีม Development พัฒนา Software ด้วยตัวเองหรือต้องพึ่งพา Outsorce

Process อธิบายผลลัพธ์ที่ต้องการเกี่ยวกับระบบ Automation การเพิ่มผลลัพธ์ (Productivity) ประสิทธิภาพ (efficiency) การลดความเสี่ยง (risk) และการกำกับดูแลที่ง่าย (simplified governance)

Technology อธิบายกลยุทธ์สำหรับการนำบริการ cloud ไปใช้ การย้าย workload ไปยัง cloud ส่งผลต่อความสามารถในการสร้างนวัตกรรมและการเติบโตทางธุรกิจอย่างไร

Business Outcomes

  • อะไรคือผลลัพธ์ทางธุรกิจที่ต้องการบรรลุ (business outcomes)
  • ความคิดริเริ่มที่จะทำให้สามารถบรรลุผลลัพธ์ทางธุรกิจได้
  • ความสามารถในการเติมโตและแซงหน้าคู่แข่ง

Enablers/Partners

  • สิ่งที่เราต้องการจากพันธมิตรทางธุรกิจ (ที่ปรึกษา หรือ ซัพพลายเออร์)
  • ที่ผ่านมา อะไรคือความสำเร็จ และล้มเหลวจากพันธมิตรทางธุรกิจ
  • คำแนะนำในประเด็นสำคัญที่กำลังมามองหา

Costs (Operational efficiency)

  • การประหยัดต้นทุนจากประสิทธิภาพที่เพิ่มขึ้น
  • ขนาดของทีม และค่าใช้จ่ายเฉลี่ยต่อพนักงาน
  • ค่าใช้จ่ายรวมในการดำเนินงานตลอดทั้งปี
  • การลดต้นทุนจาก license และการใช้ resource ให้มีประสิทธิภาพมากขึ้น รวมถึงการยกเลิกบาง resource ที่เกินความจำเป็น

Revenue (Innovation/Productivity)

  • ช่องทางที่ทำรายได้ให้กับธุรกิจมากที่สุดในปัจจุบัน
  • สรรหาช่องทางสร้างรายได้อื่นๆ
  • แนวความคิดใหม่ๆ เพื่อเพิ่มโอกาสในการสร้างรายได้มากยิ่งขึ้น

…end…

Cloud Native, WHY WHAT HOW

Leave a reply

เพื่อให้เข้าใจเรื่อง cloud native เราจะต้องทำความเข้าใจที่มาที่ไปว่าทำไมถึงมี cloud native แล้ว cloud native คืออะไร รวมถึงเราจะสร้าง cloud native ต้องทำอย่างไรบ้าง

WHY?

เริ่มต้นจากที่เรามี pain เกี่ยวกับ infrastructure ที่ต้องการ scale เพื่อให้รองรับ workload ที่มากขึ้นจาก model ธุรกิจที่ต้องแข่งขัน และการ transform business ให้เป็น digital business ทำให้ infrastructure ไม่สามารถรองรับการเติมโตได้ทัน จึงเป็นโอกาสให้ service provider ต่างๆ ออกมาให้บริการ infrastruture ในแบบ on demand ที่เราคุ้นเคยก็จะเป็นบริการ cloud service ของเจ้าตลาดอย่าง aws , google หรือ azure รวมถึง local provider อย่าง AIS, Cloud HM เป็นต้น ซึ้ง model service พวกนี้ก็คือการให้บริการ cloud computing โดยมีคุณลักษณะเบื่องต้นคือ

  • Resource pooling ให้บริการผ่าน network ในแบบ on-demand และ self-service
  • Resource ถูกสร้างขึ้น ยกเลิกตามความต้องการ (ephemeral) รวมถึงสามารถปรับแต่งและ scale ได้ (elasticity)
  • Resource ไม่เกี่ยวพันโดยตรงกับ physical hardware ระบบสามารถนำ server ที่เหมาะสมมาให้บริการได้
  • เข้าถึงได้ง่าย
  • มีระบบบันทึกและแจ้งปริมาณการใช้

จากความสามารถที่ได้กล่าวข้างต้นจะเห็นว่า infrastructure มีรูปแบบที่ง่ายในการใช้งาน และทำให้ application เองสามารถใช้ความสามารถใหม่ๆ ของบริการในแบบ cloud ได้มากยิ่งขึ้น ทำให้เกิด demand ในฝั่ง Application โดยเกิดคำนิยามใหม่คือ Cloud Native Application คือ application ที่ถูกสร้างขึ้นจากการใช้ความสามารถของ cloud computing ทำให้ได้ความสามารถใหม่ๆ เช่น

  • Build for change ทำให้ Apps สามารถ change ได้ง่าย และไม่สงผลกระทบกับการใช้งาน
  • Build for scale ทำให้ Apps สามารถรองรับการใช้งานที่มากขึ้นจากการเพิ่มจำนวน process
  • Fault tolerance ทำให้ Apps ยังคงให้บริการได้แม้จะเกิดปัญหาของระบบ โดยที่ cloud platform จะช่วยให้ Apps สามารถทำงานได้บน Resource ที่ Available อยู่ได้
  • Continuous Delivery ทำให้ Apps สามารถ deploy ได้อย่างต่อเนื่อง
  • Agile ทำให้ Development Team สามารถแบ่งส่วนของ Apps และส่งมอบในแต่ feature ย่อยๆ ได้อย่างต่อเนื่อง รวมถึงปรับเปลี่ยนตามความต้องการใหม่ๆ ได้เร็ว

WHAT?

ความคาดหวังจากผู้ใช้ Application และการใช้งานที่มากขึ้นทำให้ Application เองก็ต้องพัฒนาให้ตอบสนองคนใช้งานที่เรียกว่า Reactive Design โดยมีปัจจัยต่างๆ ที่ควรพิจารณาคือ

  • React to Events ออกแบบให้ Application ทำงานโดยตอบสนองกับเหตุการ​ณ์ต่างๆ ได้เองโดยไม่ต้องรอให้มีการเรียกใช้ ในรูปแบบ Event Driven Architecture
  • React to Load ออกแบบให้ Application สามารถ scale ด้วยการเพิ่มจำนวน process ได้ (scaleable)
  • React to Failure ส่วนของ platform ที่ทำให้ Application สามารถทำงานได้ในขณะที่อาจจะมีบาง process หยุดทำงานไป (Resilient)
  • React to Users ออกแบบให้การตอบสนองการใช้งาน Application ได้ราบรื่น ไม่กระตุก หรือรอนาน (Responsive) ถึงแม้จะมีจำนวนผู้ใช้งานที่มากขึ้นก็ตาม

ยังมีปัจจัยอื่นๆ นอกเหนือจากเรื่องของการตอบสนองต่อการใช้งาน (Reactive) ที่ต้องพิจารณาอย่างเช่น Speed & Safety โดยคำนึงถึงความรวดเร็วในการ Recovery ในกรณีที่ระบบมีปัญหา

HOW?

ในการจะสร้าง Cloud Native Application จำเป็นต้องอาศัย Design Patterns และ Framework เพื่อให้สามารถเริ่มต้นการสร้างระบบได้เร็วและการจัดการที่มีประสิทธิภาพ โดยประกอบได้ key หลักๆ คือ

  • Application Framework ส่วนนี้จะต้องพิจารณาใช้ ​​Framework เพื่อช่วยพัฒนา application เช่นการใช้หลักการ API First มีการใช้ API Gateway และ Integration Pattern เข้ามาช่วยแก้ปัญหาความเข้ากันได้ของระบบ และ Transaction ระหว่างระบบ การใช้ Reactive Design การ Develop Application ตามรูปแบบ 12Factor และ Microservice เป็นต้น
  • Runtime Platform ใช้ Platform จัดการ runtime application เช่น Kubernetes Platform หรือ Serverless
  • Infrastructure Automation มีระบบช่วยในเรื่องการทำ self-service และ automate provision resource การทำ resource planing, monitor และระบบช่วยบริหารจัดการ infrastructure สำหรับ day 2 operation
  • Infrastructure ที่พร้อมต่อการใช้งาน

ในการออกแบบ Application ในแบบที่เป็น Distributed System ยังต้องมีเรื่องที่ต้องพิจารณาเพิ่มเติมเช่น

  • Configuration Management การจัดการ Application Configuration แบบรวมศูนย์ เพื่อความง่ายในการเปลี่ยนแปลง Configuration ของ Application
  • Registration and Discovery การ Register Application บนระบบ และการค้นหาบริการของ Application
  • Routing and Load-Balancing การเรียกใช้และการเข้าถึง Application
  • Fault Tolerance and Isolation การที่ application จะต้องทำงานได้ในภาวะที่ระบบมีปัญหา และการใช้งาน Resource ที่แยกจากกันอย่างจัดเจน
  • Aggregation and Transaction การรวมผลลัพธ์ที่ได้จากการทำงานและการควบคุมกระบวนการทำงานที่แยกกันหลาย Process
  • Monitoring and Distributed Tracing การ monitor และเข้าถึง log ของ Application ที่กระจายออกไปหลายที่
  • Process Management การเข้าถึงและควบคุม process การทำงานของ application

Cloud Native Application Portfolio Assessment Guide

Leave a reply

กระบวนการในการพิจารณา เพื่อประเมินความเหมาะสมสำหรับการย้าย Application ไปยัง Cloud Native Platform นั้นมี criteria หลายอย่างด้วยกัน ซึ้งบทความนี้จะให้คำแนะนำเพื่อเป็นแนวทางให้สามารถตรวจสอบ Application จัดลำดับความสำคัญ สิ่งที่ต้องปรับเปลี่ยน (refactore) เพื่อทำเป็น backlog ในขั้นตอนของ Implement ต่อไป

สำหรับการประเมินนั้น หลักๆ จะใช้หลักการของ 12 Factors ที่เป็นหลักการในการออกแบบ Cloud Native Application ซึ้งสามารถอ่านข้อมูลเพิ่มเติมได้จาก http://12factor.net

โดยแต่ละรายการที่จะกล่าวต่อไปในหัวข้อ 12 Factors ที่ส่งผลกระทบกับกระบวนการออกแบบ Application ที่ถ้า Application สามารถ comply ได้ ก็จะจัดได้ว่าเหมาะสมในการย้าย platform (replatform) แต่ถ้ากรณีที่ Factor ที่สำคัญๆ Application ไม่สามารถ comply ได้ก็จะพิจารณาว่าไม่เหมาะสมในการย้าย Application ไปยัง Cloud Native Platform

1. Codebase

ในหนึ่ง Codebase หรือ project ต้องมีระบบ Source Code Management (SCM) เพื่อติดตามและบันทึกประวัติการเปลี่ยนแปลงของ source code รวมถึงการทำ versioning ของ source code ทั้งนี้สามารถ deploy application จาก codebase ไปยัง environment ที่แตกต่างกันได้

โดยทั่วไป Platform จะช่วยให้ทีม Agile Development สามารถทำงานได้ง่าย แต่ความสามารถของ Platform ไม่ได้รวมถึงการ migrate หรือ deploy application ผู้ใช้ยังคงใช้วิธี manual proces หรือ automate ผ่านกระบวนการ CI/CD pipeline สำหรับ application ที่มีกระบวนการ build และ packaging (ควบคุมด้วย CI) ผ่านทางระบบ build system สามารถพิจารณาได้ว่ามีความเหมาะสมในการย้ายไปยัง Cloud แต่ในกรณีที่ไม่มีระบบ build system ก็จะมีความยากและปัญหาจากปัจจัยอื่นๆ ตามมา บางกรณี application อาจจะมี script เพื่อดึง dependencies และจัดการการเข้ากันได้กับระบบข้างเคียง ก็อาจจะพิจารณาได้ว่ามีความเหมาะสมระดับปานกลาง

Application ที่ไม่เข้าข่ายข้างต้นจะถูกพิจารณาว่าไม่มีความเหมาะสมในการย้ายไปยัง Cloud Native Platform อย่างไรก็ตามควรคำนึงถึงความยากในการปรับเปลี่ยน และประโยชน์ที่ได้เมื่อ Applicaiton ทำงานบน Cloud Native Platform ประกอบการพิจารณาด้วย

ตัวอย่างปัญหาที่พบ

  • Application Code ไม่ได้ถูกจัดการด้วย Source Control
  • Application Code ถูกจัดการด้วย Source Control แต่ Code กระจายไปยังหลายๆ Repositories หรือ SCM
  • ไม่มีระบบ CI/CD pipeline ตัวอย่างเช่นไม่มี Build service ที่ถูกจัดการด้วย automate tool เช่น TeamCity, Bamboo, Jenkins หรือ build automation tool อื่นๆ

2. Dependencies

ระบุการใช้ dependencies ใน code ให้ชัดเจนและไม่มีการใช้ code ร่วมกันจากหลายๆ project (isolate)

เป็น Factor ที่จำเป็น ถ้า Application ไม่ได้ระบุ Dependencies ที่จัดเจน หรือมีการใช้ code ร่วมกัน จะทำให้การทำ automate ด้วย CI/CD เฉพาะ Application ทำไม่ได้ เพราะต้องรวม Application อื่นเข้ามาใน Process ด้วย ซึ้งจำเป็นต้องปรับเปลี่ยนค่อนค่างมาก

ตัวอย่าง Application ที่มีการระบุ dependencies ที่ดี ส่วนใหญ่จะจัดการผ่าน tool เช่น Gradle, Maven, Ant, NuGet สำหรับ .NET ก็จะไม่ค่อยมีปัญหาเพราะ tool จะสามารถระบุ dependencies ต่างๆ ที่จำเป็นสำหรับ Application ให้ได้

ตัวอย่างปัญหาที่พบ

  • Application ไม่สามารถแยก deploy ได้ จำเป็นต้อง deploy application อื่นร่วมด้วยถึงจะสามารถทำงานได้
  • ไม่ได้ใช้ build หรือ dependencies management system เช่น maven, ant, gradle
  • Application release เดียวกันทำงานได้เฉพาะบาง environment เนื่องจากไม่พบ dependencies ที่ต้องการใน environment ที่มีปัญหา
  • .NET Application พึ่ง dependencies จาก Global Assembly Cache (GAC) ส่งผลกับการให้ deploy application ไปยัง environment อื่นมีปัญหาจากการหา dependencies ที่ต้องการไม่พบ

3. Configuration

ให้ Environment จัดการ configuration ของ application

Application จะต้องใช้ configuration จาก environment ตัวอย่างเช่น java application จะเขียน config ใว้ใน properties file โดยเก็บไว้ใน disk ของ environment ซึ้งก็จะไม่เข้ากับคำแนะนำนี้ เช่นเดียวกับ .NET ที่เขียน application config ไว้ใน web.config file

แม้จะเป็นไปได้ว่า configuration สามารถ deploy ร่วมกับ application ซึ้งมองว่าเป็น dependencies เฉพาะของ application ก็จะทำให้ยากมากขึ้นในการจัดการ ทั้งนี้ Application ที่ไม่ได้ดึง configuration มาจาก environment อาจจะสามารถ replatform ได้ขึ้นอยู่กับ configuration ที่เก็บใน properties file หรือสถานที่เก็บอื่นนอก environment

สำหรับ application ที่ไม่ตรงตามข้อแนะนำข้างต้น จำเป็นต้องประมาณการความยากในการ migrate เพื่อมาใช้ environment configuration อาจจะพิจารณาร่วมกับการใช้ Service เพื่อติดต่อกับ backend service (เพิ่มเติมในหัวข้อ Backing service Factor) ทั้งนี้การให้น้ำหนักเรื่องการปรับเปลี่ยน application ให้ตรงตามข้อกำหนด เป็นส่วนหนึ่งที่นำมาใช้ในการลำดับ application ที่เหมาะสมกับการ replaform

ตัวอย่างปัญหาที่พบ

  • การใช้งาน *.properties file ใน code java
  • มีการใช้ properties class ใน code java
  • อ่านข้อมูลจำเพาะต่างๆ ของ environment จาก resource และ files
  • Configuration ทุกอย่างถูกเก็บใน web.config และไฟล์เกี่ยวข้องอื่นๆ (.NET) เช่นเก็บใน configuration manager และ class object

4. Backing Services

ออกแบบให้ services ที่ application ต้องการเรียกใช้ (backing service) เสมือน resource หนึ่งของ application ที่สามารถใช้งานด้วยการนำเข้าและออกได้ง่าย

ตัวอย่างเช่น URL หรือ Locator/Credentials ที่ application ใช้ในการเรียก backing service ถูกเก็บไว้ใน configuration เพื่อให้ถูกต้องตามข้อกำหนดนี้ Application จะต้องทำตามข้อกำหนด Configuration Factor

เพื่อให้เป็นไปตามข้อกำหนด Application ต้องสามารถปรับเปลี่ยนเพื่อใช้ Service (นำเข้า/นำออก) เช่น data store, messing/queueing system, email, caching โดย service พวกนี้จะถูกจัดการผ่านระบบภายนอก (Third party) โดยที่ไม่ส่งผลกระทบกับ application code ทั้งนี้รวมถึง resource ที่สามารถปรับเปลี่ยนได้ในขั้นตอน deployment

ทั้งนี้ Application จะคงสามารถทำงานได้ปกติถึงแม้จะไม่ตรงตามข้อกำหนดโดยขึ้นอยู่กับ Application และ Service ที่เรียกใช้ เช่นกำหนด connection ใน configuration ที่จัดเก็บไว้ใน environment ก็ยังคงถือว่าใช้ได้เหมือนกัน

แนะนำให้แก้ไข code ของ application ที่ไม่ตรงตามข้อกำหนดนี้โดยให้มีการใช้ environment variable เพื่อเรียกใช้ backing service โดยปรับ code ให้ง่ายในการปรับเปลี่ยนมากขึ้น (abstract) เช่นการใช้วิธีการ Dependencies Injection ช่วย ทั้งนี้รวมถึง credentials และ connection parameter สำหรับ legacy application หรือ service ที่ยังไม่ได้อยู่บน cloud environment

ตัวอย่างปัญหาที่พบ

  • มีการ hard code ค่า configuration (หรือไม่ใช้ environment configuration) เช่น​ database connection string
  • กำหนดข้อมูลตายตัวสำหรับค่า URL และ Port สำหรับเชื่อมต่อ backing service
  • Application เรียกใช้งานได้กับบาง backing service เช่น ทำงานได้เฉพาะ database driver เพราะไม่ได้ใช้ adapters/JDBC/abstractions ช่วย
  • เก็บ credentials สำหรับ backing service ใน configuration setting ที่อาจมองว่า application ขึ้นอยู่กับ environment มากเกินไป (tight environmental coupling)
  • Backing services ใน Docker-to-Docker โดยไม่ได้ใช้ Docker image linking จำเป็นต้องพึ่ง /etc/hosts file ที่จะส่งผลเสียกับ platform ตามมาภายหลัง

5. Build, Release, Run

แยกขั้นตอน build และ Run ออกจากกันอย่างชัดเจน

Code ถูกนำไปใช้ในการ deploy ผ่านขั้นตอนหลักๆ อยู่ 3 ขึ้นตอนคือ build , release และก็ run โดยที่ build จะเปลี่ยน code ให้กลายเป็น application ที่สามารถทำงานบน computer ได้ release จะรวมผลลัพธ์จากการ build รวมกับ deployment configuration ที่ application ต้องใช้ในการ deploy และ Run ก็จะ run application บน environment โดยที่ application จะสามารถเข้าถึง configuration ที่ต้องการจาก environment และทำงานเป็น process ในระบบ

ทั้งนี้กระบวนการ CI/CD pipeline จะรวมขั้นตอนข้างต้น เพื่อให้ทำงานสอดคล้องกันในแต่ละขึ้นตอนจากเริ่มจน application สามารถทำงานได้

สิ่งสำคัญที่ต้องพิจารณาคือ ทุกๆ releae จะต้องมีการระบุอย่างชัดเจน เช่นทำ version (uniquely identifiable) สามารถสร้างขึ้นใหม่ได้ (immutable artifact) ส่วนขั้นต้อนการ run จะต้องเล็ก (small) ง่าย (small simple thing) และมีส่วนประกอบที่น้อยที่สุด (few moving part)

ตัวอย่างปัญหาที่พบ

  • การ deploy จะสำเร็จได้จะต้องอาศัยการตั้งค่าเพื่อติดตั้งบน environment
  • Application ไม่เป็นไปตามกฏ configuration factor
  • ไม่สามารถแยกขั้นตอน build, release, run ออกจากกันได้

6. Processes

Application ทำงานโดยไม่เก็บ state (Stateless processes) และไม่ share state ให้ process อื่น ในกรณีที่ต้องการเก็บ data จะต้องใช้ backing service ช่วย

File system ที่ให้บริการสำหรับ application ที่ทำงานบน platform จะไม่คงอยู่เสมอไป เป็นไปได้ที่ application ไม่สามารถทำงานได้สำหรับข้อกำหนดนี้คือ file system ถูกลบทิ้งหลังจาก process ของ application จบการทำงาน และไม่สามารถทำงานใหม่ด้วย file system เดิมได้ ดังนั้นการเก็บข้อมูลใดๆ ของ application จะต้องทำผ่าน backingn service (เพิ่มเติมจาก Backing Service Factor)

Application ที่ทำงานได้อย่างมีประสิทธิภาพบน platform จะต้องเป็นในรูปแบบ stateless หมายถึง application จะต้องไม่เก็บ state ใดๆ ไว้ใน memory, local file system หรือ http session state และจะต้องหาแนวทางที่เหมาะสมถ้าในกรณีที่ developer ต้องการเก็บ state ของ application

ในการตรวจสอบ application ว่าเป็นไปตามข้อกำหนดนี้ สามารถทำได้ด้วยวิธีการ “Smoke test” โดย start application ขึ้นมา 2 instance และทำการ rundom request ไปยัง 2 instance เพื่อทดสอบว่า application สามารถทำงานได้ตามปกติ

กรณีที่ใช้ sticky sessions โดยให้ transaction ทำงานที่ process เดียว ก็ถือว่าไม่ตรงตามข้อกำหนดนี้ และไม่ควรเลือกแนวทางนี้ถ้าไม่จำเป็น ในกรณีที่ application ไม่ตรงตามข้อกำหนดนี้ แต่ว่ามี code base ที่สามารถเพิ่มเติมส่วนการจัดการ session ได้ ก็สามารถใช้ session management ในแบบ backing sevice โดยการใช้ Redis ช่วย

การพิจารณาตามข้อกำหนดนี้จะเป็นในมุมของ application process ว่าทำงานอย่างไร รูปแบบการหยุด มีการใช้ state และ process จัดการ state ในระหว่างการทำงานหรือไม่

ตัวอย่างปัญหาที่พบ

  • Application มีการจัดการ state (รวมถึง session) ใน memory ส่งผลให้ state หาย ทำให้ application ไม่สามารถทำงานใหม่ได้หลังจากถูก terminate
  • Application แชร์ data ให้กับ application instance อื่น
  • Application สร้าง data บน file system เพื่อที่จะใช้ต่อเมื่อ process หยุดการทำงาน
  • Application ทำงานได้จาการใช้ docker data volumes เพื่อที่จะให้ data สามารถเก็บไว้ใช้ได้นอก container process
  • Application ไม่สามารถทำงานได้เมื่อ start พร้อมกันหลาย instance หรือต้องอาศัย sticky session ช่วย

7. Port Binding

ให้บริการ service ด้วย port ที่ไม่ถูกกำหนดตอนเริ่ม process (runtime injection) ทั้งนี้ web server ต้องให้บริการ service กับผู้ใช้ โดยส่งต่อไปยัง application port ที่ถูกต้อง

บริการที่ไม่ใช่ HTTP Platform จะต้องมีการจัดการ TCP routing เพื่อที่จะสามารถ replatform ได้

ตัวอย่างปัญหาที่พบ

  • Application ให้บริการผ่าน protocal ที่ไม่ใช่ http วิธีลดปัญหานี้ควรระวังเรื่องการใช้ protocal jmx, multicast, udp, custom tcp protocal, rmi-iiop
  • มีการระบุ port เป็น requirement เฉพาะ เช่น application จะไม่สามารถ start ได้ถ้าไม่อนุญาติให้ทำงานที่ port 8081
  • Application ต้องการ process หรือต้องมี port พร้อมใช้งานก่อนถึงทำงานได้

8. Concurrency

การ scale application เพื่อรองรับการทำงานที่มากขึ้น ด้วยวิธีการเพิ่มจำนวน process

Platform สามารถที่จะ scale application ด้วยการเพิ่มจำนวน instance (scale out) ในขณะที่การเพิ่ม resource เช่น RAM และ CPU (vertical scaling) ก็เป็นอีกทางเลือกแต่จะมีข้อจำกัดเรื่อง hardware

ในการย้าย application ที่เป็นชนิด monolith ขึ้นไปยัง cloud native platform ด้วยวิธีการแก้ปัญหาต่างๆ เพื่อให้สามารถทำงานบน platform ใหม่ได้ เราจะพบว่า monolith application ส่วนใหญ่มีความต้องการ memory มากกว่าทั่วไป เนื่องจากอาจจะต้องจัดการ state ใน application เอง แต่ถ้าสามารถย้ายการจัดการ state ไปยัง backing service ก็จะช่วยเรื่องความต้องการ resource บน platform ที่น้อยลง

ในกรณีที่ application ถูกสร้างตามหลักการ concurrency คือไม่แชร์ resource (share-nothing) สามารถทำงานพร้อมกันหลายน instance ได้ (horizontally partitionable application) การย้ายไปยัง cloud native platform ก็จะสามารถทำได้ง่าย

ตัวอย่างปัญหาที่พบ

  • Application ไม่สารถทำงานพร้อมๆ กันหลาย instance ได้
  • การ scale application ให้ทำงานพร้อมกันต้องอาศัย sticky session ในการจัดการ roting ของ request
  • Application ต้องการ memory จำนวนมากเพื่อที่จะ scale
  • ใช้หรือพึ่งพาการการกระจาย transaction เพื่อทำงานร่วมกันจากหลาย process (distributed transaction) อาจจะเป็นปัญหาในการ scale (horizontal) บน platform
  • Application ไม่ตรงตามกฏ configuration factor และ processes factors
  • Application ถูก deploy ด้วย package ที่เป็น EAR/WAR อาจจะเป็นปัญหากับการ packaging ในรูปแบบ container และการ scale ในแบบเพิ่มจำนวน process

9. Disposability

การเพิ่มความเสถียรด้วยออกแบบให้ appliation เริ่มทำงาน (startup time) และหยุดทำงานอย่างสมบูรณ์ได้เร็ว (graceful shutdown) ทั้งนี้การ start หรือ stop สามารถเกิดขึ้นได้ตลอดเวลาโดยไม่ได้กำหนดล่วงหน้า

ข้อแนะนำนี้ application จะต้องอาศัย ความเร็ว (speed) และความสมบูรณ์ (grace) ทั้งนี้ application จะต้อง shutdown ได้อย่างสมบูรณ์เมื่อได้รับ SIGTERM signal จาก process manager

สำหรับความเร็วนั้น Platform เองสามารถกำหนดได้อย่างเช่น application จะต้องให้บริการทาง port ที่เปิดไว้ภายใน 5 นาที ไม่เช่นนั้น platform จะถือว่า application มีปัญหา หรืออาจจะหยุดการทำงานอย่างสมบูรณ์ไม่ได้ภายในเวลาที่กำหนด ในกรณีนี้ application จะไม่สามารถทำงานบน platform ได้

ตัวอย่างปัญหาที่พบ

  • Application ใช้เวลามากว่า 5 นาทีเพื่อพร้อมในการทำงาน
  • Application หยุดการทำงานหลังจากได้ SIGTERM signal ทำให้ข้อมูลหาย หรือทำงานได้ไม่สมบูรณ์
  • หยุดการทำงาน webserver IIS หรือ terminate process หรือ pool (.NET) ทำให้ข้อมูลหาย หรือทำงานไม่สมบูรณ์
  • การหยุด application ใช้เวลานาน หรือต้องการขั้นตอนที่ซับซ้อนในการยกเลิกการจอง resource

10. Dev/Prod Parity

ให้การ deploy application และ environment setup ในขั้นตอน development, staging และ production ในรูปแบบเดียวกันให้มากที่สุด เนื่องจาก 12 Factor ถูกออกแบบเพื่อให้ ส่งมอบ application ได้อย่างต่อเนื่อง (continuous deployment) ด้วยการทำให้ความแตกต่างของการ deploy application ในขั้นตอน development มีน้อยที่สุด

ถ้า application ต้องการที่จะต้องปรับแต่งเพื่อให้สามารถทำงานได้บน environment ที่แตกต่างกัน หรือ codebase ต้องมีการแยกเพื่อให้เหมาะสมกับการ deploy ในแต่ละ environment เช่นมี branch QA หรือ PROD อาจจะมองได้ว่าเป็นการ design ที่ไม่ดี และไม่ตรงตามกฏข้างต้น

ในกรณีของ Docker image อาจจะเป็นปัญหากับข้อกำหนดนี้ เพราะอาจจะมีการ pack บาง config เพื่อให้เหมาะสมกับ environment จำเป็นต้องตรวจสอบและป้องกันไม่ให้เกิดปัญหา conflict กับ platform

กรณีที่ application ไม่ตรงตามข้อกำหนดนี้ ก็อาจจะไม่ตรงตาม Backing Service Factor ได้เหมือนกัน เนื่องจากบางกรณี developer จำเป็นต้องใช้ backing service ที่แตกต่างกันระหว่าง development และ production

ตัวอย่างปัญหาที่พบ

  • มีการใช้ Docker image ที่มีการ pack configuration สำหรับเฉพาะ environment เช่น มีการแยก QA Docker หรือ Prod Docker
  • การทำงานของ Application แตกต่างกัน หรือ feature ไม่เหมือนกันระหว่าง Production และ Development
  • เวลาในการ deploy application ใน Dev/QA และ Produciton ค่อนข้างเยอะ จากการที่ต้องปรับแต่ง เพื่อให้ application สามารถทำงานได้ใน environment ที่แตกต่างกัน

11. Logs

จัดการ log ของ application ในแบบเหตุการณ์ที่เกิดต่อเนื่อง (event stream) โดยไม่ควบคุมหรือจัดการไดๆ

Platform มีหน้าที่ต้องจัดการ log ของ application และ system เพื่อแสดงบน console ให้ Developer สามารถเข้าถึงได้ ทั้งนี้ Application เองจะต้องเขียน log ไปยัง standard output และ standard error เพื่อที่ Platform จะสามารถตรวจจับ รวบรวมและแสดงผลได้ในที่เดียว

ดังนั้น application ต้องไม่เขียน log บน file และเก็บไว้ใน file system เอง ในกรณีที่ appliction มีการใช้งาน SLF4j, Log4j, logback หรือ tool อื่นๆ เช่น ELMAH สำหรับ ASP.NET application ที่ ELMAH เองจะต้องการ backing service เช่น SQL server ทั้งนี้การเปลี่ยนให้ application มาใช้ stdout/stderr ก็จะส่งผลกระทบน้อย

Application อาจจะพิจารณาใช้ syslog หรือ log service อื่นๆ เพื่อจัดการเรื่องความปลอดภัยของข้อมูลได้ ในกรณีที่จัดการ stdout/stderr ผ่าน platform มีความยากในการจัดการ

ตัวอย่างปัญหาที่พบ

  • Application ไม่ได้ใช้ tool ช่วยในการจัดการ log (log4j, logback, slf4j, log4net) และไม่ได้ใช้ stdout
  • Application มี code เพื่อทำการรวม log และเขียน log โดยไม่อาศัย tool จากภายนอก

12. Admin Processes

สร้าง process ให้ทำงานแยกส่วนเฉพาะงาน เพื่อจัดการ process ของ application ที่ทำงานบน environment ตัวอย่างเช่น มี shell script เพื่อควบคุม proces หรือ database migration เป็นต้น

Factor Assessment Chart

ตัวอย่างตารางสำหรับทำ Application Assessment ว่า application มีความเหมาะสมที่จะ replatform ไปยัง cloud native platform หรือไม่ โดยถ้า Application ตรงตามข้อกำหนดก็จะได้ 1 แต้ม

FactorCompliant?Effort to Comply
Codebase
Dependencies
Configuration
Backing Services
Build, Release, Run
Processes
Port Binding
Concurrency
Disposability
Dev/Prod Parity
Logs
Admin Processes

หลังจากได้ทำ assessment กับทุก application แล้ว ก็สามารถลำดับ application ที่เหมาะสำหรับ replatform จากแต้มเยอะสุด ในกรณีได้แต้มที่เท่ากัน ให้ดูพิจารณาจากความยากในการปรับเปลี่ยน

จากข้อมูลนี้ก็จะทราบว่า application ไหนเหมาะที่จะย้ายไปยัง cloud native platform ทั้งนี้ยังต้องพิจารณา Factor อย่างอื่นรวมด้วยเช่น Application ที่ย้ายไปยัง cloud native platform ช่วย Business ให้บริการลูกค้าหรือผลตอบประกอบการที่มากขึ้น รวมถึงความพร้อมของทีม คนที่เกี่ยวข้องและเวลา เพื่อใช้ในการตัดสินใจ replatform application ให้ทำงานบน Cloud