初创企业股权架构

Before you can launch a new service, you need infrastructure. You want reliability, scalability, and many other -ilities. But you don’t want to break the bank.

在启动新服务之前，您需要基础架构。 您需要可靠性，可伸缩性和许多其他功能。 但是你不想破产。

I’ve gone through the process of launching several new services over the past few years. Each time, I’ve explored the field of options.

在过去的几年中，我经历了启动多个新服务的过程。 每次，我都探索选项的领域。

The goal of this article is to help you focus on the value that your solution provides to your users, while minimizing the time and money spent geeking out on infrastructure.

本文的目的是帮助您专注于解决方案为用户提供的价值，同时最大程度地减少花费在基础设施上的时间和金钱。

We’ll use turn-key hosting services for everything, and the goal is for the bill to be under $200/month.

我们将为所有内容使用交钥匙托管服务，目标是使每月账单低于200美元。

Note that I have no affiliation — nor hold any stake — in any of the products or services I recommend in this article. I just like what they do.

请注意，我在本文推荐的任何产品或服务中都没有从属关系，也没有任何股权。 我喜欢他们的工作。

Let’s get started. Here’s what do you’ll need:

让我们开始吧。 这是您需要的：

• A high availability API高可用性API
• A web application (unless your service is purely an API, or is only consumed in a mobile application, chatbot, etc.)Web应用程序(除非您的服务纯粹是API，或者仅在移动应用程序，聊天机器人等中使用)
• File storage档案储存
• Two environments: one for testing and demoing, and one for production两种环境：一种用于测试和演示，另一种用于生产
• Tools to monitor your production platform监控生产平台的工具
• The ability to dynamically scale your production servers动态扩展生产服务器的能力

生产与分期 (Production VS Staging)

You’ll need two environments: a production one, which your customers will actually use, and a “staging” one, which your team will use for testing and potentially demoing beta features to customers.

您将需要两个环境：一个生产环境，一个客户将实际使用的环境，以及一个“阶段”环境，您的团队将使用该环境来测试和潜在地向客户演示Beta功能。

Staging should require minimal setup to run your applications. You shouldn’t need to worry about load testing for this.

登台应仅需最少的设置即可运行您的应用程序。 您不必为此担心负载测试。

Your production environment will have all its services load-balanced, with at least two instances of everything for reliability’s sake. In a moment we’ll get to some basic — yet comprehensive — tools that can help you achieve 24/7 monitoring.

生产环境将平衡所有服务的负载，至少有两个实例都是出于可靠性考虑。 稍后，我们将介绍一些基本但全面的工具，这些工具可以帮助您实现24/7全天候监控。

后端托管 (Back End Hosting)

I recommend you host your back-end API on Heroku. It works with most languages. You can view the full list of supported languages here. Note that although ASP.NET is not yet officially supported, there are open source build packs that make this possible.

我建议您在Heroku上托管后端API。 它适用于大多数语言。 您可以在此处查看支持的语言的完整列表。 请注意，尽管尚未正式支持ASP.NET，但是仍有开源构建包使之成为可能。

While some developers may argue that raw AWS EC2 instances are cheaper than Heroku dynos, this is only true when you look at the server’s cost. Since Heroku is much faster to set up and integrates more easily with extra services, you’ll save hours of developer work, should more than make up for the price difference.

尽管一些开发人员可能会认为原始AWS EC2实例比Heroku dynos便宜，但这仅在您查看服务器成本时才是正确的。 由于Heroku的设置速度更快，并且可以轻松地与其他服务集成，因此，您将节省开发人员的工作时间，而这不仅可以弥补价格差异。

Let’s start by creating a Heroku pipeline for your API with two steps: staging and production. You’ll deploy by pushing your code to the staging application. Then, once you’ve tested it, you’ll “promote” a version of staging to production. This process will help prevent faulty deployments from reaching your production servers — and ultimately your customers.

首先，通过两个步骤为您的API创建Heroku管道：过渡和生产。 您将通过将代码推送到暂存应用程序进行部署。 然后，一旦您对其进行了测试，就可以“升级”到生产的过渡版本。 此过程将有助于防止错误的部署到达您的生产服务器，甚至最终到达客户。

Your pipeline will look as below (read more details here):

