Cloud Native Lanna 2022 (DevMountain)

วันนี้มาฟัง Online ระหว่าง Clear งานไปก่อนทำธุระช่วงเย็นก่อน น่าจะครบนะ หัวข้อที่ฟังมี ดังนี้ เยอะมาก มาครบทุกค่ายของ Cloud ในไทย 555 >> AWS / GCP / Azure / Alibaba / Huawei / Proen (เพิ่งรู้ว่าทำ Cloud จดไว้ใน List และ) โดยหัวข้อที่จดมามีดังนี้ครับ

LET'S BUILD A DEVELOPER PORTAL WITH BACKSTAGE

  • Platform Engineering
    • Practice + Standard ของการสร้าง Software โดยที่ตัวนี้มันจะเป็น Self-Service ที่ช่วยให้ Dev เข้ามา Build / Operate เรียกว่า Infra 4 Development ได้มั้ง ทำตัว Internal Developer Platform (IDP)
    • ตัว DevOps / DevSecOps ถูก Include มาในนี้แล้ว
    • ปีนี้อยู่ใน Gartner Trend 2022
ฺBackstage in IDP
  • Backstage คือ อะไร ?
    • Framework ทำ IDP สำหรับ DEV (Require Dev Skill - React / Yarn / TypeScript / Git Docker / PostgreSQL เป็นต้น)
    • พัฒนาจากทีม Spotify ที่อยู่ในระดับ Incubation (มีหลายคนเข้ามา Contribute) ไม่ใช่เป็น Sandbox
    • รวม Practice + Standard มาให้ DEV ใชัสะดวก สร้าง Template จัดการ Practice + Standard
  • ทุกอย่างใน Backstage เป็น Plugin โดยมีหลายส่วน ได้แก่
    • Software Catalog - Portal ของ System ที่สนใจ
      • Asset Inventory ของ Software ในรูปแบบ YAML โดยแบ่ง Type ตาม Kind (Level + Drill Down) เช่น Domain / Component เป็นต้น
      • ถ้าจะดูความสัมพันธ์ ใช้ Catalog Graph บอกว่า Component ที่สนใจ สัมพันธ์กับ Domain อะไร รวมถึงมี API อะไรเปิดไว้เป็นต้น
      • ตัวอย่าง Catalog: backstage/catalog-info.yaml
      • Activity ของ Dev + Test
      • หรือ Integrate กับ Tools อื่นๆ ได้ เช่น Lighthouse / Sentry / K8S เป็นต้น
    • Software Template
    • Software Techdocs
      • ใช้ Markdown เขียน Doc จากใน Template ให้วางอยู่ใน Folder docs ของ Code
      • ที่เหลือเติมรายละเอียดจากใน Git
  • อนาคตของ Backstage: VMware Tanzu - เอาไปใช้แล้ว / ตอนนี้ RedHat เข้ามาร่วมด้วย / Spotify มี Backstage Subscription ด้วย (หลาย บ transform เป็น Tech จริงๆ)

Resource:

MODERN APPLICATION PATTERNS AND HOW TO BUILD THEM ON AWS

  • คิดว่าน่าจะอันนี้นะ Microservice พอดีฝั่ง Online ตัดมาเรื่อง Decoupling แม้ว่าพอจะระเบิดจาก monolith > microservice การแยกมันออกมา Decoupling มี Cost
  • Type of Decoupling - โดยหลังจากนี้มา Focus ที่ Temporal Coupling ถ้าเป็น Code จะเป็นการ Call กับ แต่พอมาส่วนของ Microservice จะเป็นเรื่องของการสื่อสารและ
