第一次創業要注意什麼?

11 年前,我是一名窮困潦倒的學生,背負著1.4 萬英鎊的債務準備畢業。在這種情況下,我做了任何一位明智的人都會做的事情,開公司。10 年後,我已小有成就,但是其中的過程卻漫長而又艱辛。以下就是我學到的。
評論
評論

做新創公司就像不斷被打臉,可是替大公司工作就像是接受水刑 —Paul Graham

編者註:這是有人在 問答網站 Quora 上提出的問題。Silktide 創始人 Oliver Emberton 的回答贏得了 1500 多票的支持 ,我們把他的建議編譯出來,希望能幫助想要創業的你。

11 年前,我是一名窮困潦倒的學生,背負著 1.4 萬英鎊的債務準備畢業。在這種情況下,我做了任何一位明智的人都會做的事情,開公司。10 年後,我已小有成就,但是其中的過程卻漫長而又艱辛。以下就是我學到的:

關於創辦人

行動第一(Firstly, do it.)

我身邊的所有人,包括我的家人和好友,他們都質疑這是不是好主意(許多人一開始都支持,但當日子過得艱難時便改變了主意)。如果你認為必須要做這件事,那就別讓他們阻止你,也別指望有誰會支持你。

保持真誠(Start with total brutal honesty.)

要我說,這是生活的第一守則。每個人都會在某種程度上自欺欺人—大家聚在一起往往很容易就會相互欺騙對方。但是,你看待世界的態度越真誠,你做出的決定就會越好。質疑自己。質疑一切。如果有人拿把槍指著你的腦袋,你會不會改變想法?如果這樣也阻止不了你的計劃,那這個計劃可能就是相當好的計劃了。

學會說不(Practice saying no. A lot.)

你想做的事情肯定有很多。就本性而言,所有的行業創辦人都這樣—在他們看來,機會遍地都是,想著要改變世界(我也不例外)。但這是一種非常糟糕的公司經營方式。你需要對極少數事情保持專注,要把那點事做得真正好,而這就意味著要對其他 1,000 件事情說不。其難度要高於你的想像,但是它的能量同樣遠超你的想像。

學會發展(Growing past 2-3 people will cripple most founders.)

大多數小企業都是由了解行業的人獨自起家的:會計師開會計事務所,麵包師開麵包坊;我曾是一名 Geek,於是我開了一家 Web 設計公司。這些人會發現,當公司發展到 2-3 人以後局面會變得極端困難,很多時候他們都想努力去找一個水準跟自己一樣好的人,到頭來卻以厭倦和沮喪告終,試圖自己包辦一切。如果你只能要一本商業書參考的話,我的推薦是「創業教父」邁克爾格伯的《創業必經的那些事(E-Myth Revisited)》,如果沒有時間看看這些 筆記(英文)也成。

關於商業創意

別怕改變(Don’t be afraid to change tacks.)

有一種說法是這樣的,計劃永遠趕不上變化。任天堂一開始是做紙牌遊戲、Facebook 本來是給大學生用的。我自己的公司做了 10 年網站設計,然後又改成做軟體。改變方向不一定就會讓你變弱或顯得沒有決斷力—你只是需要調整自己,找到最合適的方向。這件事要早點做,但也不要經常做。(注:Paul Graham 曾說過,大多數 VC 期望創辦人對未來有一個清晰的規劃,但鮮有人意識到,最大的成功正在於當初的計劃跟新創公司最終的樣子毫無關係:正所謂有心栽花花不開、無意插柳柳成蔭。)

保持專注(Just one. Powerful. Idea.)

你可以融合補充性的想法(比如餐廳裡可以有喜劇表演),但是不要把不相干的領域混到一起(比如說提供顧問服務的餐廳就不行)。開始的時候只挑選想法裡面的一些關鍵點,然後專心致志地把它做好。拒絕其他所有的東西。

愛或需求(A successful business is either loved or needed.)

做到既被人喜歡又為人所需是十分罕見的,儘管我們總是傾向於認為大家喜歡我們(還記得第一守則:真誠面對自己?)。確保自己對於客戶要么不可或缺,要么無法抗拒。一般情況下,如果你的客戶是商家的話,你得是必需的—比如會計、律師、web 設計師;如果你的客戶是普通消費者,你就應該是人見人愛的—如 iPhone、電影院、化妝品等。

另眼看己(Imagine being an outside investor.)

假裝自己是一位白手起家、有很多錢但沒有時間的人。如果這個人現在要找你,聽你講解自己的生意。你該如何想?這聽起來像不像一筆好的投資?再次強調—要真誠面對自己(譯註:做一個沒打算在財務上取得成功的企業也是可以的。但很少有創業者會認為自己要開的不是一家能賺大錢的公司)

保持激情(Imagine being an outside investor.)

真正的激情是很有感染力的。激情可以扭轉對前景的質疑,能讓員工對你死心塌地,激情將賜予你無窮的力量,在別人認輸時讓你繼續前行。如果你對所做沒有激情(我就犯過這樣的錯誤)—有朝一日你會質問自己:“我讓自己陷入一種什麼樣的境地?”

關於行銷

行銷≠洗腦(Marketing isn’t about changing people’s minds.)

你的工作不是去說服別人要你的東西。而是去幫助你的潛在客戶去說服自己,你的東西能幫助他們得到自己想要的東西。

該花則花(A few things not to skimp upon.)

商標、品牌口號、網站都是必不可少的;這是你給別人留下的第一印象,也是你不在場時留下的唯一訊息(如果你是面對商家銷售的,還要加上「名片」)。如果你需要專業輔助,那就去找。不要禁不住省錢的誘惑,找自己的小外甥幫忙或自己來。這跟自己當自己的律師沒什麼兩樣,結果是災

難性的。這些事情不一定就要花大錢—只需簡化需求,強調品質重於數量。在你開始賺錢之前,信箋抬頭、郵件註腳什麼的都不重要。

做好創意(Advertising is a tax you pay for being unremarkable.)

廣告是平庸想法的稅負。好創意很容易兜售;偉大的創意不出門也能走千里。你做的東西解釋起來和賣出去越困難,你的想法就越得啄磨。有兩個解決方案:簡化所做的事情,或者徹底調整方向。把糟糕的創意弄得越來越複雜並不能讓你賣得更好。

每個人的路只能靠自己走出來,可是花點時間學習最優秀的前人能節省你大量的時間並緩解很多的壓力。強烈建議你讀一下這三本書:《創業必經的那些路(The E-Myth Revisited)》、《與成功有約(7 Habits of Highly Effective People)》以及《在家就能讀 MBA :掌握經營的藝術(Personal MBA)》,要想提前一年做好創業計劃,只看這三本書就夠了。

我認識的所有嘗試創業的人普遍都有這麼一個慨嘆:要是早點做就好了。如果你認為這個聲音一直在召喚的話,你的藉口又是什麼?

 

 

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!