ข้อเสนอเสมือนจริงทำงานได้แย่ลงอย่างมาก (ดูการทดลองในปี 2019 ของฉัน: httpsjan.rychter.com/enblog/cloud-server-cpu-performance และมีราคาสูงกว่า ข้อแตกต่างคือคุณสามารถ "ปรับขนาดตามต้องการ"ซึ่งฉันพบว่าไม่จำเป็น อย่างน้อยก็ในกรณีของฉัน และถ้าฉันต้องปรับขนาด ฉันก็ยังทำได้ เพียงแต่ว่าการรับเซิร์ฟเวอร์ใหม่จะใช้เวลาเป็นชั่วโมงแทนที่จะเป็นวินาที ฉันไม่จำเป็นต้องปรับขนาดเป็นวินาที

ในกรณีของฉัน การเรียกเก็บเงินรายเดือนทั้งหมดของฉันสำหรับสภาพแวดล้อมการผลิตเต็มรูปแบบและสภาพแวดล้อมการจัดเตรียม/สแตนด์บายที่ซ้ำกันนั้นคงที่ เรียบง่าย คาดการณ์ได้ ต่ำมากเมื่อเทียบกับสิ่งที่ฉันต้องจ่ายให้กับ AWS และฉันยังมีช่องว่างด้านประสิทธิภาพอีกมากที่จะ

สิ่งหนึ่งที่ควรสังเกตคือฉันปฏิบัติกับเซิร์ฟเวอร์จริงเหมือนกับเซิร์ฟเวอร์เสมือน: ทุกอย่างได้รับการจัดการผ่าน ansible และฉันสามารถสร้างทุกอย่างใหม่ได้ตั้งแต่เริ่มต้น อันที่จริง ฉันใช้สภาพแวดล้อม "devcloud"อื่นที่ Digital Ocean และสภาพแวดล้อมนั้นถูกสร้างโดยใช้ terraform ก่อนที่จะส่งต่อไปยัง ansible ซึ่งทำการตั้งค่าส่วนที่เหลือ

ฉันสงสัยว่า VendorOps และเครื่องมือที่ซับซ้อนเช่น kubernetes ได้รับการสนับสนุนโดยผู้ค้าที่มีความซับซ้อนซึ่งเกิดขึ้นในทศวรรษที่ผ่านมา มันดูดีในเรซูเม่และทำให้ผู้นำเทคโนโลยีรู้สึกถึงความสำเร็จที่ผิดพลาด

ในขณะเดียวกัน Stackoverflow ซึ่งมีความสำคัญมากกว่าสตาร์ทอัพส่วนใหญ่กำลังใช้งานเครื่องเฉพาะ

1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..

ดูเหมือนว่าแนวโน้มในพื้นที่นี้คือการกระโดดโดยตรงไปยังชั้นสูงสุดของสิ่งที่เป็นนามธรรม ข้ามพื้นฐานและชี้ไปที่เครื่องมือ $buzzword ไลบรารีและผลิตภัณฑ์

คุณเห็นภาพรวมของสิ่งนี้ในรูปแบบต่างๆ หนึ่งคือหัวข้อโซเชียลมีเดียที่ถามสิ่งต่าง ๆ เช่น ฉันต้องรู้ X เท่าใดจึงจะเรียนรู้ Y โดยที่ X เป็นพื้นฐาน เทคโนโลยีหรือภาคสนามที่เสถียรมาก และ Y เป็นเครื่องมือบางอย่างสำหรับผลิตภัณฑ์หรือบริการ

CORBA อยู่ที่นั่น และบางทีอาจจะเป็นเว็บสื่อความหมายก็ได้ XML แน่นอน!
XML นั้นยอดเยี่ยม - หากคุณไม่เชื่อ คุณอาจสนใจความเจ็บปวดในการแยกวิเคราะห์ JSON: httpseriot.ch/projects/parsing_json.html
และอย่าให้ฉันเริ่ม YAML ..

ค่าใช้จ่ายที่เพิ่มขึ้นของการอยู่บนคลาวด์นั้นคุ้มค่ามากสำหรับฉันที่จะมีฐานข้อมูลที่ได้รับการจัดการ, สแน็ปช็อตอัตโนมัติ, โฮสต์โหลดบาลานซ์, ที่เก็บข้อมูลบล็อกแบบพลักแอนด์เพลย์ ฯลฯ


ฉันต้องการกังวลว่าผลิตภัณฑ์ของเราดีหรือไม่ ไม่ใช่เกี่ยวกับความล้มเหลวของฮาร์ดแวร์กลางดึก เซิร์ฟเวอร์ใหม่หมุนและทำงานไม่ถูกต้องเพราะไม่มีแรงจูงใจให้ใช้การจัดการการกำหนดค่าด้วยกล่องเดียว มีงานที่ต้องควบคุมเพียงครั้งเดียว ทำให้ OOM หรือดิสก์เต็มและทำให้ทุกอย่างพังแทนที่จะเป็นงาน VM นั้น กลัวการรีสตาร์ทเครื่องที่ใช้งานเกิน 1,000 วัน เป็นต้น

สำหรับฉัน สิ่งที่ดึงดูดใจของคลาวด์ไม่ใช่ความสามารถในการปรับขนาดของ FAANG เมื่อไม่จำเป็น แต่เป็นการแพตช์ระบบปฏิบัติการอัตโนมัติ โหลดบาลานซ์อัตโนมัติ บริการ NAT รวมศูนย์ บันทึกที่วิเคราะห์ได้ บริการฐานข้อมูลที่ฉันไม่ต้องจัดการ นอกเหนือไปจาก การอัปเกรดกล่องเป็นบริการ การจัดการคีย์เข้ารหัสลับและความลับ และแน่นอน พื้นที่จัดเก็บอ็อบเจกต์ (ทั้งหมดนี้เป็นสิ่งที่เราใช้ในการเริ่มต้นของเรา)
ฉันจะพยายามอย่างเต็มที่และบอกว่าเซิร์ฟเวอร์เฉพาะอาจใช้งานได้จริง/คุ้มราคาเมื่อเราไปถึงขนาดที่กำหนด แทนที่จะเป็นในทางกลับกัน ในขณะนี้ ค่าใช้จ่ายบนระบบคลาวด์ถือว่าคุ้มค่าสำหรับการเริ่มต้นของฉัน

หากคุณกำลังกำหนดค่าสภาพแวดล้อมของคุณเป็นโค้ด ท้ายที่สุดแล้ว ก็ไม่สำคัญว่าเป้าหมายของคุณคือเซิร์ฟเวอร์เฉพาะ, vm หรือการตั้งค่าเฉพาะบนคลาวด์ที่กำหนดค่าผ่าน api

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

แน่นอน กองจริงของ Go(o) ที่ผลักดันให้สามารถปรับปรุงได้ (และกำลังปรับปรุง)

ที่กล่าวว่า ความจริงที่ยากก็คือแนวทางของคุณเป็นแนวทางที่ถูกต้อง ธุรกิจเกือบทั้งหมด (สตาร์ทอัพ!) สร้างมากเกินไป แทนที่จะมุ่งเน้นไปที่การให้คุณค่า ระบุช่องที่แท้จริง ฯลฯ (ใช่ ยังมีด้านอุปสงค์ของสิ่งนี้ด้วย เนื่องจาก เงิน VC สูงเกินจริงสำหรับการเริ่มต้นสร้างมากเกินไป พวกเขาต้องการพึ่งพาบุคคลที่สามที่สามารถรับภาระ, ปรับขนาดกับพวกเขา, SLA และสิ่งที่ไม่ต้องโฆษณา)
Kubernetes ยอดเยี่ยมมาก! เมื่อใดก็ตามที่ฉันเห็นธุรกิจที่มีแนวโน้มแข่งขันกันเริ่มใช้ Kubernetes ฉันรู้สึกโล่งใจทันที เพราะฉันรู้ว่าไม่ต้องกังวลอีกต่อไป พวกเขากำลังจะหายไปในกองปัญหาทางเทคนิคที่แก้ไขไม่ได้ พยายามแก้ไขปัญหาที่ไม่สามารถติดตามได้ในกองเทคโนโลยีที่มีความซับซ้อนอย่างไม่น่าเชื่อ และหลีกเลี่ยงข้อจำกัดที่กำหนดโดยระบบที่ออกแบบมาสำหรับธุรกิจที่มีทราฟฟิกขนาดใหญ่กว่าสองในสาม นอกจากนี้ COGS ของพวกเขาจะสูงกว่าของฉันมาก ซึ่งหมายความว่าพวกเขาจำเป็นต้องตั้งราคาผลิตภัณฑ์ของตนให้สูงขึ้น เว้นแต่ว่าพวกเขาจะใช้เงินจาก VC ไปจนหมด (ซึ่งในกรณีนี้พวกเขาเปรียบเสมือนเงินก้อนโต)

ของดีมีอยู่รอบตัว

Ansible เป็นสิ่งที่จำเป็น มันสามารถทำงานไปสู่สถานะคงที่ได้ และนั่นคือทั้งหมด หากพบปัญหา มันจะยกเลิกการเชื่อมต่อ SSH และแสดงข้อผิดพลาดหลามมากมาย และเลิกใช้ไปตลอดกาล แม้จะมีสินค้าคงคลังอยู่ห่างไกลจากการประกาศ
k8s เป็นลูปควบคุมที่พยายามทำให้ความคืบหน้าไปสู่สถานะที่ประกาศไว้ ความล้มเหลวไม่ใช่ปัญหา จะลองอีกครั้ง มันจะตรวจสอบสถานะของตัวเองอย่างต่อเนื่อง มี API ที่ดีในการรายงาน และด้วยแนวคิดที่ปรับปรุงใหม่จำนวนมาก มันจึงยากที่จะมีการปะทะกันแปลกๆ ระหว่างส่วนประกอบที่ใช้งาน (ในขณะที่การรวม playbooks หลายเล่มเข้ากับ Ansible นั้นไม่ใช่เรื่องเล็กน้อย)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
และแม้ว่า k8s จะใช้มรดกตกทอดมากเกินไป แต่ก็ยังมีการสำแดงแนวคิดหลักที่บางลง (เช่น httpsgithub.com/aurae-runtime/aurae )
และตอนนี้คุณกำลังแนะนำให้ผู้คนใช้การดำเนินการที่ไม่ได้มาตรฐานที่ง่ายกว่าหรือไม่
แน่นอนว่าคุณสามารถใช้โซลูชันที่ซับซ้อนน้อยที่สุดหรือใช้บางอย่างที่ "ปิดชั้นวาง"ได้

k8s มีความซับซ้อนและบางอย่างไม่จำเป็นสำหรับสถานการณ์ของคุณ แต่ก็ค่อนข้างกว้าง ยืดหยุ่น รองรับได้ดี ฯลฯ

>คุณกำลังแนะนำให้ผู้คนใช้การดำเนินการที่ไม่ได้มาตรฐานที่ง่ายกว่าใช่หรือไม่
สิ่งที่ฉันแนะนำคือถ้า k8s โปรเจ็กต์/ซอฟต์แวร์มีขนาดใหญ่เกินไปที่จะล้มเหลว ผู้คนก็สามารถเปลี่ยนไปใช้ทางเลือกอื่นได้ โชคดีที่แนวคิดและ API ของ k8 เป็นโอเพ่นซอร์ส ดังนั้นจึงสามารถนำไปใช้ในโครงการอื่นๆ ได้ และฉันได้ให้ตัวอย่างดังกล่าวเพื่อแสดงให้เห็นว่าการเลือก k8s ไม่ใช่การล็อคอินของผู้ขายที่เหมือนกับ Oracle

ฉันมักจะได้ยินเกี่ยวกับสิ่งที่ยอดเยี่ยมทั้งหมดที่คุณได้รับฟรีจากผู้ให้บริการระบบคลาวด์ สิ่งนั้นติดตั้งและใช้งานง่ายจริงหรือ ทุกครั้งที่ฉันพยายามตั้งค่า LAMP Stack บนบริการคลาวด์ มันเป็นกระบวนการที่สับสนและน่ากลัวจนฉันเลิกล้มความตั้งใจ ฉันสงสัยว่าฉันแค่ต้องออกแรงให้หนักขึ้นอีกสักหน่อยแล้วฉันจะไปถึง Cloud Heaven
ความสามารถในการพูดว่า "ฉันต้องการ MySQL แบบคลัสเตอร์ที่นี่ด้วยสเป็คแบบนี้"นั้นดีกว่า (ตามเวลา) มาก กว่าการทำด้วยตัวเอง การอัปเดตยังรวมอยู่ในระบบอย่างดี ดังนั้นฉันแค่พูดว่า "ใช้การอัปเดตล่าสุด"แทนที่จะทำให้แน่ใจว่าเกิดข้อผิดพลาด/รีสตาร์ทด้วยตนเองตามลำดับที่ถูกต้อง

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

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

ด้วยระบบคลาวด์ทั้งหมดจะหายไปเนื่องจากได้รับการจัดการโดยผู้ให้บริการศูนย์ข้อมูลใดก็ตามที่ระบบคลาวด์กำลังทำงานอยู่ แต่สิ่งที่ผู้คนลืมไปก็คือนั่นเป็นเรื่องจริงสำหรับบริการ colocation แบบเก่าซึ่งมักเสนอต้นทุน / มูลค่าที่ดีกว่าระบบคลาวด์
และในขณะที่การจัดการสิ่งต่าง ๆ เช่น AWS หรือ Azure นั้นยากขึ้นอย่างแน่นอนเพราะมันทำให้ผู้ให้บริการ vpc ขนาดเล็กที่แอบอ้างเป็นนามธรรมจำนวนมากซ่อนตัวจากคุณหรือคุณไม่ได้รับจากเซิร์ฟเวอร์ภายในบ้านเครื่องเดียว แต่ก็ไม่ใช่เรื่องยากที่ต้องเรียกใช้สองสามเครื่อง เซิร์ฟเวอร์ vmware พร้อมที่เก็บข้อมูลแบบ SANด้วยสิ่งบนคลาวด์ คุณมีการกำหนดค่าเพิ่มเติมที่ต้องทำเพราะมันเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์เสมือน ฯลฯแทนที่จะพกพาพีซีไปใน กล่องไปที่ห้องของคุณ คุณต้อง "กำหนดค่า"เพื่อให้พร้อมใช้งานฐานข้อมูล DO มีการสำรองข้อมูลที่คุณสามารถกำหนดค่าตามที่คุณต้องการ เก็บไว้ใน DO Spaces (เช่น S3)การจัดการผู้ใช้ DB เป็นเรื่องง่ายนอกจากนี้ยังมีเซิร์ฟเวอร์แคชสำหรับ Redisคุณสามารถเพิ่มโหลดบาลานเซอร์และเชื่อมต่อกับเซิร์ฟเวอร์เว็บต่างๆ ของคุณฉันคิดว่ามันต้องใช้เวลา ประมาณ 30 นาทีในการตั้งค่าเว็บเซิร์ฟเวอร์ 2x, เซิร์ฟเวอร์ DB, เซิร์ฟเวอร์แคช, โหลดบาลานเซอร์, เซิร์ฟเวอร์ที่เก็บข้อมูล และเชื่อมต่อทั้งหมดตามต้องการโดยใช้รูปแบบง่ายๆ ไม่กี่รูปแบบไม่สามารถเอาชนะได้จริงๆหากคุณมีข้อมูลหรือความคิดเห็นเพิ่มเติมโปรดแบ่งปันบทความมากมายทั่วอินเทอร์เน็ตเกี่ยวกับ การทำให้เซิร์ฟเวอร์ Linux แข็งขึ้น เซิร์ฟเวอร์ที่ฉันได้ลองใช้เวลามากกว่า 30 นาทีเล็กน้อยในการทำตามขั้นตอน นานกว่านั้นมากหากฉันพยายามเรียนรู้และเข้าใจว่าแต่ละสิ่งกำลังทำอะไร ทำไมจึงสำคัญ อะไรคือช่องโหว่พื้นฐาน และวิธีการที่ฉันอาจต้องปรับแต่งการตั้งค่าบางอย่างสำหรับกรณีการใช้งานเฉพาะของฉันฉันแน่ใจว่าคุณสามารถค้นหาสคริปต์การตั้งค่าตัวอย่างทางออนไลน์ได้ (กำหนดค่าการอัปเดตอัตโนมัติ ไฟร์วอลล์ แอปพลิเคชัน ฯลฯ ควรเป็นประเด็น ของการเรียกใช้ 'curl $URL'จากนั้น 'chmod +x $FILE'และ 'bash $FILE'ฉันไม่ต้องการการจัดการการกำหนดค่า (ฉันใช้บริการสำรองข้อมูลของผู้ให้บริการซึ่งเป็นสิ่งสำคัญ ฉันเดาว่า)สิ่งนี้: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(เห็นใน httpswww.reddit.com/r/selfhosted /comments/f18xi2/ubuntu_d )เห็นได้ชัดว่าสิ่งเดียวกันนี้อาจกล่าวได้สำหรับ VM ที่ใช้งานระยะยาว และสิ่งนี้สามารถแก้ไขได้โดยการมีทีมที่มีระเบียบวินัย แต่ฉันคิดว่าโดยทั่วไปแล้วมีแนวโน้มมากกว่าในสภาพแวดล้อมที่มีการทำงานระยะยาวเพียงครั้งเดียวโดยเฉพาะ เครื่องHetzner มีทั้งหมดนี้ ยกเว้นฐานข้อมูลที่มีการจัดการhttpswww.hetzner.com/managed-serverแพ็คเกจเว็บโฮสติ้งประกอบด้วย 1. .unlimited DBs (MySQL และ PostgreSQL)httpswww.hetzner.com/webhosting/มีการสำรองข้อมูลอัตโนมัติและล้มเหลวหรือไม่>ด้วยการสำรองข้อมูลรายวันที่จองไว้หรือการสำรองข้อมูลที่รวมอยู่ในประเภทของเซิร์ฟเวอร์ ข้อมูลทั้งหมดจะได้รับการสำรองข้อมูลทุกวันและเก็บไว้สูงสุด 14 วันการกู้คืนข้อมูลสำรอง (กู้คืน) เป็นไปได้ผ่านอินเทอร์เฟซการดูแลระบบ konsoleHแต่ฉันรู้สึกว่าฐานข้อมูลบนเซิร์ฟเวอร์ที่มีการจัดการมีไว้สำหรับใช้งานโดยแอปที่ทำงานบนเซิร์ฟเวอร์นั้น ดังนั้นจึงไม่มีแนวคิดเรื่องเฟลโอเวอร์จริงๆhttpswww.hetzner.com/legal/managed-server/ไดรฟ์เดียวบนเซิร์ฟเวอร์เดียวที่ล้มเหลวไม่ควรทำให้เกิดการผลิต ไฟดับปัญหาเกี่ยวกับการกำหนดค่าจำนวนมากสามารถติดตามได้จนถึงการปรับใช้แบบสมบูรณ์ในตัวเองไฟล์ฟอนต์หรือ JRE นั้นจำเป็นต้องติดตั้งบนเซิร์ฟเวอร์ทั้งหมดหรือไม่ หรือคุณสามารถรวมไฟล์นั้นไว้ในการปรับใช้ของคุณการปรับใช้ของเราใช้เป้าหมายในองค์กรและ EC2สคริปต์การปรับใช้ไม่แตกต่างกัน เฉพาะ IP สำหรับโฮสต์คือทีนี้ ฉันจะบอกว่าฉันสามารถใช้ S3 ในสิ่งที่ฉันต้องการได้ 100% หรือไม่ไม่มีทางเลือกในองค์กรที่มีชุดคุณลักษณะเดียวกันประเด็นของ DevOps คือ "ปศุสัตว์ ไม่ใช่สัตว์เลี้ยง"ใส่สัญลักษณ์แสดงหัวข้อย่อยในเซิร์ฟเวอร์ของคุณสัปดาห์ละครั้งเพื่อหาจุดล้มเหลวของคุณฉันชอบถ้าคุณกระโดดเข้าสู่ Discord/Slack ของเราและแจ้งปัญหาบางอย่างที่คุณพบ เพื่อให้เราสามารถ อย่างน้อยที่สุดก็สร้างประสบการณ์ที่ดีขึ้นสำหรับผู้อื่นโดยใช้ Dokkuอย่าลังเลที่จะติดต่อฉันที่นั่น (ชื่อเล่นของฉันคือ `savant`)ให้ฉันออกตัวก่อนและบอกว่าฉันเป็นผู้พัฒนาแอปพลิเคชันที่มีเพียงความรู้ที่ใช้งานได้ของ Dockerฉันไม่เชี่ยวชาญด้านอินฟราและแอปพลิเคชันที่ฉันมีปัญหามีพารามิเตอร์การปรับใช้ที่แปลกประหลาด: เป็นแอป Python ที่เวลาสร้างแยกวิเคราะห์การรวบรวมข้อมูล HTML แบบคงที่หลายกิกะไบต์เพื่อเติมฐานข้อมูล Postgres ที่เป็นแบบคงที่หลังจากสร้างจากนั้นเว็บแอป Flask จะให้บริการกับฐานข้อมูลนั้นการแยกวิเคราะห์ HTML พัฒนาอย่างรวดเร็ว ดังนั้นควรรวมข้อมูล DB ที่มีประชากรเป็นส่วนหนึ่งของอิมเมจแอปพลิเคชันIIRC ฉันมีปัญหากับการจัดโครงสร้างไฟล์ Dockerfiles เมื่อฐานข้อมูลไม่ใช่ 'ไม่คงอยู่แต่เป็นเพียงส่วนอื่นชั่วคราวของแอป แต่ดูเหมือนว่าจะเอาชนะได้ปัญหาที่ใหญ่กว่าดูเหมือนจะเป็นวิธีการหลีกเลี่ยงการดึงกิ๊กของข้อมูลที่ไม่ค่อยเปลี่ยนแปลงจาก S3 สำหรับแต่ละบิลด์เมื่อต้องการแคช โดยเฉพาะอย่างยิ่งในลักษณะที่ประพฤติอย่างเหมาะสมใน DigitalOcean และสภาพแวดล้อมในเครื่องของฉันฉันคิดว่าการแคชเลเยอร์อิมเมจของ Docker ที่ถูกต้องจะช่วยแก้ปัญหาได้ แต่ความรู้และความอดทนของฉันก็หมดลงอย่างรวดเร็วDX ของ Dokku นั้นยอดเยี่ยมสำหรับคนที่ทำสิ่งปกติ .:)0. httpscoolify.io/นอกจากนี้ ใครไม่อยากเล่นกับของเล่นชิ้นใหม่ล่าสุดที่เจ๋งที่สุดมีข้อโต้แย้งแน่นอนที่จะย้าย (บางส่วน) ออกจากระบบคลาวด์ในภายหลังเมื่อความยืดหยุ่น (หรือการจัดการกับฟลักซ์/การหมุน) กลายเป็นตัวขับเคลื่อนหลักน้อยลง และขนาด/ต้นทุนเริ่มครอบงำแน่นอน คุณสามารถทำงานบางอย่างกับ Hetzner ได้ แต่เตรียมพร้อมที่จะตอบคำถามอีกมากมายตกลงในจุดสุดท้ายขององค์กรของคุณที่ขอสิ่งนี้ ซึ่งเป็นเรื่องที่น่าเศร้าอีกครั้งที่ธุรกิจเหล่านี้ "ข้อกำหนด"กำหนดวิธีออกแบบและโฮสต์ซอฟต์แวร์ของคุณ เมื่อวิธีอื่นอาจดีกว่ามากการกู้คืนความเสียหายเป็นปัญหาที่แท้จริงซึ่งเป็นเหตุผลที่ฉันทดสอบเป็นประจำในสถานการณ์แผ่นดินที่ไหม้เกรียม ฉันสามารถเริ่มทำงานบนระบบสำรอง (การจัดเตรียม) หรือระบบคลาวด์ที่มีรูปแบบพื้นผิวในเวลาน้อยกว่าหนึ่งชั่วโมงสำหรับธุรกิจของฉัน แค่นั้นก็พอ
เราผ่านช่วงการเติบโตที่เฟื่องฟู และเช่นเดียวกับทั้งหมดก่อนหน้านี้ หมายความว่ามีคนที่ไม่มีประสบการณ์จำนวนมากได้รับเงินจำนวนมากและความคาดหวังเร่งด่วน มันเป็นสูตรสำหรับการเพาะเลี้ยงสินค้าและการตลาดที่เอาเปรียบ

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

เซิร์ฟเวอร์เฉพาะที่มั่นคงมีประโยชน์มากกว่า VPS ที่พิการบนฮาร์ดแวร์ที่ใช้ร่วมกันถึง 99% แต่เห็นได้ชัดว่ามีค่าใช้จ่ายเพิ่มขึ้นหากคุณไม่ต้องการทรัพยากรทั้งหมดที่มีให้

ใช่ แต่ความโหยหาที่จะ "ทำในสิ่งที่เด็กๆ เจ๋งๆ กำลังทำอยู่ตอนนี้"อย่างน้อยก็แรงพอๆ กับผู้ที่ปกติเรียกว่า "ผู้จัดการ"เทียบกับ "พนักงาน"ผลลัพธ์ A) การใช้จ่ายไมโครเซอร์วิส/คลาวด์จำนวนมากผิดพลาด อย่างน้อยคุณก็ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด สิ่งเหล่านี้เกิดขึ้น คุณจะทำอย่างไร

ผลลัพธ์ B) คุณใช้เซิร์ฟเวอร์ Hetzner และมีบางอย่างผิดพลาด คุณก็ควรจะเลิกใช้ไมโครเซอร์วิสแล้ว สนุกกับการหางานใหม่

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