- Sync / Async Pattern
  • Synchronous request-response model
    • จุดเด่น low latency / Simple / Fail Fast
    • จุดด้อย ต้องหาทาง Handle Receive Error / Receive Throttling (รุมยิง)
  • Asynchronous Point to Point Model (Queue)
    • แก้ปัญหาแบบแรก โดยเพิ่ม Message Queue ขึ้นมาตรงกลาง
    • จุดเด่น
      • มันจะลด Temporal Coupling ถ้างานชิ้นนั้นมีปัญหาเพิ่ม Dead Letter queue เพือเก็บไว้
      • 1 Receiver จัดการกับ message ได้ที่ละอัน แต่สามารถเพิ่ม Receiver เพื่อมาจัดการ Message ได้ (Consumption Rate)
    • จุดด้อย
      • ต้องมาจัดการ Correlation ID (Key บอกว่าของใคร)
      • เก็บ Backlog กรณีที่ Fail ต้องเก็บเวลาเท่าไหร่ จนกว่าจะได้รับคำสั่งใหม่ และสุดท้ายพอมีเคส Fail แล้วเราจะจัดการงานใหม่ งานที่ Fail ให้มันสมดูลกัน (Fairness) ได้อย่างไร
    • Tools Amazon Simple Queue Service (SQS) / Amazon MQ
  • Asynchronous Point to Point (Router)
    • จุดเด่น มี Logic จัดการกับ Message ได้
    • จุดด้อย Increate Location Coupling / ตัว Sender มี Logic ของตัวมันเอง ทำให้ใช้เวลามาขึ้น
  • Async Message-Router (Bus)
    • มาแก้ปัญหา อันแรก Location Coupling
    • Tools Amazon EventBridge
- Event Driven Architecture
  • Event - สัญญาณที่บอกการเปลี่ยนแปลงของระบบ //Immutable แก้ไม่ได้
    • Sparse มีข้อมูลที่สำคัญ เช่น Key แต่ถ้าน้อยไป Receive จะมารุมขอเพิ่ม บ่อย อาจจะทำให้เกิดได้ DDOS
    • Full State Description มีข้อมูลครบกว่า Sparse แต่ต้องระวัง เพราะ Field เยอะต้องมี Compatible ระหว่าง Version และ Cost ที่จัดเก็บ
  • Choreograph - Subscripting Event และรอ Notify
  • Event Uniqueness ต้องทำ
    • Idempotency ถ้าได้ Event ซ้ำต้องประมวลผลได้เหมือนเพิ่ม เช่น ถ้าทำไปแล้ว ต้องไม่ทำ หรือทำแล้วผลเท่าเดิม
    • Idempotency Key - ป้องกัน deduplication
  • Orchastate Business Domain
    • BPMN มาจัดการ Business Flow ไม่ต้องเขียน Code ผมมองว่าเป็น BPMN App แบบนึง
    • Tools Amazon Step Functions: ใช้ UI Design Workflow / Code CDK / Python ได้
  • Demo Amazon Serverless Espresso ภาพนึกถึงพวก Flow ในร้าน KFC เลย

Resource:

EVERYTHING EASY DEPLOY, SCALE AND MANAGE IN DOMETIC CLOUD

  • เกริ่นถึงเรื่อง Game ที่บางทีก็ Lag ค้าง หลายคน เรื่องของ Infra ไม่ใช่เรื่อง Server นะ แต่จริงๆ แล้วนอกจาก Server / Bandwidth หรือ Package Loss แล้ว มันขึ้นกับการ Design Infra ด้วย อย่างเคสของ Game Lag ที่เจอ Root Cause - Network Buffer ไม่พอ
  • ดังนั้น Design สำคัญ มองถึงตอน Operate ด้วย
    Simplify Design + Operation = Availability + Performance
Simplify Design ของ Proen
  • Proen Any Cloud - เพิ่งรู้ว่าเป็น Cloud Provider อีกเจ้าในไทย (Domestic Cloud) ทำได้ private / public / hybrid หรือ จะทำ Multi-Cloud โดยรองรับ
    • Market Place - เอา SAAS มา Deploy ได้เลย
    • DevOps Flow มีนะ ฝัง Dev เข้าไป Config ได้เลย หรือ K8S มีนะ
    • Monitor ก็มีนะ

Resource

SECURE SOFTWARE SUPPLY CHAIN FOR K8S APPLICATIONS

  • AWS ไปแล้วสว Google ต่อเลย