您的管道如下所示( 在此处了解更多详细信息)：

I recommend you start with:

我建议您从以下内容开始：

• 1 hobby dyno at $7/month for staging每月进行一次$ 7的每月1步动态测功
• 2 standard-1X dynos for production at $25/month each2台标准1X测功机，每台每月25美元

Cost: $57/month

费用：$ 57 /月

数据库托管 (Database Hosting)

If you’re using PostgreSQL, just use Heroku’s service for this. It will be more consistent network-wise, and you’ll get one line of billing instead of two.

如果您使用的是PostgreSQL，则只需使用Heroku的服务即可。 从网络角度来看，这将更加一致，您将获得单行计费，而不是两行计费。

For the more generic case, use Compose. The lowest resource plans are more than OK for the early stage. Scale the resources “slider style” upon need.

对于更通用的情况，请使用Compose 。 最低的资源计划在早期阶段是可以接受的。 根据需要扩展资源的“滑块样式”。

Compose covers the must have: node failover, daily backups, SSL encryption, and a basic monitoring panel.

Compose涵盖了必须具备的内容：节点故障转移，每日备份，SSL加密和基本监视面板。

You could run the staging and production databases on one “deployment” in Compose. But to keep your production data isolated and safe from corruption from untested code, you should use two separate databases.

您可以在Compose的一个“部署”中运行登台和生产数据库。 但是，为了保持生产数据隔离并防止未经测试的代码损坏，您应该使用两个单独的数据库。

For the costs, we take the MongoDB as benchmark for $31/month per deployment (PostgreSQL would be $27/month).

对于成本，我们以MongoDB为基准，每个部署每月31美元(PostgreSQL每月27美元)。

Cost: $62/month

成本：$ 62 /月

A quick note on using mlab for MongoDB hosting: We started out with mlab, too. We had a fancy dedicated replica set of 2 nodes with 1.7 GB of RAM and 40 GB SSD. All for the price of $260/month ($180 for the cluster itself and $80 just to turn on SSL).

关于使用mlab进行MongoDB托管的快速说明：我们也是从mlab开始的。 我们有一个花哨的专用副本集，其中包含2个节点，1.7 GB的RAM和40 GB的SSD。 全部价格为260美元/月(群集本身为180美元，而打开SSL则为80美元)。

The service was good — especially their monitoring component, telemetry.

服务很好-尤其是其监视组件遥测 。

But after a few months run and a few thousand users, all graphs still showed less than 10% consumption. The cluster was overkill, and would be for some time. So we moved to Compose and scaled gradually there to reduce costs.

但是经过几个月的运行和数千名用户之后，所有图表仍然显示不到10％的消耗量。 该集群过大，将持续一段时间。 因此，我们搬到了Compose并逐步扩展以降低成本。

前端托管 (Front End Hosting)

I recommend using Netlify. It’s quite straight-forward:

我建议使用Netlify 。 这很简单：

• connect with your BitBucket/GitHub/GitLab account与您的BitBucket / GitHub / GitLab帐户连接
• select the repository and branch to deploy选择要部署的存储库和分支
• set your build command, and the build folder you want to serve设置您的构建命令，以及您要提供的构建文件夹

Pushing to the right Git branch will trigger your build on Netlify’s servers, then automatically deploy it to their CDN. You can read more about how all this works here.

推送到右侧的Git分支将触发您在Netlify服务器上的构建，然后将其自动部署到其CDN。 您可以在此处阅读有关所有这些工作原理的更多信息。

There are two more steps:

还有两个步骤：

• point your DNS to your Netlify URL using a CNAME record使用CNAME记录将DNS指向Netlify URL
• enable SSL on the Netlify panel. It will provision and auto-deploy a Let’s Encrypt TLS certificate within minutes.在Netlify面板上启用SSL。 它将在几分钟之内配置并自动部署Let's Encrypt TLS证书。

Then create projects as follows:

然后如下创建项目：

• one for the staging app on a non-master git branch一个用于非主git分支上的登台应用程序
• one for the production app for your master git branch一个用于主git分支的生产应用程序

Use the free plan for the staging platform and the $9/month plan for the production platform. You will quickly scale to the $49/month plan to bring in your team. But this is not needed at start. When you reach millions of users worldwide you can upgrade again to use the Geo-IP CDN.