(เช่นเดียวกับการเป็นที่ปรึกษาที่ต้องการส่วนเสริมและเขียนซอฟต์แวร์ที่ใช้งานได้ เนื่องจากฉันค้นพบวิธีที่ยาก)
มีการตัดการเชื่อมต่อระหว่างผู้ก่อตั้งและคนอื่นๆ

ผู้ก่อตั้งเชื่อว่าพวกเขาจะทำมากกว่า 10 เท่าทุกปี

ความจริงก็คือ 90% มีแนวโน้มที่จะล้มเหลว

90% ของเวลา - คุณจะล้มเหลวในอะไรก็ตาม

% จาก 10% ของเวลาที่คุณประสบความสำเร็จ คุณยังสบายดีหากไม่มีระบบคลาวด์ - อย่างน้อยก็เป็นเวลาหลายปีของความสำเร็จ มีเวลาอีกมากที่จะเปลี่ยนหากจำเป็น

ฉันมีการตั้งค่าแบบ ansible เพียงอันเดียว และมันสามารถทำงานได้ทั้งกับเซิร์ฟเวอร์เสมือนจริงและเซิร์ฟเวอร์จริง ไม่แตกต่าง. ข้อแตกต่างเพียงอย่างเดียวคือเซิร์ฟเวอร์เสมือนจริงจำเป็นต้องตั้งค่าด้วย Terraform ก่อน และจำเป็นต้องสั่งซื้อเซิร์ฟเวอร์จริงก่อนและป้อน IP ลงในไฟล์การกำหนดค่า (รายการสินค้าคงคลัง)

