Monthly Archives: January 2023

Business Outcomes Lean Canvas

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…

Run Docker without Docker Desktop on macOS

จากที่ Docker Inc ได้ประกาศเรื่อง Docker Desktop ที่จะไม่ free สำหรับหน่วยงานที่มีรายได้มากกว่า 10 ล้านดอลลาร์ แต่ก็คงใช้ได้ฟรีสำหรับหน่วยงานที่มีการใช้งานน้อยกว่า 250 คน และมีรายได้น้อยกว่า 10 ล้านดอลลาร์ ใช้งานส่วนตัว การศึกษา หรืองานที่ไม่แสวงหาผลประโยชน์ เช่น open-source project เป็นต้น โดยจะเริ่มบังคับตั้งแต่ 31 มกราคม 2565 เป็นต้นไป ซึ้งบริษัทใหญ่ๆ ที่เข้าเกณท์ก็ต้องจ่ายต่อการใช้งานที่ 5$ ต่อคน ต่อเดือน และก็มี plan อื่นๆ เช่นจ่ายต่อ Team หรือ ต่อหน่วยงาน บริษัทที่มีรายได้ขนาดนี้ก็ไม่น่ามีปัญหาอะไรในการจ่าย เพราะ Docker Inc เองก็ลงทุนเรื่อง product development ไปพอสมควร รายได้ตรงนี้จะทำให้ product พัฒนาได้อีกมาก

พอเราพูดถึง docker ก็จะมีหลายคำที่เราต้องทำความเข้าใจ ก่อนจะเข้าเนื้อหาการติดตั้ง docker บน macOS

Container เป็นรูปแบบของ software ที่สามารถทำงานได้บนเครื่องที่มีสภาพแวดล้อมแตกต่างกันได้ จากการที่เราได้ pack application และสิ่งที่ application ต้องการใช้ให้อยู่ด้วยกัน (package) เช่น application code, libraries, configuration, runtime/server, operating system เป็นต้น

Docker Inc เป็นบริษัทที่พัฒนา docker software ที่ช่วยให้เรา develop, test และ run application ในแบบ container ได้ง่าย ทั้งที่เป็น open source และไม่ใช่ open source

Docker Engine เป็น open-source software ทำงานบน Linux OS ช่วยทำให้ container ทำงานบน Linux kernel ได้ หน้าที่ของ software ตัวนี้คือจัดการ container life cycle เช่น start, stop, delete และจัดการ resource ของเครื่อง (compute, memory, storage) สำหรับให้ container ทำงานได้แบบแยกจากกัน ป้องกันไม่ให้ process อื่น สามารถเข้าถึง หรือ share resource กันได้ เพื่อจุดประสงค์ด้านความปลอดภัย ทั้งนี้ Docker Engine ทำงานได้เฉพาะใน Linux OS

Docker CLI เป็น command line สำหรับเพื่อติดต่อกับ Docker Engine เพื่อใช้งาน container ประกอบด้วย docker และ docker-compose ซึ้งเป็นเป็น open-source software

Docker Desktop เนื่องจาก Docker Engine ทำงานอยู่บน Linux เท่านั้น ถ้าเครื่องเราเป็น Windows หรือ macOS ก็จะไม่สามารถใช้งาน container ได้ ทั้งนี้เราต้องสร้าง Virtual Machine (VM) ที่เป็น Linux OS สำหรับ docker engine ในเครื่องของเราก่อน ถึงจะสามารถใช้ container ผ่าน VM ที่สร้างขึ้นได้ ตรงนี้จึงเป็นต้นกำเนิดของ Docker Desktop ที่ทำให้เราสามารถใช้ container บน Windows/macOS ได้ โดยจะช่วยเรื่องการจัดการ VM และอื่นๆ ที่เกี่ยวข้องกับการใช้งาน เช่น Networking, Virtualization, สั่งงาน Linux OS เป็นต้น ทั้งนี้ Docker Desktop ถูกออกแบบมาให้ใช้สำหรับเครื่อง Desktop เพื่อ Develop software ไม่ใช่สำหรับ run container บน Production หรือใช้งานจริง