1. Software Supply Chain Security
  • Supply Chain สมัยนี้หลายอย่าง เราไม่ได้มาลงมือทำเองแล้ว บางอันเราก็ใช้วัสดุดิบจากแหล่งอื่นๆหมด - ถ้าใน IT อย่างเราจะเป็น Dependency
  • ในมุมของ Container Security มาจาก 4C: Cloud Provider / Cluster / Container / Code + Dependency
  • ทำไม Supply Chain ถึงสำคัญ มันไม่ใช้เรื่องใหม่นะ และเด่นๆ SolarWinds
  • Trend ตอนนี้ Supply Chain เพิ่มขึ้นนะ
  • Software Supply Chain Security: Attack Vector มาจากไหนบ้าง - ทุกจุดใน CI/CD ได้เลยตามรูป
  • CI/CD Core Principle (จดๆไว้ก่อน มันจะไปตีกับ AZ-40 ในหัวไหมเนี่ย)
    • Repeatable + Reliable Process
    • Automate Everything
    • Version Control
    • Build in Quality
    • Do the hardest parts first
    • Everyone is reposible
    • Accumulate Trust - ตรงนี้ส่วนของ Security และ Supply Chain Security จะเป็นหนึ่งในนั้นด้วย
2. Google Open-Source Security - Contribute ด้านนี้ยังไง ที่เด่นๆ
  • slsa.dev - guideline ในการจัดการ supply chain risk
    • Build Integrity - แก้ Code แอบมาใส่หลัง Build จบไม่ได้ / ตัว CI CD ของเรา Secure พพอ หรือยัง
    • Source Integrity - Code Change History / Code Review / Compromised Source Control
    • Dependency - Ref มั่วไหม หรือ มีความเสี่ยงอะไรบ้าง
      Note: มีการจัด Level ว่าแต่ละองค์กรทำอะไรไปบ้าว ดังนี้
  • deps.dev - DB ของ Google ที่แสดงถึง Insight ของ Open-Source Project มี Dependecy ที่เอามามี Quality ยังไง
  • Scorecard - Risk Assessment System
  • sigstore.dev - ช่วย Sign Service
  • Container Analysis Scanner + Metadata Storage :
    • Grafeas - metadata ของซอฟต์แวร์ ถ้ามี CVE จะเก็บไว้ในนี้ และควบคุมการ Deploy //พอมาอ่านอีกที มันคล้ายกับ Backstage ไหมนะ
    • Kritis - enforces deploy-time security policies for K8S
  • Voucher - เอาไปเป็นส่วนนึงของ CI/CD ว่า Container เรามี CVE อะไรค้างไว้บ้าง และไป ทำเป็น Metadata และ Mitigate ตอน deploy
  • Security Tools Policy
    • สมัยนี้ Tread As a Code หมดแล้ว
    • เน้นการ Shiftleft เข้ามามากขึ้น หรือทำ DryRun
    • Break Glass ลงไปก่อน
3.Software Delivery Shield
  • จากทั้งหมด ถ้าลงเองมันยาก ใช้ Service ที่มีตัว Software Delivery Shield
    • Code (IDE Plugin) - ดูคล้ายๆ Sonar Lint
    • Cloud Build - มันจะ Stamp Metadata ไว้ Build จากไหน มี CVE อะไรบ้าง
    • ทำ Policy คุมใน cloud Run เช่น ตรวจ Image ก่อน deploy หรือ บอกว่าต้อง Build จาก Trust Source (Binary Authorization)
    • Runtime Security Insight เป็นต้น
  • รองรับ 3rd Party Integration: Synopsis Black Duck / CloudBees CI / Digester / Terraform

Resource:

HYBRILD CLOUD SECURITY CHALLENGES

  • Hybrid Cloud Security Working group - บอกว่า Hybrid Cloud มีความเสี่ยงอะไรบ้อง ป้องกันอย่างไง แล้วมี Guideline ในการจัดการยังไง
  • Hybrid Cloud = Public + Private Cloud ที่ต้องมี Link Connection เชื่อมกัน แต่ละแบบจุดเด่น
    • Private - ข้อมูล Sensitive เราสามารถ Control ได้ดี
    • Public - Tech ใหม่ เช่น AI / Serverless และต้องการ Scale บางส่วนได้
    • Security ที่ใช้กับเทคโนโลยีทังฝั่ง Private / Public อาทิ เช่น การทำ Pseudonymization (น่าจะเขียนถูกนะ) Control Data ชุดเดียวกันบน Public (ไม่ Expose ออกไป) / Private
    • Control Cost - Private (capex) / Public (opex)
  • Hybrid Cloud Implementation
    • Layer 3 Network: IP / VPN / Dedicate line
    • Multi-Cloud Mangement Enable by Cloud Broker -
    • Consistent Hybrid Cloud - ต้องหา Service ที่ match กัน ทั้ง Private + Public เผื่อต้องโยก resource ข้ามกันไป แล้วระบบไม่พัง
  • Share Responsibility in Hybrid Cloud
  • Hybrid Cloud Risk - อาจจะมาจากตัว Cloud เอง / Data Center ของเรา หรือ ช่องทางสื่อสารของ site
    • DDoS - โจมตี เพื่อแยก Hybrid Cloud - อาจจะโจมตี Link ระหว่าง 2 Site
    • Data Leakage - เกิดเมื่อมีการโยก Data ระหว่าง Private/Public
    • Perimeter Protection Risks
    • Compliance Risks - Data ควรอยู่ที่ไหน นึกถึงพวก PDPA เลย
    • Misaligned SLAs - Cloud Provider แต่ละเจ้า + Vendor ที่ดูแล DC เรา มี SLAs ต่างกัน ทำให้เวลามีปัญหาเกิดขึ้น เราจะจัดการยังไง
    • Misaligned of Cloud Skill Sets - เช่น จากเดิมเคยดู DC ขององค์กรมาก่อน พอมาเช่า Public Cloud แล้วจะเอา SE ของเราเข้าไปได้ แต่จริงๆ มันไม่ได้
    • Gap in Security Control Maturity - Public + Private มองเท่ากันไหม
    • Comprehensiveness of Security risk Assessment - ส่วนใหญ่จะพลาดเรื่องนี้ เพราะไปทำแยกกัน แต่ไม่ได้ทำในภาพรวม
  • Security Challenge
    • Cross Cloud Perimeter Security
      • Perimeter Protection
      • Access Control - ปกติจะมี 2 กลุ่ม Ser คนนอกเข้ามาใช้ Service) / คนในองค์กรที่เข้ามาใช้ หรือ จัดการ Service ต่างๆ และพวก connection validation
      • Interface Security - เปิด Link ขึ้นมา 1 จุด เช่น เชื่อมระหว่าง Private /Public เรามีวิธีการจัดการ หรือควบคุมอย่างไร
    • Cross Cloud Transmission Security
      • Network Connection
      • Communication Transmission
    • Cross Cloud Storage + Compute Security ในมุมของ Bank จะแยกเป็น Tier ว่า App เราควรเป็นแบบไหน เช่น Tier1 มี HA ใน DC (Private จัดการอย่างไร) และบน Public Cloud ทำอย่างไร ต้องในเทียบกันไหม รวมถึง SLA แบบไหน มีมุมที่ต้องสนใจ ดังนี้
      • Data Storage
      • Computer resource - distribute อย่างไร
      • Back restore
    • Cross Cloud Management Security
      • Identity Authentication - ทุกคนควรใช้ Account เดียวกัน Access Resource นอกจากคนแล้ว พวก Service จัดการอย่างไร
      • Authorzation Management - เมื่อผ่านด่าน Authentication ตัว user นั้นควรจะมีสิ?ธิใน resource อะไรบ้าง app ไหน หรือ ถ้าเป็น DB ต้องระวังในส่วนของ Data
      • Key Management - ควรจะอยู่ที่ไหน
      • Operation & Maintenance - มุมด้าน Infra ถ้ามี Single Control Pane มาช่วยจัดการะช่วยได้มาก และสะดวก
      • Operation Management - ถ้ามี cloud แล้ว ทีมที่ดูงาน Operation เช่น Batch ต่างๆ จัดการอย่างไร ให้มันล้อกัน