แน่นอน ฉันยังระมัดระวังที่จะหลีกเลี่ยงการพึ่งพาบริการคลาวด์อื่น ๆ อีกมากมาย ตัวอย่างเช่น ฉันใช้ VpnCloud (httpsgithub.com/dswd/vpncloud) เพื่อสื่อสารระหว่างเซิร์ฟเวอร์ ข้อดีนี้ยังช่วยให้ฉันมีความยืดหยุ่นในการเปลี่ยนไปใช้ผู้ให้บริการโครงสร้างพื้นฐานได้ทุกเมื่อ
ประเด็นหลักของฉันคือแม้ว่าข้อเสนอแบบเวอร์ช่วลไลซ์จะมีประโยชน์ แต่ก็มีช่องว่าง (มาก) ระหว่าง VPS สำหรับงานอดิเรกที่ $10/เดือน กับบริษัทที่มีธุรกิจ B2C ที่เติบโตอย่างรวดเร็ว ธุรกิจใหม่ส่วนใหญ่จะตกอยู่ในช่องว่างดังกล่าว: คุณไม่ได้คาดหวังการเติบโตแบบทวีคูณใน B2B SaaS ที่ทำกำไรได้ นั่นคือสิ่งที่คุณควรตั้งคำถามเกี่ยวกับตัวเลือกเริ่มต้นตามปกติของ "ใช้ AWS"ฉันใส่ใจกับ COGS และกำไรขั้นต้นของฉัน ดังนั้นฉันจึงพิจารณาตัวเลือกนี้อย่างระมัดระวัง

คุณไม่ใช่บริษัทซอฟต์แวร์ โดยพื้นฐานแล้วคุณผลิตและจำหน่าย Sprockets

ความคิดเห็นที่นี่น่าจะเป็นการจ้างเจ้าหน้าที่อังกฤษ/ไอทีรายใหญ่เพื่อ "ซื้อและบำรุงรักษาเซิร์ฟเวอร์"(PaaS แย่) จากนั้นมีแนวโน้มว่าจะ "เขียนโค้ดด้วยตัวเอง"(SaaS แย่) หรืออะไรก็ตามที่กำลังได้รับความนิยมในปัจจุบัน (กระทู้สุดท้ายนี่คือ "ผลักดัน PHP ผ่าน SFTP โดยไม่มี Git และคุณต้องการมากกว่านี้"ฮ่าๆ)
แต่ฉันเชื่อว่าธุรกิจควรทำ One Thing Well และหลีกเลี่ยงการพยายามแข่งขัน (ทำด้วยตนเอง) เพื่อสิ่งที่อยู่นอกเหนือความสามารถหลักของตน ในกรณีนี้ ฉันคิดว่า Sprocket Masters ไม่ควรพยายามจัดการฮาร์ดแวร์ของตนเอง และควรพึ่งพาผู้ให้บริการในการจัดการการปรับขนาด ความปลอดภัย เวลาทำงาน การปฏิบัติตามข้อกำหนด และรายละเอียดเล็กๆ น้อยๆ ทั้งหมด ฉันยังคิดว่าซอฟต์แวร์ของพวกเขาควรมีมาตรฐานที่ไม่ดีโดยให้น้อยที่สุดเท่าที่จะทำได้ พวกเขาไม่ใช่ร้านขายซอฟต์แวร์และควรเขียนโค้ดให้น้อยที่สุด

ตามความเป็นจริงแล้ว Widget Masters สามารถใช้งานไซต์เหล่านี้ได้ด้วยพนักงานจำนวนไม่มากนัก เว้นแต่พวกเขาจะตัดสินใจดำเนินการด้วยตนเองทั้งหมด ซึ่งในกรณีนี้ พวกเขาอาจต้องการพนักงานที่ใหญ่กว่านี้มาก

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

แต่หน่วยงานเหล่านั้นไม่ต้องการให้มีพนักงานดูแลฮาร์ดแวร์ทางกายภาพเช่นกัน..

แต่ Sprocket Masters ยังคงต้องมีที่ปรึกษาระบบคลาวด์ราคาแพงคอยดูแลอยู่เพียงเพื่อตอบสนองต่อเหตุฉุกเฉิน

หากคุณกำลังจะมีเจ้าหน้าที่คอยจัดการปัญหาคลาวด์ คุณก็อาจเช่าเซิร์ฟเวอร์แทนได้

โดยส่วนตัวแล้วฉันใช้ Dedicated Servers สำหรับธุรกิจของเราในช่วงก่อนหน้านี้ แต่เมื่อเราขยายและขยายขนาด มันกลายเป็นเรื่องง่ายมากขึ้นที่จะร่วมมือกับผู้ให้บริการคลาวด์เพื่อจัดเตรียมบริการต่างๆ ได้อย่างรวดเร็ว แม้ว่าต้นทุนจะสูงขึ้นก็ตาม ไม่ต้องพูดถึง มันง่ายกว่ามากที่จะบอกผู้มีโอกาสเป็นลูกค้าว่าคุณใช้ "คลาวด์อย่าง AWS"มากกว่า "เราเช่าเครื่องเหล่านี้ในศูนย์ข้อมูลที่ดำเนินการโดยบริษัทบางแห่ง"(ซึ่งจริงๆ แล้วอาจดีกว่านี้ แต่ลูกค้าส่วนใหญ่จะไม่เข้าใจ) . การตรวจสอบ การปฏิบัติตามข้อกำหนด และอื่นๆ