将免费计划用于登台平台，将每月9美元的计划用于生产平台。 您将Swift扩展到每月49美元的计划，以吸引您的团队。 但这在一开始就不需要。 当您遍及全球数百万用户时，您可以再次升级以使用Geo-IP CDN。

Cost: $9/month

费用：9美元/月

文件托管 (File Hosting)

For file hosting, I recommend AWS S3 (Simple Storage Service). Create two buckets — one for staging and one for production.

对于文件托管，我建议使用AWS S3(简单存储服务)。 创建两个存储桶-一个用于暂存，另一个用于生产。

The content is distributed via the AWS CDN, and data can be stored and retrieved securely. There are more details here on how to set up buckets securely.

内容通过AWS CDN分发，并且可以安全地存储和检索数据。 还有更多的细节在这里就如何安全地设置桶。

The first 5GB (now even 15GB I think) are free. Then the cost is at $0.03 per GB (at least for their EU/Ireland location). So early on, you may not even have to pay anything.

前5 GB(我认为现在甚至是15 GB)都是免费的。 然后，成本为每GB 0.03美元(至少对于它们在欧盟/爱尔兰的位置而言)。 如此一来，您甚至不必支付任何费用。

Cost: $0/month

成本：$ 0 /月

On a side note, I recommend you send data to AWS S3 directly from your web app to lighten the load on your API. There are plenty of articles on the web for how to do this securely.

附带说明一下，建议您直接从Web应用程序将数据发送到AWS S3，以减轻API的负担。 网上有很多文章介绍如何安全地执行此操作。

域和SSL (Domain and SSL)

Get a domain name, which for most top-level domains will cost less than $50/year.

获取一个域名，对于大多数顶级域名而言，其价格每年不到$ 50。

Then you can generate certificates for all your endpoints using Let’s Encrypt. It provides CA enabled SSL certificates — which are trusted by major browsers — for free.

然后，您可以使用Let's Encrypt为所有端点生成证书。 它免费提供支持CA的SSL证书，这些证书受到主要浏览器的信任。

Cost: $50/year

费用：每年50美元

监控工具 (Monitoring Tools)

Monitoring your production platform is key. You need to know when errors occur so you can quickly fix them. Users will not make the effort to report small problems, but their impression of your service will nevertheless be degraded.

监视生产平台是关键。 您需要知道何时发生错误，以便快速修复它们。 用户不会尽力报告小问题，但是他们对您的服务的印象仍然会下降。

Comprehensive monitoring requires:

全面监控要求：

• API rotating logs with proactive error line detectionAPI旋转日志，具有主动错误线检测功能
• active reporting of client- and server-side exceptions and errors主动报告客户端和服务器端异常和错误
• uptime monitoring正常运行时间监控
• performance metrics on your API and database, so you know when to scaleAPI和数据库上的性能指标，因此您知道何时进行扩展
• a central place to report all the errors so you can act quickly报告所有错误的中心位置，因此您可以Swift采取行动

松弛 (Slack)

You can use Slack to aggregate all the error reports in a single communication hub. Slack is built for teams, but if you’re working alone on your project, these tools will be your team.

您可以使用Slack将所有错误报告汇总在一个通信中心中。 Slack是为团队而建的，但是如果您一个人在项目上工作，那么这些工具将成为您的团队。

Create an account on Slack and a channel called #prod-errors. You’ll configure all your other services to report errors on Slack.

在Slack和一个名为＃prod-errors的频道上创建一个帐户。 您将配置所有其他服务以报告Slack上的错误。

Once you install each services’ Slack app and enable its notifications for desktop and mobile, you’ll be good to go.

一旦安装了每个服务的Slack应用程序并为台式机和移动设备启用了其通知，就可以了。

This is the startup version of 24/7 on-call monitoring.

这是24/7通话监控的启动版本。

记录中 (Logging)

I recommend Papertrail for log management. It provides:

我建议使用Papertrail进行日志管理。 它提供：

• a simple web based console for logs from all your API dynos一个简单的基于Web的控制台，用于存储来自所有API dynos的日志
• daily backup of your logs in a separate storage location日志的每日备份在单独的存储位置
• alert configuration, to ping you when necessary警报配置，必要时可以Ping您