Resource:

TISCO BANTAO: FROM CRISIS TO OPPORTUNITIES WOTH LOW CODE&CLOUDS

  • BANTAO = บรรเทา //ตอนแรกอ่าหัวข้อ ตอนแรกคิดว่าบ้านเต่า
  • Intro Bank ใช้ Cloud กันหมดแล้วนะ
  • BANTAO - ทำในช่วง COVID-19
    • ทำให้ต้องเร่งพัฒนาระบบ 5 Days เพื่อให้ตอบสนองกับลูกค้าสินเชื่อ ต้องดูในแง่ Business / กฏหมาย เพื่อช่วยให้ลูกค้าได้รับผลกระทบจาก COVID19 ให้ทันท่วงที เพราะผลบกระทบมันวงกว้าง
    • และมี User Experience ที่ดี - ได้ยินแว๊บว่าต้องมี Sync Data บางส่วนมาในบน Cloud ระบบบรรเทา
    • แถมทีมงาน DEV ต้อง WFH - Amazon Workspace จัดการ Environment + ลดการสื่อสารลง Miro + MS Team
    • แต่ต้องคง Security ตาม Standard ของ Bank
  • Tech Stack ของ BANTAO -
    • จะเห็นว่ามี Challenge จาก AS400 ซึ่งอยู่บน On-Premises ที่ไ่มี API ต้อง SFTP + เข้ารหัส ไปที่ Cloud
    • ส่วน ฺBANTAO อยู่บน AWS Cloud เพราะสร้าง Resource ได้เร็ว / Scale ได้ง่าย + Cloudflare มาจัดการ Traffic มากๆ
    • Flow CI/CD อยู่บนนี้ด้วย
  • นอกจาก BANTAO แล้ว มี Digitial Form Platform Process ช่วยให้การจัดการ Form เป็นเรื่องง่าย แอบสงสัยตัวนี้ เป็น Low Code หรือป่าวนะ
  • COVID-19: Digital Transformation ตัวจริง

Resource

CENTRALIZED LOGGING STACK ON K8S PLATFORM

  • Centralize Logging - เอา Event ต่างที่เกิดขึ้นทั้ง System / App และอื่นมารวมกันที่ถังกลาง เพื่อช่วยให้การติดตามปัญหาได้สะดวก ถ้าแบบเดิมเวลาเกิดปัญหาเราต้องเข้าไปไล่ส่องให้ทุกๆ Microservice เพื่อมาหา Log วึ่งมันเปลืองพลังมาก
  • Centralize Logging Benefit
    • ง่ายกับการค้นหา และจัดการ
    • user access management
    • จัดการ Storage ได้ดีขึ้น หรือจะ Apply Policy ลงไป
    • Event Log Correlation - เอา AI มาช่วย Track
  • Centralize Logging Tech
    • Data Collector - ปกติจะเป็น Agent ไว้กับ VM / Container
    • Buffering
    • Data Processing
    • Index + Storage
    • Visualization
  • K8S - Container Orchestration จัดการ Self-Healing / Load Balancing / Auto Scale และ Rollout+Rollback เอาไว้จัดการการ Deploy เป็นต้น
  • Lagacy VM Base Pain point - เวลาเกิดปัญหาในแต่ละ Component ต้องเข้าไปใน VM นั้นๆ เพื่อมาดู
    • Fluenttd - Data Collector Agent
    • RabbitMQ
    • logstash - เอาไว้ตัดแต่ง Log
    • open distro จัดเก็บ Log + indexing
    • kibana - visualize
  • Modernize ตอนนี้ปรับไปวางบน K8S หมด แล้ว Key นอกจาก Log Infra แล้ว ต้องมา Modernize App ด้วย โดยมีการแก้ ดังนี้
    • Fluenttd > Fluentbit แทน เพราะกิน Resouces น้อยกว่า 100 เท่ากัน
    • เปลี่ยน RabbitMQ > Kafka เพราะเหมาะกับ Streaming มากกว่า รวมถึง Scale ได้สะดวกกว่า RabbitMQ ต้องเพิ่ม Compute ให้ Instance เดิม
    • Logstash - ปรับ Config ลด Rule ที่ไม่จำเป็น ทำให้รับ Load จาก Kafka ได้มากขึ้น
    • Open Distro > OpenSearch
    • OpenSearch Dashboard และเปิดช่อง Dev หรือทีมอื่นๆ เข้ามาตรวจสอบ
  • Pros & Cons
    • Pros : Open source / Realtime Logging / Easy to install (ใช้ผ่าน helm) / Easy to Patch จากเดิมต้องมาปิด VM Patch OS ตอนนี้เตรียม image ให้ secure และ deploy / K8S Pros
    • Cons: Community Support / Learning Curve
  • Lesson Learned:
    • ถ้า deploy stateful app พยายามทำให้มัน HA ด้วย เพราะบางที data อาจจะ corrupt ได้
    • ถ้า deploy stack นี้บน Cloud ต้องระวังเรื่อง Data Transfer ระหว่าง Region ด้วย