โดยสรุปแล้ว Docker Desktop ไม่ใช่ core technology สำหรับ run container จุดประสงค์คือเป็น Software ที่อำนวยความสะดวกให้เรา Develop software ในแบบ container บน OS ที่เป็น Windows หรือ macOS ได้ง่ายขึ้น ไม่ต้องจัดการอะไรให้ยุ่งยาก ดังนั้น Docker Inc เองก็เลยพยายามที่จะทำรายได้จาก product ตัวนี้กับบริษัทใหญ่ๆ เพราะตัวเองก็ Develop อย่างยากลำบาก รวมถึงค่าใช้จ่ายที่ได้ลงทุนไปนั่นเอง

จากที่อ่านถึงต้องนี้คงตอบคำถามได้แล้วว่า ถ้าเราไม่ใช้ Docker Desktop ได้มั้ย และต้องทำยังไง (อย่าลืมว่า docker, docker-compose, docker engine เป็น open-source) เราต้องมีเครื่องที่เป็น Linux สำหรับ docker engine โดยต้องมี software เพื่อทำ virtualization สำหรับ macOS สามารถใช้ hyperkit หรือ virtualbox ก็ได้ ตัวอย่างนี้ผมใช้ virtualbox โดยทำได้ตามขั้นตอนต่อไปนี้

  1. ทำการ uninstall docker desktop ออกก่อน ด้วยการลบ /Applications/Docker.app สำหรับ macOS แต่จะมี file ค้างอยู่ แนะนำให้ทำตามขึ้นตอนนี้ เพื่อ clean ข้อมูลที่ค้างอยู่ออก หรือ search google ด้วย “uninstall docker desktop on macos”
  2. Install docker, docker-machine และ docker-compose (ถ้าต้องการใช้)
❯ brew install docker docker-compose docker-machine 

3. Install VirtualBox

❯ brew install --cask virtualbox
❯ brew install --cask virtualbox-extension-pack

4. ถ้าเราสั่ง create docker-machine เลยหลังจากนี้จะติดปัญหาเรื่องข้อจำกัดของ IP สำหรับ Host-Only network ใน VirtualBox version ใหม่ โดยจะได้ error “VBoxManage: error: Code E_ACCESSDENIED (0x80070005) – Access denied (extended info not available)” อ่านเพิ่มเติมได้จาก redit สามารถแก้ปัญหาด้วยขั้นตอนดังนี้ อ้างอิง

  • สร้าง folder vbox ใน directory /etc
  • สร้าง file networks.conf ภายใน folder vbox และเขียนข้อมูลในไฟล์ตามด้านล่าง
* 0.0.0.0/0 ::/0

5. create docker-machine

❯ docker-machine create -d virtualbox default
Running pre-create checks...
Creating machine...
(default) Copying /Users/pongsakk/.docker/machine/cache/boot2docker.iso to /Users/pongsakk/.docker/machine/machines/default/boot2docker.iso...
(default) Creating VirtualBox VM...
(default) Creating SSH key...
(default) Starting the VM...
(default) Check network to re-create if needed...
(default) Found a new host-only adapter: "vboxnet0"
(default) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env default

ตรวจสอบหลังจากสร้างเสร็จ

❯ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER      ERRORS
default   *        virtualbox   Running   tcp://192.168.99.100:2376           v19.03.12

ลองเล่น command อื่นๆ > docker-machine –help

6. setup docker environment เพื่อให้ docker CLI เชื่อมต่อไปยัง docker engine ที่สร้างใหม่

❯ eval $(docker-machine env default)

7. ทดสอบใช้ command docker cli

❯ docker version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.40
 Go version:        go1.17.5
 Git commit:        e91ed5707e
 Built:             Sun Dec 12 06:28:24 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.12
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       48a66213fe
  Built:            Mon Jun 22 15:49:35 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

เท่านี้เราก็สามารถใช้ docker CLI ได้ปกติโดยไม่ต้องมี Docker Desktop

Credit: ข้อมูลบางส่วนได้สรุปเนื้อหาจาก https://dhwaneetbhatt.com/blog/run-docker-without-docker-desktop-on-macos

KIND – Kubernetes in Docker

kind เป็น tool ตัวหนึ่งที่น่าสนใจสำหรับ run Kubernetes อยู่ที่เครื่องเราเองโดยใช้ Docker container เป็น nodes ของ Kubernetes ข้อดีคือจัดการง่ายและทำงานได้เร็ว ถ้าต้องใช้ script เพื่อสร้าง cluster เพื่อทำ integration test แล้ว tool ตัวนี้ตอบโจทย์ได้ดีทีเดียว ติดตั้งเพื่อใช้งานทำได้ตาม quick start