สำหรับหลายๆ คนยังน้อยกว่านั้นอีกมาก ฉันรันโปรเจ็กต์เล็กๆ[1] ที่แพร่ระบาดไปสองสามครั้ง (การดู 30,000 ครั้งใน 24 ชั่วโมงโดยประมาณ) และมันทำงานบนเว็บเซิร์ฟเวอร์ CPU คอร์เดี่ยวและ Postgres ที่ได้รับการจัดการเช่นเดียวกันบนคอร์ CPU เดียว มันยังใช้งานไม่เต็มที่เลยด้วยซ้ำ
1: httpsaihelperbot.com/ฉันขอเปลี่ยนบางส่วนเป็นฟังก์ชันแลมบ์ดาได้ไหมหรือเปลี่ยนไปใช้ ECS?หรือเปลี่ยนไปใช้บริการคลาวด์อื่น du jour?อาจจะแต่ระยะเวลาที่ฉันใช้ในการเขียนความคิดเห็นนี้ก็คุ้มค่ากับเงินที่ประหยัดได้ประมาณหกเดือนสำหรับสวิตช์ดังกล่าวถ้ามันยากกว่า "กดปุ่ม รับบริการแปลที่เชื่อถือได้ 100%"ก็ยากที่จะพิสูจน์ว่าบางส่วนเป็นเพราะระบบคลาวด์ให้บริการอื่นๆ บริการที่เปิดใช้งานสิ่งนี้ฉันไม่จำเป็นต้องเรียกใช้คลัสเตอร์ Kafka สำหรับการส่งข้อความพื้นฐาน พวกเขาทั้งหมดมาพร้อมกับบัสข้อความผมก็ใช้นะฉันใช้ตัวเลือก DB ที่โฮสต์ฉันใช้ S3 หรือเทียบเท่า ฯลฯฉันพบว่าสิ่งที่เหลืออยู่แทบไม่คุ้มกับความยุ่งยากในการพยายามยัดเยียดตัวเองไปสู่กระบวนทัศน์อื่น เมื่อฉันจ่ายเงินเป็นดอลลาร์หลักเดียวต่อเดือนให้กับ เพียงแค่เรียกใช้บนอินสแตนซ์ EC2เป็นกรณีที่ไม่ใช่ทุกคนหรือทุกโครงการที่สามารถทำได้ฉันไม่ได้ยึดติดกับสิ่งนี้ในฐานะเป้าหมายสุดท้ายเมื่อไม่ได้ผล ฉันจะดำเนินการปรับขนาดที่เหมาะสมทันทีฉันไม่ได้แนะนำให้คุณออกแบบโครงสร้างใหม่ตามสิ่งนี้ฉันแค่จะบอกว่า มันไม่ใช่ทางเลือกที่จะถูกดูหมิ่นมันมีความยืดหยุ่นมาก และการเรียกเก็บเงินก็ค่อนข้างสม่ำเสมอ (หรือพูดอีกอย่างก็คือ ถ้าจู่ๆ ฉันมีทราฟฟิก 50x ระบบของฉันจะเริ่มสำลักและกระตุกอย่างเห็นได้ชัดแทนที่จะเป็นแค่ การเรียกเก็บเงินจากฉันหลายร้อยดอลลาร์เป็นคุณสมบัติสำหรับฉันมากกว่าข้อบกพร่อง) และโดยทั่วไปคุณไม่ได้ยืดตัวเองไปสู่กระบวนทัศน์ที่สะดวกสำหรับบริการคลาวด์บางอย่าง แต่อาจไม่สะดวกสำหรับคุณคุณเคยต้องจัดการหนึ่งในสภาพแวดล้อมเหล่านี้หรือไม่?ประเด็นก็คือ ถ้าคุณต้องการได้รับความสามารถในการปรับขยายขั้นพื้นฐานมากกว่าหนึ่งคนและการเลิกใช้ที่เหมาะสม คุณจะต้องจัดสรรทรัพยากรมากเกินไปด้วยปัจจัยสำคัญ (อาจทำให้เงินออมของคุณเป็นโมฆะ)คุณจะลงเอยด้วยโซลูชันเฉพาะอย่างหลีกเลี่ยงไม่ได้ ซึ่งหมายความว่าผู้ร่วมงานใหม่จะมีช่วงเวลาที่ยากขึ้นในการเรียนรู้ระบบ และบุคคลสำคัญที่ลาออกจากบริษัทจะนำความรู้ที่ลึกซึ้งเกี่ยวกับโครงสร้างพื้นฐานของคุณติดตัวไปด้วยคุณกลับมาหาสัตว์เลี้ยงแทนวัวควายเซิร์ฟเวอร์บางตัวมีความพิเศษ หลังจากนั้นระยะหนึ่งการทำงานอัตโนมัติหมายถึง "สคริปต์กาวเชลล์จำนวนมากที่นี่และที่นั่น"และการอัปเกรดระบบปฏิบัติการหมายความว่าอินฟราครึ่งหนึ่งเป็น KO ชั่วขณะหรือคุณไม่ได้ทำการอัปเกรดระบบปฏิบัติการเลยและในกรณีที่โชคดี คุณต้องขยายขนาดขึ้น คุณอาจพบเรื่องน่าประหลาดใจที่ไม่พึงประสงค์และอย่าปล่อยให้ฉันเริ่มต้นด้านเครือข่ายเว้นแต่คุณจะเช่าชั้นวางทั้งหมดและวางฮาร์ดแวร์เครือข่ายของคุณเอง คุณจะได้รับสิ่งที่ได้รับซึ่งอาจทำงานได้แย่มากทั้งในด้านฟังก์ชันหรือประสิทธิภาพ สมมติว่าคุณไม่ได้ทำอะไรแฟนซีหากคุณต้องการเวลาทำงาน 100.0000% แน่นอนแต่โดยปกติแล้วคุณจะไม่ทำบริษัทที่ต้องการเวลาทำงานแบบนั้นมักจะมีทีมที่ทุ่มเทให้กับมันอยู่แล้วและการปรับขนาดก็ทำงานได้ดีบนโลหะเปลือยเช่นกันหากคุณปรับขนาดในแนวตั้ง คุณรู้หรือไม่ว่าปริมาณเท่าใด พลังและปริมาณงานที่คุณได้รับจากเซิร์ฟเวอร์เครื่องเดียว?การได้ยินเกี่ยวกับ "มาตราส่วน"เป็นเรื่องที่น่ากังวลเสมอ เมื่อผู้พูดหมายถึง "มาตราส่วนในแนวนอน"หากคุณกำหนดความต้องการคือ "มาตราส่วน"การปรับขนาดในแนวตั้งจะนำคุณไปไกลหากความต้องการของคุณคือ "การปรับขนาดตามแนวนอนตามความต้องการ"แน่นอนว่าผู้ให้บริการคลาวด์จะช่วยได้แต่มีเพียงไม่กี่แห่งที่ต้องการการปรับสเกลแบบนั้นฉันไม่ได้บอกว่าเวลาทำงาน 100% บน Bare Metal นั้นราคาถูก ฉันกำลังบอกว่าไม่จำเป็นต้องใช้เวลาทำงาน 100% บ่อยๆเนื่องจากอุตสาหกรรมนี้เต็มไปด้วยผู้คนที่ไล่ตามเทรนด์และคีย์เวิร์ด และสิ่งที่สำคัญที่สุดคือการเพิ่มคีย์เวิร์ดเหล่านั้นในประวัติย่อIME มุ่งเป้าไปที่ ความสามารถในการปรับขนาดเป็นสิ่งที่ผิดอย่างมากสำหรับบริการ/แอปพลิเคชัน/อะไรก็ตามส่วนใหญ่และโดยปกติแล้วคุณต้องจ่ายค่าใช้จ่ายจำนวนมากสำหรับโซลูชันที่ "ปรับขนาดได้"ซึ่งคุณจะต้องปรับขนาดเพื่อชดเชยฉันสงสัยในสิ่งนี้จริงๆธีมหนึ่งที่คุณเห็นในผู้สนับสนุน AWS เกือบทุกคนคือความเข้าใจผิดจำนวนมากเกี่ยวกับสิ่งที่รับประกันว่า AWS ให้คุณจริง ๆใช่ แน่นอนไม่มีใครถูกไล่ออกเพราะซื้อจาก IBMถ้าบริษัทขนาดใหญ่มีความสามารถในการตัดสินใจ พวกเขาก็จะไร้เทียมทานและคงสิ้นหวังที่จะทำงานอย่างอื่นที่ ทั้งหมด.ใช่แล้ว นั่นคือสินค้าสาธารณะที่มา: เกือบสามสิบปีของ opsจนถึงตอนนี้ฉันยังไม่ได้สังเกตเลยว่าถ้าฉันใช้จ่ายมากกว่านี้ สำหรับบริษัทที่ฉันได้รับเงินมากกว่าด้วยการได้รับความน่าเชื่อถือเทียบเท่ากับเตารีดนั้นแพงกว่าการเช่า "เซิร์ฟเวอร์เฉพาะ 2 เครื่อง"มาก - ตอนนี้คุณอาจสบายดีกับเซิร์ฟเวอร์เครื่องเดียวและโซลูชันสำรองข้อมูล และนั่นก็ยุติธรรม แต่ sysad ที่จะสร้างทุกสิ่งนั้น แม้ในสัญญาสั้นๆ สำหรับการตั้งค่าเริ่มต้นและไม่ต้องบำรุงรักษา ก็จะไปได้ไกลกว่าความแตกต่างของราคาบนคลาวด์ โดยเฉพาะอย่างยิ่งหากมีฐานข้อมูลอยู่รวมกันและคุณสนใจข้อมูลนั้นทุกวันนี้ คลาวด์ก็คล้ายๆ กัน เวลาในการออกสู่ตลาดเร็วกว่าเนื่องจากมีส่วนที่เคลื่อนไหวน้อยกว่าเมื่อเศรษฐกิจซบเซาและการเติบโตที่ชะลอตัว ผู้ค้าถั่วจะเข้ามาและทำสิ่งที่พวกเขาทำมันเกิดขึ้นทุกครั้งสิ่งนี้ทำให้ AWS สมบูรณ์ยิ่งขึ้นเท่านั้น ที่บริษัทและทีมคลาวด์การจัดเตรียมและยกเลิกการจัดเตรียมอินสแตนซ์ EC2 โดยอัตโนมัติภายในไม่กี่วินาทีนั้นเป็นเรื่องเล็กน้อย หากการปรับใช้ของคุณจำเป็นต้องปรับขนาดขึ้นหรือลงนั่นคือสิ่งที่ทำให้แตกต่างโดยพื้นฐานจากเซิร์ฟเวอร์โลหะเปลือย
ตอนนี้ ฉันไม่ปฏิเสธว่าการจัดเตรียมเซิร์ฟเวอร์เฉพาะเพิ่มเติมสองสามตัวเกินกว่าที่คุณต้องการจะยังคุ้มค่ากว่าเมื่อเปรียบเทียบกับ AWS แต่เมื่อคุณมีปริมาณงานที่คาดเดาไม่ได้จริงๆ การติดตามไม่ง่ายเลย

หากคุณกำลังหมุนและปิด VM เพื่อให้เป็นไปตามเส้นอุปสงค์ - มีบางอย่างผิดปกติอย่างร้ายแรงกับสถาปัตยกรรมของคุณ

เคยเกิดขึ้นกับคุณหรือไม่ เหตุใด stackoverflow จึงใช้เซิร์ฟเวอร์เฉพาะ ~8 เซิร์ฟเวอร์เพื่อรองรับทั่วโลก และไม่จำเป็นต้องหมุนและปิด VM เพื่อตอบสนองความต้องการของลูกค้าทั่วโลก
--
เมื่อวางแผนโครงสร้างพื้นฐานการประมวลผล สิ่งสำคัญคือต้องกลับไปสู่พื้นฐานและไม่ตกอยู่ภายใต้การโฆษณาชวนเชื่อของผู้จำหน่ายระบบคลาวด์
คุณพูดเอง ไม่ใช่ทุกแอปพลิเคชันที่ต้องรองรับทั่วโลก ดังนั้น ความต้องการจะลดลงเมื่อผู้คนเข้าสู่โหมดสลีป

แม้ว่าแอปพลิเคชันทั่วโลกจะมีข้อบังคับที่กำหนดให้คุณต้องโฮสต์แอปพลิเคชันและข้อมูลในภูมิภาคเฉพาะ ลองนึกภาพแอปพลิเคชันที่ลูกค้าในยุโรป ออสเตรเลีย และสหรัฐอเมริกาใช้ จำเป็นต้องให้บริการจากศูนย์ข้อมูลระดับภูมิภาค และคลัสเตอร์หนึ่งจะเข้าสู่โหมดสลีปเป็นส่วนใหญ่เมื่ออีกคลัสเตอร์หนึ่งทำงานอยู่ (เนื่องจากเขตเวลา) ด้วยเซิร์ฟเวอร์เฉพาะ คุณจะเสียทรัพยากรไป 60-70% ในขณะที่ใช้บางอย่างเช่น EC2/Fargate คุณสามารถลดขนาดลงได้เกือบ 0 เมื่อภูมิภาคของคุณอยู่ในโหมดสลีป

วิธีบ้ามีอยู่วิธีหนึ่ง นี่เรียกว่า “การพัฒนาที่ขับเคลื่อนด้วยความมั่นคงทางงาน”

เพราะมันเป็นภัยคุกคามต่องานของพวกเขา

มีหลายกลุ่มที่มีทักษะด้านเทคนิคในการให้เช่าที่พักด้วยตนเอง หรือจัดพื้นที่เล็กๆ น้อยๆ ให้กับครอบครัว/เพื่อน/สมาคม/ชมรมเดินป่า ส่วนต่างเล็กๆ น้อยๆ นี้ที่คุณยินดีจะใช้จ่ายเพิ่มเล็กน้อยเพราะคุณต้องการทำให้เหมาะสม แต่คุณไม่สามารถจ่ายเงินมากและใช้เวลาไปกับการบำรุงรักษาอย่างหนักได้ VPS ขนาดเล็กที่มี Nextcloud ที่ใช้ร่วมกันหรือเว็บไซต์ขนาดเล็ก ล้วนเป็นสิ่งที่จำเป็นในหลายกรณี

สำหรับสิ่งนี้ ฉันยังใช้ Raspberry Pi 400 เล็กๆ น้อยๆ ในห้องนอนของฉันด้วย

httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..

ฉันเป็นเจ้าของของตัวเองมาเกือบทศวรรษแล้ว ไม่มีใครลอง DDoSing การตั้งค่าของฉัน เพราะเหตุใดจึงทำเช่นนั้น พวกเขาจะได้ประโยชน์อะไรจากมัน? ฉันคงเป็นคนเดียวที่ได้รับผลกระทบ และเมื่อพวกเขาหยุดแล้ว ก็จะใช้เวลาฟื้นตัวไม่นาน

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

คุณกำลังประเมินความสามารถของวัยรุ่นสูงเกินไปอย่างมาก