Resource:

EXTRAME K8S HA ACROSS CLUSTER / REGION WITH CLUSTER MESH

- Why Extreme HA ?
  • Application ตอนนี้ Critical ทุกวัน เช่น App ขายหวย / E-Commerce ช่วง 10.10 11.11 โดยที่ App 24*7
  • K8S HA By Default แต่ทว่ายังไม่รองรับเคส Extreme เช่น Fail ทั้ง Cluster ต้องเพิ่ม Cluster ขึ้นมา ถ้าจะให้ปลอดภัยสุดการแยก Cluster อยู่คนละ Region หรือ Provider เลย ตัว Hybrid Cloud กับ multi-Cloud มาตอบในส่วนนี้
- Generic failure Case
  • ทำอยู่ microservice ที่เกี่ยวข้องของ failure ไปซะงั้นทำให้ Flow สะดุด
  • Config ผิด เช่น ใส่ LABEL/ชื่อ ผิด พังกันทั่วหน้า อาจจะเกิดจากการ Maintain มาหลายมือ หรือ เจอสิ่งที่มองไม่เห็น เช่น space เป็นต้น
  • ตกลงกันไม่ดี อาจจะมีทีมแรกวาง K8S แต่ไม่ได้ตกลง namespace + request สุดท้าย Resouces ไม่พอ
- Solution

การแก้ปัญหา Partially Microservice Failure ด้วย K8S – ซึ่ง Partially Microservice Failure การที่ Set ของ Microservice ที่ทำงานด้วยกัน เกิด Fail ไปตัวนึงทำให้ Flow งานสะดุด

  • Sol1 ใช้ DNS + Load Balance มาช่วย ถ้า fail ให้ไปจิ้ม K8S อีกชุด > ไม่แก้ปัญหาตรงเรื่องนี้ ย้ายไปทั้งชุดเลย ถ้า User ทำงานอยู่ไปเริ่มต้นทำใหม่เลย
  • Sol2 Set Worker ให้กระจายข้าม Region > ทำได้ แต่มีปัญหา High Latency / Unstable Cluster (Down แบบแปลกๆ) ถ้าอยากเร็วใช้เงินแก้ปัญหาเพิ่มเส้นเชื่อมตรง 
  • Sol3 ใช้ KubeFed ทำ Federation สร้าง Management Console มาจัดการ Cluster ในแต่ละ Region แต่ซับซ้อนมาก เพราะนอกจากดูว่าจะจัดอยู่ใน namespace ไหน / resource เท่าไหร่ / Balance Cluster แต่ไม่แก้ปัญหานี้ตรงๆ และใช้งานยาก (huge complicate) และตัว Tools นี้ยังไม่ GA
  • Sol4 ใช้ Cilium 
    • ทำ Cluster Mesh - ให้ Cluster A และ ฺB คุยกันได้ในบาง Service ที่สนใจ
    • Less Effort ไม่ต้องแก้ YAML เยอะ
    • สามารถกำหนด Affinity ให้เชื่อ Local ก่อนได้ และแก้ปัญหาของ Sol2 ได้ด้วย (Ver 1.12 Jully 2022)
    • Cilium Network Mode
      • Tunneling Mode (Default) - VXLAN
      • Direct Routing (ถ้า IP ของ Pod เป็น IP แท้เป็น)
      • Transparent Encrypt Mode เปิด IP Sec แต่กิน Resouces มหาศาล