This is how it looks:

看起来是这样的：

Not so sexy at first glance, but in the end the UX is close to a real server console, so it does the trick.

乍一看并没有那么性感，但最终UX接近真实的服务器控制台，因此就可以了。

Add Papertrail as an add-on for your Heroku staging and production apps. Use the free plan for the staging platform. Use the $7/month “Fixa” plan for the production platform to get the 50MB/day of logs and history for 1 year.

将Papertrail添加为Heroku舞台和生产应用程序的附加组件。 将免费计划用于登台平台。 使用生产平台每月7美元的“ Fixa”计划，每天可获得50MB /天的日志和历史记录，为期一年。

Configure a Papertrail alert to push errors lines to your Slack #prod-errors channel.

配置Papertrail警报以将错误行推送到Slack ＃prod-errors通道。

Be careful. The logs are pushed from your dynos to add-ons via a component called logplex. If you have an algorithm that produces thousands of lines in a few milliseconds, logplex will drop them.

小心。 日志通过名为logplex的组件从您的dynos推送到附件。 如果您有一种算法可以在几毫秒内产生数千行，logplex将删除它们。

Cost: $7/month

费用：每月7美元

Alternatives: You can plug other tools in one click on Heroku. See the full list here.

替代方案：您可以一键式将其他工具插入Heroku。 在这里查看完整列表。

You can add and remove logging add-ons without restarting your app, so it’s pretty safe to play around. You can even test several solutions in parallel and compare them.

您可以在不重新启动应用程序的情况下添加和删除日志记录附件，因此可以安全地玩耍。 您甚至可以并行测试多个解决方案并进行比较。

In my opinion other logging systems are overkill at the start. Logentries provides advanced analytics, but only on the $89/month plan. Sumologic is also a great tool, but for it’s only necessary when you have millions of users. Then it will be able to detect changes in log flows and application behavior.

在我看来，其他日志系统在一开始就显得过分杀伤力。 Logentries提供高级分析功能，但仅以每月89美元的价格提供。 Sumologic也是一个很好的工具，但是只有在拥有数百万用户的情况下才有必要。 然后，它将能够检测到日志流和应用程序行为的变化。

哨兵 (Sentry)

Your API, web app, and mobile applications should report errors and exceptions to Sentry. Integration is turn-key. It just involves copy-pasting a few lines into your project in any technology out there.

您的API，Web应用程序和移动应用程序应向Sentry报告错误和异常。 集成是交钥匙的。 它仅涉及使用任何现有技术将几行内容复制粘贴到您的项目中。

Setup Sentry to also push errors to your Slack #prod-errors channel.

设置哨兵也将错误推送到您的Slack ＃prod-errors频道。

Sentry’s free plan is OK, as it allows 5,000 events per day. So unless you have a bug in a mobile app distributed to thousands of users, it should hold. Use the first paid plan at $29/month if your team is at least two people, so all of your team members have access to the portal.

Sentry的免费计划还可以，因为它每天允许5,000个事件。 因此，除非您在分发给成千上万个用户的移动应用程序中存在错误，否则该错误应该保留。 如果您的团队至少有两个人，则使用每月29美元的第一个付费计划，因此您的所有团队成员都可以访问门户。

Cost: $29/month

费用：$ 29 /月

机器人 (Uptimerobot)

This is a health check to know whether your service is up.

这是一项运行状况检查，以了解您的服务是否启动。

To set it up:

进行设置：

• configure one endpoint for your API (and add some authentication free endpoint like /version if needed)

  为您的API配置一个端点(并根据需要添加一些免认证端点，例如/ version )

• configure one endpoint for your web app in its index.html file在其index.html文件中为您的Web应用程序配置一个端点

Set up Uptimerobot to push downtime alerts to your Slack #prod-errors channel.

设置Uptimerobot，将停机警报推送到您的Slack ＃prod-errors频道。

Use the free plan (there’s only a free plan at this point).

使用免费计划(目前只有免费计划)。

Cost: $0/month

成本：$ 0 /月

天秤座 (Librato)

Heroku provides decent metrics for your API, but it’s limited to three days of history. Librato has longer history and a more comprehensive dashboard.

Heroku为您的API提供了不错的指标，但是历史记录仅限于三天。 Librato具有较长的历史和更全面的仪表板。