การกระตุก IP ซ้ำแล้วซ้ำเล่าไม่ได้ช่วยอะไรมากนัก บางทีการโจมตี DoS ขึ้นอยู่กับว่าเครือข่ายเป้าหมายมีอะไรบ้างในแง่ของ IPS แต่ถึงอย่างนั้นก็มีแนวโน้มมากขึ้นที่พวกเขาจะติดไวรัสในคอมพิวเตอร์ก่อนที่จะมีโอกาสโจมตีคุณจริงๆ

โดยส่วนตัวแล้วฉันตกเป็นเหยื่อของหนึ่งในนั้นเพราะคนโกงใน GTA 5 มันเกิดขึ้นอย่างแน่นอนและมันไม่สนุกเลย
 แก้ไข: ดูเหมือนว่านี่อาจเป็นไปโดยอัตโนมัติ นี่เป็นสิ่งที่น่าสนใจที่ฉันควรพิจารณาสักหน่อย มันอาจเป็นเพียงความซับซ้อนเพิ่มเติมสำหรับเซิร์ฟเวอร์เล็กๆ ของฉัน แต่ฉันก็คำนึงถึงประโยชน์บางอย่างอยู่แล้ว

ตามหลักแล้ว homelab ของฉันก็อยู่บน IP สาธารณะแบบคงที่เช่นกัน -- นี่เป็นแบบฝึกหัดใน "ฉันจะทำสิ่งนี้ได้ไหม"มากกว่า "จำเป็นจริง ๆ"แต่ก็ยังเจ๋งอยู่และฉันก็มีความสุขมาก

เกี่ยวกับการวางสายเพียงอย่างเดียวคือฉันต้องกำหนดค่า Wireguard เพื่อรักษาอุโมงค์ให้คงอยู่ มิฉะนั้นบางครั้ง VPS จะรับทราฟฟิกเข้ามาและหากแล็บของฉันไม่ได้ติดต่อมาระยะหนึ่ง (ซึ่งจะเป็นเพราะเหตุใด) อุโมงค์ก็จะหยุดทำงาน และการเชื่อมต่อพร็อกซีจะ โชคดีที่มีฟังก์ชันในตัว

ดังนั้น ดูเหมือนว่าการเพิ่มฟีด RSS / Atom บนเว็บไซต์เพจ jekyll หรือ GitHub ค่อนข้างตรงไปตรงมา

1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/th/pages/setting-up-a-github-pages-s..

3. httpspages.github.com/versions/
atom 2c/4t, แรม 4gb, ไดรฟ์ 1tb, 100mbit
ณ จุดนี้เป็นเวลาสองสามปี
หากไม่หยุดชะงัก: อาจมีการอัปเกรดบางอย่าง
การอัปเดตความปลอดภัยของเคอร์เนลเป็นสิ่งสำคัญ


ฉันพบว่า Atoms ทำงานช้าจนแทบทนไม่ไหว แม้แต่กับ Linux แน่นอนว่ามันเพียงพอสำหรับการให้บริการเว็บไซต์และอะไรก็ตาม แต่มันทำให้ยุ่งเหยิงว่าพวกเขาใช้พลังมากแค่ไหน

อย่างแน่นอน. อินสแตนซ์ VPS ที่มีราคาต่ำกว่า $10 นี้เหมาะสำหรับโครงการขนาดเล็กที่คุณไม่ต้องการทำสัญญาระยะยาวหรือจัดการกับเซิร์ฟเวอร์ของคุณเอง

หากคุณกำลังดำเนินธุรกิจจริงโดยที่อัตรากำไรขั้นต้นต่ำมาก และคุณมีเวลาว่างในโลกนี้เพื่อจัดการกับปัญหาเซิร์ฟเวอร์หาก (เมื่อไหร่) เกิดปัญหาขึ้น เซิร์ฟเวอร์เฉพาะ $50 เหล่านั้นก็น่าสนใจที่จะสำรวจ

แต่ถ้าคุณทำธุรกิจจริง ค่า AWS $10,000 ต่อเดือนก็ยังถูกกว่าจ้างนักพัฒนาที่มีทักษะคนอื่นมาช่วยจัดการเซิร์ฟเวอร์เฉพาะของคุณ

นี่คือสิ่งที่มักพลาดในการอภิปรายเกี่ยวกับต้นทุนระบบคลาวด์ในสถานที่ต่างๆ เช่น HN: ใช่ คลาวด์มีราคาแพง แต่การจ้างผู้ดูแลระบบ/นักพัฒนาเพิ่มเติมแม้แต่รายเดียวเพื่อช่วยคุณจัดการโครงสร้างพื้นฐานแบบกำหนดเองนั้นมีราคาแพงอย่างไม่น่าเชื่อและมีความยืดหยุ่นน้อยกว่ามาก นั่นเป็นเหตุผลว่าทำไมการใช้จ่ายสมมุติ $5,000 ต่อเดือนกับโซลูชันที่โฮสต์บนคลาวด์ ซึ่งตามทฤษฎีแล้วสามารถสร้างขึ้นเองบนเซิร์ฟเวอร์ $50 ต่อเดือนโดยใช้เวลาเพียงพอในการลงทุนก็ยังถือว่าคุ้มค่ามาก วิศวกรมีราคาแพงและมีเวลาจำกัด

เอ่อ ขอโทษนะ แต่คุณจ่ายไอ้ DevOps คนนี้เท่าไหร่? ดูเหมือนว่าจะเป็นมุมมองแบบอเมริกันมาก แม้แต่บริเวณหุบเขา ในยุโรป การจ้างผู้ชายจะถูกกว่า

ต้นทุนการจ้างงานเต็มจำนวนนั้นสูงกว่าเงินเดือนที่คุณได้กลับบ้านอย่างมาก มันแย่กว่าในยุโรปจริงๆ ดูแผนภูมิเหล่านี้: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
หากคุณจ่ายเงินให้ใครสักคน 1,000 ยูโรในสหราชอาณาจักร บริษัทจะมีค่าใช้จ่ายทั้งหมด 1,245 ยูโร

หากคุณจ่ายเงินให้โรมาเนีย 1,000 ยูโร บริษัทจะต้องจ่ายทั้งหมด 1,747 ยูโร

ดังนั้นค่าใช้จ่ายเต็มจำนวน 120,000 ดอลลาร์อาจซื้อคุณได้เพียงเงินเดือน 68,000 ดอลลาร์สหรัฐฯ สำหรับผู้ที่ยอมสละสิทธิ์ในสหภาพยุโรป

แต่คุณไม่สามารถมีผู้เสียสละเพียงคนเดียวได้ คุณต้องมีอย่างน้อย 2 คนหากต้องการอนุญาตให้คนใดคนหนึ่งหยุดพักหรือไปเที่ยวพักผ่อน

ฉันสามารถโทรหาคุณได้ภายใน 3 ชั่วโมง

AWS นั้นคุ้มค่ามากสำหรับบริการอื่นๆ (S3, SES, SQS ฯลฯ) แต่เครื่องเสมือนนั้นไม่ใช่ข้อเสนอที่ดีนัก คุณได้รับ RAM น้อยลง& CPU ที่มีค่าใช้จ่ายด้านการจำลองเสมือนและจ่ายเงินมากขึ้น

โดยเฉพาะอย่างยิ่งสำหรับ Postgres หากคุณทำการทดสอบกับ pgbench คุณจะเห็นการลงโทษที่คุณจ่ายสำหรับการจำลองเสมือน

บางทีทักษะการดูแลระบบในการสร้างโครงสร้างพื้นฐานของคุณเองอาจกลายเป็นงานศิลปะที่หายไป ไม่เช่นนั้นฉันก็อธิบายไม่ได้ว่าทำไมผู้คนถึงชอบจ่ายเงิน 5 เท่าเพื่อประสิทธิภาพที่น้อยลง

Hetzner มีราคาถูกและเชื่อถือได้ในยุโรป หากคุณอยู่ในอเมริกาเหนือ ลองดูที่ OVH โดยเฉพาะทางเลือกที่ประหยัดต้นทุนที่เรียกว่า SoYouStart คุณสามารถซื้อ 4/8 4.5ghz, 64 RAM และไดรฟ์ NVME ได้ในราคา 65 ดอลลาร์