- CLUSTER MESH USE-CASE
  • HA - บน Cloud / On-Premises / Hybrid ก็ได้
  • ทำ Share Service ของ Internal Use-Case
  • Separate Service (Apply จาก Share Service) แยก Service Stateless / Stateful

Resource:

CREATE HIGHLY SECURE AND RESILIENT CLOUD-NATIVE APPS WITH MS AZURE

Scale + Secure App มันต้องมีอะไรท้าท้ายบ้าง
  • Design - สิ่งที่ต้องสนใจ
    • Data Management
    • Design & Implement - เอาง่ายการต่อ App DB ควรทำ Connection Pooling รวมถึง Logic ในการเขียน Code ของเราด้วย
    • Messing - ทำอย่างไงให้ของไปถูกเป้าหมาย
    • ดูเพิ่ม Cloud Design Pattern
  • Capacity
    • เข้าใจ Nature ของการ Event ต่างๆ ก่อน ว่ามีลักษณะแบบไหน Peak ช่วงแรก หรือ Peak เป็นช่วง เช่น จอง iPhone / จองวัคซีน
    • Performance นอกจากเรื่อง Design +Code เวลา Scale ต้องเผื่อเวลา Provisioning ของแต่ละ Resource กดปุ่มได้ปั๊บ
  • Protection
    • ใช้่ Zero Trust Principle - Azure มีตัว Microsoft Defender
    • ส่วนที่มีปัญหาจะดดนประจำ Jump Host / Build Server
  • Insights - เราบอกได้ไงว่าเอาอยู่ หรือไม่อยู่
    • Eye มาดู Application Insight - APM ดู Telemetry trace ว่าปัญหาเกิดจากอะไร เช่น อาจจะเกิดจาก Logic ของ Code แต่ DB ทำงานปกติ ทำให้ App ของเรารับ Load ได้มากขึ้น ใน Resource เท่าเดิม
  • Uninterrupted - ถ้ามีเหตุคาดไม่ถึงทำอย่างไร ?
    • Plan for Global Distributuion - Multi region / CDN / Front Door เป็นต้น

Resource

DOUBLE 11 BEHIND THE SCENES

สถิติของช่วง Double 11
  • Alibaba Cloud เป็น Cloud อีกเจ้านึงที่มาทธุรกิจใจไทย มี Region BKK แล้วนะ Double11 มี 4 Key ที่ช่วยให้ราบรื่นมาสะดุด ได้แก่
    • Cloud Native Technology - Scale Software
    • Hyper-Scale Data Centers - Scale hardware
    • Intelligent Robot - เอามาจัดการคลังสินค้าได้รวดเร็ว
    • Live Streaming + AI Transformation
  • Key อีกอันนอกจาก 4 Key ข้างต้นแล้ว ยังมีตัว PolarDB ที่เป็น distribute database ที่มาช่วยจัดการข้อมูลที่ load เข้ามาจำนวนมาในช่วง 11
  • EMAS Product - จัดการ API ต่างๆของ mobile หรือจะไปทำ Super App ก็ได้

Resource