Configure Librato as an add-on for your Heroku apps:

将Librato配置为Heroku应用程序的附件：

• Use the free plan for the staging app将免费计划用于登台应用程序
• Use the $19/month “Nickel” plan for the production app, so you’ll get up to four weeks depth on the graphs使用生产应用程序每月$ 19的“镍”计划，这样您最多可以在图表上看到4周的深度

The pricing of Librato with Heroku is different than on the Librato website.

Heroku的Librato定价与 Librato网站上的定价不同。

This is enough to get an overview of your API performance. Scale your resources as your throughput and response time increase, to reduce the impact on your user experience.

这足以了解您的API性能。 随着吞吐量和响应时间的增加，扩展资源，以减少对用户体验的影响。

Cost: $19/month

费用：$ 19 /月

支付账单的时间 (Time to pay the bill)

Let’s sum up all the costs I’ve identified so far:

让我们总结一下到目前为止我已经确定的所有成本：

• $57/month for the backend on HerokuHeroku后端每月$ 57
• $62/month for the databases on Compose对于Compose数据库，每月$ 62
• $9/month for the web apps on NetlifyNetlify上的Web应用程序每月9美元
• $50/year for the domain name (split to ~$4/month)域名每年$ 50(每月约$ 4)
• $55/month for the monitoring Papertrail/Sentry/Librato$ 55 /月用于监控Papertrail / Sentry / Librato

Total: $187 / month

总计：每月$ 187

We’ve achieved our goal of being under $200/month. We still have an extra $13/month to spare. Let’s see if we can setup our software engineering stack for this cost.

我们已经实现了每月收入低于200美元的目标。 我们仍然有每月额外的$ 13剩余空间。 让我们看看是否可以为此费用设置软件工程堆栈。

We could use:

我们可以使用：

• Bitbucket for Git repositories. It’s less trendy than GitHub, but offers free private repositories

  用于Git存储库的Bitbucket 。 它不如GitHub流行，但提供免费的私有存储库

• JIRA can serve as an agile planner and bug tracker for $10/month

  JIRA可以充当敏捷计划者和错误跟踪者，每月只需$ 10

• CodeShip has a free plan to automate your API build

  CodeShip有免费计划来自动化您的API构建

• Google Apps only costs $4/month per account. Use one account and aliases for things like office@…, support@…, career@…. These addresses look good, but reach the very same person at the earliest stage of a startup.

  Google Apps每个帐户每月只需花费$ 4。 使用一个帐户和别名来处理诸如office @ …， support @ …， career @ …之类的事情。 这些地址看起来不错，但在初创企业的最早阶段就可以到达同一个人。

I could go on and on, but we should stop here since we’ve exceed the $200 monthly budget by $1 already.

我可以继续下去，但是我们应该在这里停下来，因为我们已经将200美元的每月预算超出了1美元。

结论 (Conclusion)

If you’re a developer and want to launch a SaaS startup or hobby, I hope this article has shown that the infrastructure part is not so difficult if you use the right tools.

如果您是开发人员，并且想启动SaaS启动或业余爱好，我希望本文表明如果使用正确的工具，基础结构部分并不会那么困难。

Even if you aim to become the next big thing, you can still economize during your early stage drive to get your product out there.

即使您打算成为下一件大事，您仍然可以在早期开发阶段就节约成本，以使产品上市。

Focus on the value you bring to users. Not on infrastructure.

专注于您为用户带来的价值。 不在基础架构上。

The solutions provided in this article scale to tens of thousands of users. Set it up right at start, and you’ll be on track for supporting explosive user growth once you achieve traction. I wish you luck in reaching that point as soon as possible.

本文提供的解决方案可扩展到成千上万的用户。 在一开始就对其进行设置，一旦获得牵引力，您将可以按需支持爆炸性的用户增长。 希望您能尽快达到这一点。

Please share this to whoever would be interested. If you like what you read, hit that ❤ button below.

请与有兴趣的人分享。 如果您喜欢阅读的内容，请点击下面的❤按钮。

翻译自: https://www.freecodecamp.org/news/how-your-startup-can-leverage-production-grade-infrastructure-for-less-than-200-month-15c3724038b4/

初创企业股权架构