ตัวอย่าง command ต่าง ๆ สำหรับใช้งาน kind

สร้าง cluster ที่มี Master และ Worker จำนวน 1 node

kind create cluster --name test1

สร้าง cluster ที่มี Master และ Work อย่างละ Node จาก configuration file

kind create cluster --name=test2 --config kind-2node.yaml

# ข้อมูลใน File kind-2node.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker

สร้าง cluster ที่มี Master จำนวน 3 nodes และ Worker จำนวน 2 nodes

kind create cluster --name=test3 --config kind-5node.yaml

# ข้อมูลของ file kind-5node.yaml
kind: Cluster 
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker

ในกรณีที่ใช้ docker-machine เพื่อสร้าง docker engine จำเป็นต้องระบุ ip ของ docker engine ใน file config ด้วย กรณีต้องการ config ค่าอื่นๆ ดูได้จาก kind document

# หา ip ของ docker engine ด้วย
❯ docker-machine ip
192.168.99.102

# จากนั้นสร้าง config file ดังนี้
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  apiServerAddress: "192.168.99.102"
  apiServerPort: 6443
nodes:
- role: control-plane
- role: worker

การ access เข้าไปที่ node

docker ps

# test1-control-plane เป็นชื่อ Master node จากผลลัพธ์ docker ps
docker exec -it test1-control-plane bash

การ access container ที่ run ที่เครื่อง test1-control-plan ซึ้ง container runtime ใน node จะเป็น containerd นะครับ

root@test-control-plane:/# crictl ps
CONTAINER           IMAGE               CREATED             STATE               NAME                      ATTEMPT             POD ID
fd7b628af2359       296a6d5035e2d       20 minutes ago      Running             coredns                   0                   f068e76bb133e
67db85b7b5293       296a6d5035e2d       20 minutes ago      Running             coredns                   0                   1d773ed216c4e
1e94aff11ee8e       e422121c9c5f9       20 minutes ago      Running             local-path-provisioner    0                   6c9467c5cdb84
9599b04fdad77       6de166512aa22       20 minutes ago      Running             kindnet-cni               0                   1a9a398e62418
f55a566a3f556       0e124fb3c695b       20 minutes ago      Running             kube-proxy                0                   c075e7b86e928
6927ff1f38141       0369cf4303ffd       20 minutes ago      Running             etcd                      0                   92b0750af4e4c
6eaab86c31d42       94ffe308aeff9       20 minutes ago      Running             kube-apiserver            0                   34bbfc2183651
5a861837a686e       96a295389d472       20 minutes ago      Running             kube-controller-manager   0                   571c1b03041e7
7f5d355589866       1248d2d503d37       20 minutes ago      Running             kube-scheduler            0                   9d92fc037f002

สร้าง Kubernetes pod

kubectl run nginx --image=nginx

สร้าง Kubernetes service

❯ kubectl expose pod nginx --port=80 --target-port=80 --name=nginx-http --type=NodePort


# ทดสอบเรียก service
root@test-control-plane:~# kubectl get nodes -o wide
NAME                 STATUS   ROLES                  AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE       KERNEL-VERSION         CONTAINER-RUNTIME
test-control-plane   Ready    control-plane,master   18m   v1.21.1   172.18.0.3    <none>        Ubuntu 21.04   4.19.130-boot2docker   containerd://1.5.2
test-worker          Ready    <none>                 18m   v1.21.1   172.18.0.2    <none>        Ubuntu 21.04   4.19.130-boot2docker   containerd://1.5.2

root@test-control-plane:~# curl http://172.18.0.2:30108
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
root@test-control-plane:~# exit

สร้าง kube config ที่ master

cp /etc/kubernetes/admin.conf ~/.kube/config

แสดง log ของ cluster จาก kind cli

kind export logs --name=test2

ลบ cluster

kind delete cluster --name test1

Restart docker, ในกรณีที่ restart เครื่อง ต้อง start docker image ของ Master และ Worker nodes

docker start <name>-control-plane
docker start <name>-worker
export KUBECONFIG="$(kind get kubeconfig-path --name="<name>")"

Cloud Native, WHY WHAT HOW

เพื่อให้เข้าใจเรื่อง 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

กระบวนการในการพิจารณา เพื่อประเมินความเหมาะสมสำหรับการย้าย 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