EVERYONE CAN BE A DEVELOPER WOTH HUAWEI CLOUD APPCUBE

  • สำหรับ Huawei Cloud เปิดตัวมา 4 ปีในไทยและ ตอนกันยามีจัดงาน Huawei Connect 2022@BKK ไปด้วย
  • Trend ตอนนี้ทุกอย่างไปไว้ขึ้น และ
    • Expected ของผู้บริหาร(Hours) กับคนทำงาน (Week ... Month) ต่างกัน
    • การมาของ Cloud ทำให้การ Provision resource ไวขึ้น
    • การเพิ่มคนอัดๆลงไปก็ไม่ช่วยในงานไวขึ้น เพราะมีงานความซับซ้อน
  • ดังนั้น No Code / Low Code มาเป็น trend (ของ Gartner) ที่มาตอบโจทย์ตรงนี้ เตรียมด้าน Tech ให้พร้อม และจะได้เอา Business User เข้ามาจัดการ บน Huawei จะมี Service AppCube ที่เป็น Low Code/No Code
  • AppCube ตอนนี้ใช้ใช้ในจีน นอกจาก No Code/ Low Code แล้วยังต่อกับ Code ได้ด้วย โดย Feature ของตัวนี้
    • Metadata - สร้างจาก DB ที่มี หรือจะเอา Excel Import เข้าไปก็ได้ หรือ Connect กับ OBS / S3 ก็ได้นะ
    • No Code - ถ้าเอาจาก template ที่มีให้
    • Low Code
      • Customize จาก Template และปรับตาม Screen แบบต่างๆได้
      • ถ้าไม่เชี่ยววาดใส่กระดาษ ถ่ายรูป และให้ตัว DMAX (AI) สร้าง UI ก็ได้
      • รวมถึงการทำ Visualize ออกมาได้ ถ้าทำเสร็จ ทำเป็น template เพื่อ Re-used ต่อได้
    • Business Process Support - ทำ Workflow ที่ใช้งานกันบ่อยๆได้ เช่น Approval / ลา เป็นต้น
    • มี Flow Dev ในตัว
      • ขยับไป Deploy Sandbox เพื่อ Test
      • ถ้าผ่านแล้วขยับไป Production
  • ปีนี้ Low Code มาแรงจริงๆ เหมือน Feature จะพอๆกับ Power Platform ของทาง MS ด้วย

Resource :

ADD AI TO YOUR APP WITH AZURE CUSTOM VISION SERVICE

  • ทุกวันนี้ AI มันเกี่ยวกับตัวเราหมดเลย
    • ปีนี้ AI จากเดิมที่แบบเราต้อง พิมพ์ คลิก บอกมัน
    • ถัดมายุคของ siri / google assistant
    • ปีนี้มาวาดรูปได้แล้ว midjourney / แนะนำ Code ได้
  • คอนนี้ App เริ่มมี AI เข้ามาแล้ว โดยการทำให้มี App มี AI ได้ต้องทำ Machine Learning ให้มันเรียนรู้ จากข้อมูล > train > Model ปกติกว่าจะได้ Model ต้องใช้เวลา+compute ที่เยอะ
  • จากปัญหาข้างต้น ใช้ Cloud เข้ามาช่วยสิ ทาง Azure แบบ End-User 2 กลุ่ม
    • End-Users (Citizen Developer) - มีความรู้ Business แต่เขียน Code ไม่เป็น ใช้ Low Code / No Code - PowerPlatform - มี AIBuilder
    • Developer - เขียน code ได้ หรือจะใช้จาก API ของ Cognitive Service)
  • จากนั้นจะเป็น Demo Azure Custom Vision Service ที่อย่ในส่วน Compter Vision เรียนรู้จากภาพจานสีแดง/ดำ
    • สร้าง Resource บน Azure Custom Vision? -Learn
    • ใช้ Custom Vision - Home ในการ Train
    • ถ้า Model แล้วก็ Deploy Model ขึ้นไป และนำ EndPoint (WebAPI) ไปใช้งานกับ APP ของเราต่อ
  • พอ Huawei มา Low Code / MS มาต่อ Low Code 555

Resource:

Reference

Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.

Tags

Related Posts