(ฉันไม่มีความเกี่ยวข้องกับ OVH ฉันเป็นเพียงลูกค้าที่มีเซิร์ฟเวอร์เกือบ 100 เครื่อง และมันได้ผลดีสำหรับฉัน)
ฉันยังจะสังเกตด้วยว่าฉันแก่แล้ว อิอิ และหนึ่งในงานแรกๆ ของฉันที่เรามีศูนย์ข้อมูลขนาดพอเหมาะในสถานที่ การจัดการกับ SAN, เทปไดรฟ์ (ตัวหมุนเทปอัตโนมัติในขณะนั้นคือเซิร์ฟเวอร์ ฯลฯ ถือเป็น PITA ขนาดใหญ่ การบรรจุเทปและจัดส่งไปยังสำนักงานอื่นเพื่อความซ้ำซ้อนของสถานที่เป็นเรื่องสนุกเสมอ

แอปพลิเคชันเฉพาะที่ฉันจัดการมีความถี่ต่ำ GHz และไม่มีข้อมูลทั้งหมดในหน่วยความจำ ฉันเรียกใช้การวัดประสิทธิภาพบน EC2 แล้ว รายงานบางฉบับที่เสร็จสิ้นภายใน ~5 วินาทีอาจใช้เวลานานกว่าหนึ่งนาทีบนอินสแตนซ์ EC2 ที่เทียบเคียงได้ ซึ่งมีราคาสูงกว่าประมาณ 10 เท่า แอปพลิเคชันนี้ต้องการ CPU แบบ Raw จริงๆ และใช่ เรามีทีมวิศวกรขนาดใหญ่ที่ได้เพิ่มประสิทธิภาพการสืบค้น Ãndices ฯลฯ ทั้งหมด

ในส่วนของการจำลองแบบ การสำรองข้อมูล ฯลฯ ฉันตั้งค่าทั้งหมดแล้ว และจริงๆ แล้วมันก็ไม่ใช่เรื่องใหญ่อะไร เป็นบทสั้นๆ สองสามบทในหนังสือ Postgres ที่อธิบายทั้งหมดอย่างง่ายๆ วิธีกำหนดค่า การทดสอบอย่างต่อเนื่อง (และอัตโนมัติ) ฯลฯ

ฉันยอมรับว่า SAN เป็นฝันร้าย นั่นเป็นเหตุผลที่ฉันจัดส่ง WAL (ไฟล์สำรอง PG) ทั้งหมดของฉันไปยัง S3 (และในท้ายที่สุดคือ Glacier) ด้วยวิธีนี้ฉันไม่ต้องคิดถึงการสูญเสียไฟล์เหล่านั้นและราคาถูกมาก

ฉันคิดว่ามีความเข้าใจผิดว่าการกำหนดค่าประเภทนี้ซับซ้อนเกินกว่าที่วิศวกรคนเดียวจะตั้งค่าได้ โดยต้องมีการบำรุงรักษาไม่สิ้นสุด ในความเป็นจริง คุณสามารถตั้งค่าทั้งหมดได้ภายในเวลาไม่ถึงหนึ่งสัปดาห์ และต้องการการบำรุงรักษาจริงๆ เมื่อคุณต้องการอัปเกรด Postgres เท่านั้น (การตั้งค่าบางอย่างอาจมีการเปลี่ยนแปลง) ฉันคาดว่าจะใช้เวลาประมาณ 5 ชั่วโมงต่อปีในการบำรุงรักษา

โครงสร้างพื้นฐานแบบบริการตนเองดูเหมือนจะมีศักยภาพมากขึ้นในขณะที่เราปรับปรุงการส่งมอบไมล์สุดท้ายและขยายการเข้าถึงไฟเบอร์อย่างต่อเนื่อง คลาวด์จะกลายเป็นคนกินเนื้อตัวเองหรือไม่? อาจจะแน่นอน

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

httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..

แก้ไข: ถ้าใครสนใจจะโฮสต์เองก็ทำได้ง่ายๆ ด้วย cloudflared ฉันมี Google Pixelbook ปี 2017 ที่ใช้ Ubuntu บนเฟิร์มแวร์ที่กำหนดเองซึ่งให้บริการเว็บไซต์ที่ใช้ Flask ชาร์จโต๊ะของฉันขณะเชื่อมต่อกับเครือข่าย wifi สำหรับแขก ได้คะแนน Mobile PageSpeed ​​100/100 และใช้เวลาโหลดเต็ม 0.8 วินาที

จาก DO ฉันได้รับประโยชน์ทั้งหมดจากบริษัทที่เชื่อถือได้ ความสามารถในการขยายขนาด การสำรองข้อมูลอัตโนมัติ ฯลฯ ฯลฯ ไม่มีทางที่ฉันจะเปลี่ยนแปลง

ขณะนี้ระบบคลาวด์ของ Hetzner มีที่ตั้งสองแห่งในสหรัฐฯ แต่ยังไม่มีเซิร์ฟเวอร์เฉพาะของสหรัฐอเมริกา - สิ่งเหล่านั้นน่าจะใช้งานได้จริง แม้ว่าข้อเสนอคลาวด์ในปัจจุบันจะอยู่ที่ประมาณ 30% ของราคาเทียบเท่าคลาวด์หลักแล้วก็ตาม

เช่นเดียวกับคุณ ฉันก็ใช้บริการของฉันจากเซิร์ฟเวอร์จริงที่เช่ามาเช่นกัน ฉันเคยใช้ Versaweb แต่เครื่องของพวกเขาเก่าเกินไป ก่อนหน้านี้ฉันไม่ชอบ Hetzner เพราะฉันได้ยินเรื่องแย่ๆ เกี่ยวกับพวกเขา ซึ่งขัดขวางสิ่งที่คุณกำลังดำเนินการอยู่

อย่างไรก็ตาม ฉันย้ายไปยังพวกเขาในเดือนธันวาคม เมื่ออินสแตนซ์ Versaweb ของฉันเพิ่งเสียชีวิต อาจเป็น SSD ที่มีอายุมาก ตอนนี้ฉันจ่ายเงิน 50% ของสิ่งที่ฉันจ่ายให้ Versaweb และฉันสามารถเรียกใช้อินสแตนซ์ Postgres ได้ 6 รายการ

จากนั้นก็ทำให้เกิดข้อสงสัยว่าคุ้มค่าที่จะจ่ายเงิน 700 ดอลลาร์จาก 800 ดอลลาร์สำหรับบริการที่ได้รับการจัดการด้วย UI คลาวด์ที่สวยงาม การอัปเกรดและการสำรองข้อมูลอัตโนมัติ ฯลฯ

สำหรับการแสดงคนเดียวหรือสตาร์ทอัพเล็กๆ ฉันคิดว่าไม่ ถูกกว่าหากใช้บริการที่มีอยู่และสำรองข้อมูลไปยัง S3 หรืออะไรที่ถูกกว่า

บริษัทที่ฉันเคยทำงานให้กับบริษัท A ที่มีรายได้ดีเป็นสี่เท่าของราคาที่บริษัท B เรียกเก็บสำหรับบริการเดียวกัน เพียงเพราะบริษัท A ยินดีที่จะส่งใบแจ้งหนี้รายไตรมาสในลักษณะที่เข้ากับระบบการออกใบแจ้งหนี้ของเราได้ดี สำหรับบริษัทต่างๆ การประหยัดเงินได้สองสามร้อยเหรียญที่นี่และมักจะไม่คุ้มค่ากับความยุ่งยากในการทำให้เกิดแรงเสียดทานเพิ่มเติมใดๆ

มีค่าใช้จ่ายโดยนัยที่นั่น หากมีเพียงหนึ่งหรือสองสิ่งเหล่านั้น เพียงใช้บริการที่มีการจัดการ

หากคุณเริ่มขยายขนาด ให้จ้างพนักงานประเภทผู้ดูแลระบบเพื่อประหยัดในเรื่องนี้
มิฉะนั้น ฉันจะต้องจ้าง/ทำสัญญากับผู้ที่มีประสบการณ์สูง หรืออุทิศเวลาหนึ่งเดือนหรือมากกว่านั้น (ซึ่งไม่พร้อมให้บริการ) เพื่อให้แน่ใจได้ 100% ว่าเราสามารถกู้คืนข้อมูลสำรอง PITR ที่เจอร์นัลได้อย่างรวดเร็ว

ฉันสามารถประหยัดค่าใช้จ่ายบนคลาวด์ในที่อื่นได้ แต่ PostgreSQL ที่มีการจัดการที่น่าเชื่อถือนั้นค่อนข้างง่าย (แม้ว่าป้ายราคาระดับเริ่มต้นจะมากกว่าที่คุณคาดไว้ก็ตาม)

การเริ่มต้นใช้งานแต่เนิ่นๆ ที่ไม่สามารถยอมสูญเสียข้อมูลการผลิตหนึ่งชั่วโมงนั้นอาจเปราะบางเกินกว่าจะอยู่รอดได้

เป็นการเริ่มต้นก่อนเวลา - จะมีการขัดจังหวะขนาดใหญ่กว่านั้นในบริการ และลูกค้ารายใดก็ตามที่หลบหนีหลังจากสูญเสียข้อมูลการผลิตไปหนึ่งชั่วโมง ก็ไม่ได้ให้คุณค่ากับผลิตภัณฑ์มากพออยู่ดี

(ในการเริ่มต้นเฉพาะที่ฉันคิดไว้ ฉันมีดัมพ์ DB-online แบบอัตโนมัติที่ดีอยู่แล้วไปยัง S3 พร้อมการบังคับใช้การเก็บรักษา แต่ฉันไม่คิดว่าจะดีพอสำหรับสถานการณ์เฉพาะนี้ แต่ไม่แน่ใจว่าเราจะกู้คืนด้วย PITR/journaling จะเพิ่มจุดเสี่ยงแห่งความล้มเหลวเพียงจุดเดียวในการเดิมพันความสำเร็จของธุรกิจที่มิฉะนั้นอาจมีทางออกด้วยตัวเลข 9+ ในอีกไม่กี่ปีข้างหน้า เพียงเพื่อประหยัดเงินไม่กี่ร้อย)
นอกจากนี้ ฉันคิดว่าสตาร์ทอัพยุคแรกๆ บางรายที่มีความต้องการน้อยกว่า แต่มีความเข้มงวดเกี่ยวกับภาระผูกพันที่มีต่อข้อมูลของลูกค้า/ผู้ใช้ ยังคงเพิกเฉยต่อการปฏิบัติขั้นพื้นฐานขั้นต่ำ

วิธีหนึ่งในการชื่นชมโดยสัญชาตญาณ: ลองนึกภาพข่าวธุรกิจบน HN การดำเนินการของสตาร์ทอัพบางรายการโดยมีการแนบชื่อผู้ก่อตั้งสตาร์ทอัพ และเรื่องราวบอกว่าพวกเขาไม่มีการสำรองข้อมูลที่ดี จากนั้นหนึ่งในนั้น ผู้ร่วมก่อตั้งซึ่งอาจจะไม่ได้นอนมากเพราะบริษัทของพวกเขามีปัญหารอบๆ ตัวพวกเขา ตอบว่า "ข้อมูลลูกค้าไม่ได้สำคัญขนาดนั้นในการเริ่มต้นแรกๆ ถ้าเป็นเช่นนั้น เราคงจะเปราะบางเกินไป"(พิมพ์ก่อนที่ผู้ร่วมก่อตั้งจะโยนแล็ปท็อปของบุคคลนั้นทิ้ง ข้ามห้องเพื่อหยุดพิมพ์) มันคงดูไม่ดีนัก

ฉันจะพูดเรื่องนี้ในตอนท้าย

>ลองนึกภาพข่าวธุรกิจบน HN การดำเนินการของสตาร์ทอัพบางรายการโดยมีการแนบชื่อผู้ก่อตั้งสตาร์ทอัพ และเรื่องราวก็พูดขึ้น และปรากฎว่าพวกเขาไม่มีการสำรองข้อมูลที่ดี

ITYM และปรากฎว่าพวกเขาไม่ได้สำรองข้อมูลในชั่วโมงที่แล้ว
ฉันสามารถจินตนาการทุกอย่างในสถานการณ์ของคุณ แม้แต่บิตที่ไม่ได้สนิป และดูเหมือนทุกอย่างจะปกติ เว้นแต่คุณจะอ่านว่า "ลูกค้าเริ่มต้นของเรา ที่ใช้เรามาหนึ่งเดือน ทั้งหมดจะถูกทิ้งทันทีเมื่อเราทำข้อมูลหายในชั่วโมงที่แล้ว"ฉันนึกภาพเหตุการณ์นั้นไม่ออกจริงๆ

จริงอยู่ มีบางธุรกิจที่ข้อดีของการใช้คือไม่มีข้อมูลสูญหายแม้แต่ชั่วโมงเดียว
IOW ลูกค้าใช้เพราะจะไม่สูญเสียข้อมูลใดๆ เช่น การทำงานร่วมกันในเอกสารออนไลน์[1] เช่น[2] หากคุณประสบปัญหาที่สูญเสียข้อมูลที่ป้อนล่าสุดไปหนึ่งชั่วโมง แน่นอนว่าคาดว่าผู้ใช้ปัจจุบันที่ได้รับผลกระทบทั้งหมดจะหนีไปทันที

[1] แม้ว่าโดยส่วนตัวแล้ว ฉันจะลดความเสี่ยงด้วยการทำซ้ำเอกสารปัจจุบันใน localstorage ในขณะที่กำลังแก้ไข

[2] บางทีตลาดหลักทรัพย์อาจต้องการให้ระบบเก็บข้อมูลชั่วโมงสุดท้ายด้วย? อะไรอีก?
ฉันคิดว่าแม้สำหรับทีมขนาดใหญ่ การจัดการฐานข้อมูลด้วยตัวเองก็อาจสมเหตุสมผล โดยสมมติว่าคุณมีความสามารถที่จะทำมันได้ดี มีหลายสิ่งหลายอย่างที่อาจผิดพลาดได้กับบริการที่มีการจัดการ และพวกเขาไม่ได้ซ่อนการใช้งานพื้นฐานเช่นเดียวกับที่เก็บข้อมูลแบบบล็อกหรือที่เก็บวัตถุ

ประสิทธิภาพสูงสุดนั้นแย่ลงอย่างแน่นอน - แต่ฉันก็ไม่กังวลเกินไปหากบางอย่างใช้เวลานานกว่าในการทำงาน คุณพูดถูกอย่างแน่นอนในการมีระบบอัตโนมัติในการจัดหาเซิร์ฟเวอร์ ซึ่งเป็นสิ่งที่ฉันไม่ได้ทำกับเซิร์ฟเวอร์จริง

ฉันเคยมีเซิร์ฟเวอร์รูทสำหรับโครงการสัตว์เลี้ยงของฉัน แต่พูดตามตรง มันไม่สมเหตุสมผลเลย ฉันไม่ได้ใช้งานทราฟฟิกสูง คำนวณ SaaS ที่เข้มข้นบนเครื่องของฉัน เป็นเพียงเว็บไซต์คงที่และบางโครงการ ฉันลดค่าใช้จ่ายรายเดือนลงเหลือ 24 ซึ่งรวมถึงกล่องเก็บข้อมูลขนาด 1 TB เพื่อเก็บข้อมูลทั้งหมดของฉัน

ปัญหาหลักในทุกสถานการณ์ที่เกี่ยวข้องกับฮาร์ดแวร์จริงคือคุณต้องการพนักงานที่มีความสามารถทั้งในด้านฮาร์ดแวร์และระบบ Linux/UNIX หลายคนอ้างว่าอยู่ในเรซูเม่แล้วไม่สามารถทำงานได้เลย (จากประสบการณ์ของฉันเอง) ในความคิดของฉัน หนึ่งในเหตุผลหลักที่ทำให้โลกคลาวด์ระเบิดคือความยากลำบากในการสร้างและต้นทุนทางการเงินในการสร้างทีมดังกล่าว นอกจากนี้ยังมีความไม่ลงรอยกันที่ค่อนข้างเป็นธรรมชาติ (และจำเป็น) ระหว่างผู้พัฒนาแอปพลิเคชันและผู้ใช้ระบบ ผู้ใช้ระบบควรโต้กลับและโต้เถียงอยู่เสมอเพื่อความปลอดภัยที่มากขึ้น กระบวนการที่มากขึ้น และการปรับใช้ที่น้อยลง ทีมพัฒนาควรโต้เถียงเสมอเพื่อความยืดหยุ่นที่มากขึ้น การเปิดตัวที่มากขึ้น และกระบวนการที่น้อยลง การจัดการที่ดีควรสร้างทางสายกลางระหว่างทั้งสอง น่าเสียดายที่ผู้จัดการที่ไร้ความสามารถมักจะตัดสินใจกำจัดคนในระบบและย้ายสิ่งต่างๆ ไปยังพื้นที่ AWS

สุดท้ายนี้ ฉันขอแจ้งให้ทราบว่าสถาปัตยกรรมระบบคลาวด์นั้นไม่ดีต่อโลก เนื่องจากผู้ให้บริการระบบคลาวด์ต้องการการจัดสรรพื้นที่มากเกินไป และต้องใช้พลังงานคอมพิวเตอร์โดยรวมมากขึ้นเนื่องจากสิ่งที่เป็นนามธรรมหลายชั้น ในขณะที่ทุกโครงการมีส่วนรับผิดชอบต่อของเสียเพียงเล็กน้อย แต่ระบบคลาวด์ทั่วโลกโดยรวมนั้นสิ้นเปลืองมาก สิ่งนี้รบกวนจิตใจฉันและเห็นได้ชัดว่ามีปัจจัยที่เป็นอคติทางอารมณ์ในมุมมองของฉัน (เกลือจำนวนมากสำหรับทั้งหมดข้างต้น)
ข้อโต้แย้งอาจทำให้คุณสามารถพัฒนาวิธีการเช่าเซิร์ฟเวอร์ทางกายภาพก่อนรายได้ จากนั้นเมื่อสมเหตุสมผล คุณสามารถใช้ค่าเสื่อมราคามาตรฐาน -หรือ- มาตรา 179 สำหรับการซื้อทันทีและ/หรือสัญญาเช่ามาตรา 179

ตัวอย่างเช่น คุณสามารถปรับใช้กลุ่มที่มีความสามารถอย่างไม่น่าเชื่อ สมมติว่ามีเครื่อง 1U ทางกายภาพที่มีการจัดสรรเกินมูลค่า $100,000 จำนวนสี่เครื่องในสิ่งอำนวยความสะดวกที่มีโคโลต่างกันเพื่อความซ้ำซ้อน มีลูกเล่นทุกประเภทสำหรับโหลดบาลานซ์และเฟลโอเวอร์ด้วยบริการคลาวด์ XYZ, DNS, แคสต์ใดๆ ก็ตามที่คุณต้องการ คุณสามารถใช้สิ่งอำนวยความสะดวก colo ต่างๆ ที่ดำเนินการศูนย์ข้อมูลทั่วโลก จัดส่งฮาร์ดแวร์จากผู้จำหน่ายไปยังพวกเขา จากนั้นจัดเตรียมสิ่งอำนวยความสะดวกเหล่านั้นด้วย Ansible หรืออะไรก็ตามที่คุณสนใจโดยที่คุณไม่เคยเห็นสิ่งอำนวยความสะดวกหรือสัมผัสฮาร์ดแวร์

ตอนนี้คุณมีฮาร์ดแวร์ทางกายภาพที่ซ้ำซ้อนที่จะทำงานเป็นวงกลมรอบผู้ให้บริการคลาวด์ส่วนใหญ่ (โดยเฉพาะสำหรับ I/O) ค่าใช้จ่ายคงที่ เช่น แบนด์วิดท์ทั้งหมดที่คุณสามารถทำได้ (ซึ่งไม่มีมาร์กอัป 800% ของบริการคลาวด์ ฯลฯ) ไม่ต้องรออีกต่อไป สำหรับการเรียกเก็บเงินคลาวด์มูลค่า 50,000 ดอลลาร์ที่หลีกเลี่ยงไม่ได้ หรือพยายามติดตาม (ด้วยความตื่นตระหนก) ว่าอะไรทำให้คุณใช้จ่ายเกินงบประมาณคลาวด์ที่กำหนดค่าไว้ในหนึ่งวันแทนที่จะเป็นหนึ่งเดือน โอ้ อีกอย่าง คุณไม่ได้ล็อคตัวเองไว้กับ APIs ที่เป็นกรรมสิทธิ์ของตัวเองเพื่อจัดเตรียมและแม้แต่ใช้บริการอื่นนอกเหนือจากเครื่องเสมือนที่นำเสนอโดย $BIGCLOUD

หากคุณกำลังทำ ML ใดๆ คุณสามารถฝึกฝนบนฮาร์ดแวร์ของคุณเองหรือ (หรือระบบคลาวด์เป็นครั้งคราว) และเรียกใช้การอนุมานตลอด 24 ชั่วโมงทุกวันด้วยสิ่งต่างๆ เช่น NVIDIA A10 การเช่าระบบคลาวด์อย่างต่อเนื่องสำหรับอินสแตนซ์ GPU นั้นแพงอย่างไม่น่าเชื่อ และ ROI จากการซื้อฮาร์ดแวร์โดยทั่วไปจะอยู่ในช่วงไม่กี่เดือน (หรือล่วงหน้าเกือบจะทันทีด้วยมาตรา 179) ตัวอย่างเช่น เมื่อเร็ว ๆ นี้ฉันได้ทำเกณฑ์มาตรฐานกับ Nvidia A10 สำหรับรุ่นที่เรากำลังให้บริการ และสามารถทำคำขออนุมานได้มากกว่า 700 รายการ/วินาทีใน FP32 โดยมีเวลาแฝงต่ำกว่า 10 มิลลิวินาที ด้วย A10 เดียวต่อแชสซีในสี่อินสแตนซ์ที่ดีที่ 2,800 req/s (และอาจปรับเพิ่มเติมได้)

จากนั้น ถ้าคุณใหญ่ขึ้นจริงๆ คุณก็เริ่มหาตู้และอื่นๆ ได้ ในแง่ของความล้มเหลวของฮาร์ดแวร์ดังที่ได้กล่าวมา ทั้งหมดที่ฉันสามารถพูดได้คือ dual PS RAID-ed out ฮาร์ดแวร์อื่นๆ (จากประสบการณ์ของฉัน) มีความน่าเชื่อถืออย่างมาก การมีตู้ฮาร์ดแวร์เต็มรูปแบบหลายตู้ในอดีต ความล้มเหลวของฮาร์ดแวร์มีน้อยมากและห่างไกลระหว่างฮาร์ดแวร์ ผู้ขายจะรวม SLA ที่น่าทึ่งเพื่อทดแทน คุณแจ้งให้พวกเขาทราบถึงความล้มเหลว พวกเขาส่งเทคโนโลยีเข้ามา< แปดชั่วโมงโดยตรงไปที่ศูนย์ colo และเปลี่ยนดิสก์ PS ฯลฯ ด้วยไฟกะพริบ

ประสบการณ์ของฉันคือทรัพยากร FTE หนึ่ง (ที่ดี) สามารถจัดการสิ่งนี้ได้อย่างง่ายดายจนถึงหลายขนาดตู้ ตามประเด็นของคุณ ปัญหาปัจจุบันคือคนเหล่านี้จำนวนมากถูกผู้ให้บริการคลาวด์รายใหญ่แย่งชิงไปและแทนที่ (ในตลาด) ด้วยทรัพยากรที่สามารถสำรวจความไร้สาระในแนวเขตแดนที่ใช้ผลิตภัณฑ์/บริการจำนวนมาก (ถ้าไม่มากกว่านั้น) จาก $ บิ๊กคลาวด์

ฉันยังพบว่าการกำหนดค่านี้มีความน่าเชื่อถือมากกว่า $BIGCLOUD ส่วนใหญ่มาก ไม่ต้องสงสัยอีกต่อไปว่าเกิดอะไรขึ้นกับการหยุดทำงานของ $BIGCLOUD ที่พวกเขาไม่รู้ด้วยซ้ำ (และคุณไม่สามารถควบคุมได้อย่างแน่นอน) มาจากพื้นฐานด้านโทรคมนาคมและการดูแลสุขภาพ ฉันรู้สึกแย่มากที่เวลาทำงานแย่กว่านั้นมากกับผู้ให้บริการระบบคลาวด์ โดยปกติแล้ว คุณสามารถบอกลูกค้าว่า "โอ้ อินเทอร์เน็ตกำลังมีปัญหาในวันนี้"เพราะพวกเขาอาจจะเห็นพาดหัวข่าวเกี่ยวกับเรื่องนี้ แต่สำหรับแอปพลิเคชันจำนวนมากที่ยอมรับไม่ได้โดยสิ้นเชิง - และเราควรคาดหวังให้ดีกว่านี้

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
ถ้าฉันต้องการเริ่มโครงการใหม่หรือลองโฮสต์สิ่งใหม่ ๆ ใช้เวลาสองสามนาทีและฉันมีสคริปต์แล้ว การปรับใช้ทำได้รวดเร็ว การบำรุงรักษาต่ำ และฉันมีเงินมากกว่านั้นมาก

สำหรับใครก็ตามที่สนใจ นี่คือส่วนคร่าวๆ ของสิ่งที่ฉันใช้:
* สามารถจัดการทุกอย่างได้
* พื้นผิวเล็กน้อยสำหรับบางรายการ DNS ซึ่งฉันอาจแทนที่ในหนึ่งวัน
* restic สำหรับการสำรองข้อมูล ควบคุมโดย ansible อีกครั้ง
* tailscale สำหรับ vpn (ฉันมี pi บางตัวทำงานอยู่ที่บ้าน ไม่มีอะไรสำคัญนอกจาก tailscale ทำให้ง่ายและปลอดภัย)
* docker-compose สำหรับอย่างอื่นเกือบทั้งหมด
แอปหลักคือ Clojure ดังนั้นฉันจึงเรียกใช้ JVM แบบเนทีฟ ฐานข้อมูลได้รับการเผยแพร่อย่างสมบูรณ์ RethinkDB กำลังดำเนินการย้ายไปยัง FoundationDB

สิ่งสำคัญคืออย่าจัดการอะไรด้วยตนเองเช่น ปฏิบัติต่อเซิร์ฟเวอร์จริงเหมือนกับเซิร์ฟเวอร์คลาวด์อื่นๆ ไม่สำคัญว่าจะเป็นแบบกายภาพหรือแบบเสมือนจริง

ฉันเคยเห็นคนที่มีประสบการณ์น้อยกว่าจำนวนมากจ่ายเงินมากเกินไปสำหรับเฮตซ์เนอร์และคล้ายกันเมื่อ vps $5-10 ทำงาน

ใช่ คุณกำลังสนับสนุนฮาร์ดแวร์ของคุณเอง ณ จุดนั้น ไม่ มันไม่ใช่อาการปวดหัวมาก

ค่าใช้จ่ายเพิ่มเติมที่ใหญ่ที่สุดคือการเช่าที่อยู่ IPv4 มากขึ้น ซึ่ง Hetzner คิดค่าบริการอย่างดีสำหรับตอนนี้ที่มีให้ใช้งานน้อยมาก

ไม่ว่าคุณจะสร้างอะไรก็ตาม จะเริ่มต้นด้วยผู้ใช้ 0 คน และเครื่องจริงทั้งเครื่องก็เกินความจำเป็นสำหรับการโหลด 0 ที่คุณจะได้รับ คุณอัปเกรด VPS ของคุณเป็นเครื่องจริง 2 เครื่อง จากนั้นเป็นคลัสเตอร์เช่าขนาดเล็ก จากนั้นเป็นดาต้าเซ็นเตอร์ ทั้งหมดนี้มีค่าใช้จ่ายที่คาดเดาได้และประสิทธิภาพสูงสุดสำหรับราคาของพวกเขา

ทุกสิ่งที่คุณเป็นเจ้าของในโคโลก็จะมากขึ้นต่อเดือนเช่นกัน เมื่อฉันมีการเชื่อมต่อที่สามารถจ่ายค่า IP แบบคงที่ได้ โดยปกติจะเป็น $5 ต่อเดือน
ตอนนี้ฉันกำลังเช่าเซิร์ฟเวอร์ระดับล่างอยู่ แต่ราคาอยู่ที่ $30/เดือน ทุกสิ่งที่ฉันต้องการมากกว่านี้ แต่มันก็ดี และพวกเขาไม่ได้ลดการสนับสนุนระบบปฏิบัติการของฉันในขณะที่เพิ่มราคาเพื่อปรับปรุงการสนับสนุนหรืออะไรสักอย่าง (แม้ว่าฉันจะมีฮาร์ดแวร์ที่ไม่สม่ำเสมอในตอนแรกซึ่งจำเป็นต้องเปลี่ยน)
อย่างที่คุณชี้ให้เห็น โลหะเปลือยคือหนทางที่จะไป ทำงานตรงกันข้ามกับคลาวด์ - ทำงานเพิ่มขึ้นเล็กน้อยในช่วงเริ่มต้น แต่มีค่าใช้จ่ายน้อยลงมากในตอนท้าย

ข้อมูลเพิ่มเติม httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..

การตั้งค่าและการจัดการ Postgres เป็นเรื่องที่ยุ่งยาก คงจะดีไม่น้อยถ้ามีวิธีที่ง่ายกว่านี้ในการทำให้ทุกอย่างถูกต้อง

1. บังคับให้กำหนดค่าให้ทำซ้ำได้ เนื่องจาก VM จะหยุดทำงาน

2. คุณสามารถรับส่วนลดมากมายจาก AWS ซึ่งช่วยลดความเจ็บปวด

3. สิ่งอื่นๆ ที่คุณสามารถเข้าถึงได้บน VM ที่ถูกกว่า/เร็วกว่าเมื่อข้อมูลของคุณอยู่ในคลาวด์แล้ว
4. มีการกำหนดค่าระบบที่จัดทำเป็นเอกสาร (เช่น เอกสาร AWS) ง่ายกว่าการฝึกอบรมบุคคล/เอกสารว่าคุณมีสิ่งพิเศษอะไรบ้างภายในองค์กร มีประโยชน์อย่างยิ่งในการจ้างคนใหม่

5. คุณไม่จำเป็นต้องมีพื้นที่หรือพลังงานสำรอง/อินเทอร์เน็ต/อื่นๆ ในสถานที่ตั้ง เพียงพอที่จะให้ผู้คนใช้แล็ปท็อปของตนได้

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

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

Hetzner มี API สำหรับสั่งซื้อเซิร์ฟเวอร์เฉพาะ และ API สำหรับการติดตั้งระบบปฏิบัติการ (หรือสำหรับการรีบูตเพื่อช่วยเหลือและแฟลชรูปภาพที่คุณต้องการ)
ฉันเดาว่าหากฉันกำลังตรวจสอบตัวเลือกเชิงพาณิชย์ ฉันคงจะจัด "ส่วนท้าย"ที่สำนักงานด้วยโซลูชัน ISP เชิงพาณิชย์, IP แบบคงที่, ฮาร์ดแวร์ไอทีที่ดีบางที แต่จากสิ่งที่ฉันรู้ในขณะนี้หากลูกค้าต้องการโฮสติ้ง ฉัน มักจะตรงไปที่การเช่า vps

ตอนนั้นฉันเป็นผู้พัฒนารุ่นน้องมากกว่า ดังนั้นบางทีฉันอาจจะอยู่แต่ก็ไม่พลาดเลย ตามทฤษฎีแล้ว ฉันเห็นด้วยกับสิ่งที่คุณพูด แต่การนำ Dockerfile ไปใช้กับ Google Cloud Run นั้นง่ายกว่ามาก ใช่แล้ว ฉันจ่ายเงินมากกว่าที่จะจัดการ VPS ของตัวเอง แต่ฉันคิดว่านี่เป็นมากกว่าการชดเชยด้วยชั่วโมงการพัฒนาที่บันทึกไว้

- ฮาร์ดแวร์ทางกายภาพมีปัญหา เช่น พัดลมทำงานล้มเหลว ->VM ของฉันถูกย้ายไปยังโฮสต์อื่น ฉันไม่สังเกตเห็นหรือสนใจ
- ฮาร์ดแวร์กายภาพระเบิด ->VM ของฉันรีสตาร์ทบนโฮสต์อื่น ฉันอาจสังเกตเห็น แต่ฉันไม่สนใจ
การวางแผนภัยพิบัตินั้นง่ายกว่ามากด้วย VM (แม้กับสัตว์เลี้ยงไม่ใช่ปศุสัตว์)

สำหรับผู้เริ่มต้น คนที่ถูกที่สุดจะทำงานให้เสร็จ

ฉันแน่ใจว่าเมื่อคลาวด์คอมพิวติ้งพัฒนาขึ้น ข้อเสนอเหล่านี้กลายเป็นเรื่องธรรมดามากขึ้น

มีอีกแง่มุมหนึ่งของคลาวด์คอมพิวติ้ง องค์กรขนาดกลางถึงขนาดใหญ่นับการประมวลผลแบบคลาวด์เป็นเปอร์เซ็นต์หลักเดียวในการคำนวณต้นทุน ซึ่งหมายความว่าการตัดสินใจของผู้จัดการและทีมงาน มักจะค้นหาความน่าเชื่อถือและความสามารถในการปรับขนาด (เพื่อใช้ในการนำเสนอ) แทนที่จะเป็น "การตั้งค่าของฉันแพงหรือถูก"นายจ้างของฉันใช้คลาวด์เป็นธุรกิจ/การเงิน ไม่ใช่การเล่นทางศาสนา เรามักจะฝังงานสร้างใหม่ในระบบคลาวด์และย้ายไปยังศูนย์ข้อมูลตามความเหมาะสมในภายหลัง

แอปในองค์กรมีค่าใช้จ่ายน้อยลงประมาณ 40% แอพที่คุ้มค่ากว่าในระบบคลาวด์อยู่ที่นั่น

ฉันคิดว่าเป็นกรณีที่ AWS/GCP/Azure ไม่ใช่ข้อเสนอที่มีราคาแข่งขันได้ในยุโรป สิ่งที่ฉันไม่เห็นคือหลักฐานของสิ่งนั้นสำหรับสหรัฐอเมริกา

ในสเป็คเดียวกันแน่นอน ฉันคิดว่าเวอร์ชวลสมเหตุสมผลที่ปลายทั้งสอง - ความสามารถในการปรับขนาดไดนามิกสำหรับ N ขนาดใหญ่นั้นสำคัญ หรือคุณต้องการเพียงแค่ส่วนเล็กๆ ของฟิสิคัลบ็อกซ์เท่านั้น การจ่ายเงิน 45/เดือนสำหรับบางสิ่งที่ทำงานบน 5/เดือนก็ไม่สมเหตุสมผลเช่นกัน และทำให้คุณมีความยืดหยุ่นมากขึ้นในการไม่รวมสิ่งต่างๆ เข้าด้วยกันเพียงเพื่อใช้เซิร์ฟเวอร์ของคุณ

สำรองข้อมูลในทุกกรณี โดยเฉพาะอย่างยิ่งกับผู้ให้บริการรายอื่นหรืออย่างน้อยในสถานที่ทางกายภาพที่แตกต่างกัน และแน่นอนทดสอบพวกเขา

และหากคุณจัดการระบบการสำรองข้อมูลที่ดีและตรวจสอบข้อมูล/แอปของคุณอยู่แล้ว
--
[1] ในความเป็นจริง หากคุณทำกระบวนการกู้คืนไปยังตำแหน่งอื่นโดยอัตโนมัติ ซึ่งฉันทำเพื่อบิตของฉัน จากนั้นคุณสามารถกดปุ่มนั้นและอัปเดต DNS เมื่อเสร็จสิ้น และอาจจัดสรร RAM + คอร์เพิ่มเติมอีกเล็กน้อย (การทดสอบของฉัน มิเรอร์มีขนาดเล็กกว่า Live VM เนื่องจากไม่จำเป็นต้องรองรับรูปแบบการใช้งานจริง)

สิ่งที่ฉันทำเพื่อตัวเองและลูกค้าของฉัน ช่วยประหยัดปริมาณ dosh

แม้ว่าฉันต้องการอัปเดต แต่ก็เป็นเพียงกรณีของการดึงเวอร์ชันล่าสุดลงในเทมเพลตที่เขียนโดยนักเทียบท่าและเรียกใช้ playbook ที่ไม่สามารถแก้ไขได้อีกครั้ง เห็นได้ชัดว่าหากการอัปเกรดต้องการมากกว่านี้ก็ช่างมันเถอะ แต่ก็ไม่ต่างอะไรกับการตั้งค่าอื่นๆ ที่ชาญฉลาด

สิ่งเดียวที่ฉัน _need_ ต้องทำด้วยตนเองคือทดสอบการสำรองข้อมูลของฉัน แต่ฉันมีสคริปต์สำหรับแต่ละโปรเจกต์ซึ่งทำแบบนั้น ฉันแค่เปิด SSH รัน one-liner ตรวจสอบผลลัพธ์ เท่านี้ก็เสร็จเรียบร้อย ฉันทำประมาณเดือนละครั้ง แต่ฉันยังได้รับอีเมลหากการสำรองข้อมูลล้มเหลว
จึงจะไม่มีเวลาได้เลย. โดยปกติแล้วอาจใช้เวลา 1-2 ชั่วโมงต่อเดือนหากฉันรับการอัปเดตแบบกึ่งประจำ แต่นั่นจะขยายตามสิ่งที่คุณโฮสต์และจัดการมากขึ้น

กล่าวอีกนัยหนึ่ง ข้อแตกต่างเพียงอย่างเดียวคือแหล่งที่มาของไฟล์สินค้าคงคลัง ansible อาจเป็นรายการ IP แบบคงที่หรือมาจาก Terraform

หากคุณต้องการ ECC RAM ดูเหมือนว่าจะเป็น 60 ต่อเดือน และยังเพิ่มเป็น CPU 8 คอร์ที่ทรงพลังกว่าอีกด้วย

โดยไม่คำนึงว่า หากเรากำลังพูดถึง "สภาพแวดล้อมการผลิตเต็มรูปแบบและสภาพแวดล้อมการจัดเตรียม/สแตนด์บายที่ซ้ำกัน"(เพื่ออ้างถึงบุคคลที่คุณตอบกลับ) ดังนั้น 60/เดือน * (2 หรือ 3) ก็ยังถือว่าถูกเมื่อเทียบกับ AWS ของสตาร์ทอัพใดๆ บิลที่ฉันเคยเห็น

กรณีการใช้งานแตกต่างกันไป แต่ฉันมักจะยอมรับว่า AWS/GCP/Azure ไม่ใช่คำตอบสำหรับทุกปัญหา

สำหรับคนที่สามารถนำแอปพลิเคชันของตนไปใช้กับ VPS มูลค่า 4 ดอลลาร์ แน่นอนว่าจะมีราคาถูกกว่าโลหะเปล่าๆ ทั่วไป แต่คลาวด์จะขยายขนาดขึ้นอย่างแพงมากในหลายกรณี Bare Metal ไม่ใช่คำตอบสำหรับทุกปัญหาเช่นกัน แต่ผู้คนจำนวนมากในอุตสาหกรรมดูเหมือนจะไม่ยินดีเมื่อมันสามารถเป็นคำตอบที่ถูกต้องได้