服务器功耗计算器_无服务器在您的用例中便宜吗? 用这个计算器找出答案。

服务器功耗计算器

When talking about serverless, cost savings and auto-scaling are the first benefits that come to mind. Companies expect reduced operations time and lower costs to deliver more value on features critical to their business.

当谈到无服务器时,节省成本和自动扩展是首先想到的好处。 公司期望减少运营时间和降低成本,从而为他们的业务关键功能提供更多价值。

A dream (at least for investors).

一个梦想(至少对于投资者而言)。

I guess you’ve read this theory a few times already. And still, how can you be sure that serverless is the right fit for you? That your use case is indeed cheaper with serverless?

我想你已经读过几次这个理论了。 而且, 如何确定无服务器适合您? 没有服务器,您的用例确实便宜吗?

Today I will shine some light on how much an AWS serverless architecture could cost you. To help with that, we (at Theodo) created an easy to use but complete AWS serverless cost calculator! Maybe it will give you a little incentive to invest more in the technology.

今天,我将向您介绍无服务器AWS架构可能要花多少钱 。 为了解决这个问题,我们( 在Theodo )创建了一个易于使用但完整的AWS无服务器成本计算器! 也许这会给您一点动力,以便您在技术上进行更多的投资。

⚠️ If you already know about TCO, FinOps and serverless architecture, you should directly jump to the calculator’s presentation (the link doesn’t work on mobile, go to the half of the page).

If️如果您已经了解TCO,FinOps和无服务器架构,则应直接 跳到计算器的演示文稿 (该链接在移动设备上不起作用,请转到页面的一半)。

要了解无服务器的价值,请考虑总拥有成本 (To understand the value of serverless think Total Cost of Ownership)

One core concept often mentioned when talking serverless cost is the Total Cost of Ownership (TCO):

在谈论无服务器成本时,经常提到的一个核心概念是总拥有成本(TCO):

Image for post

At the end of the month, when you receive your serverless bill, you mainly see one number. If you want to compare this number with non-serverless app costs, you shouldn’t simply compare it to infrastructure costs, you should broaden your comparison and also include:

在月底,当您收到无服务器账单时,主要看到一个数字。 如果您想将此数字与非无服务器应用程序成本进行比较,则不应该将其与基础设施成本进行简单的比较,应该扩大比较范围,还应包括:

  • a chunk of Ops salaries

    大块的Ops薪水
  • SaaS bills such as your monitoring tool

    SaaS账单,例如您的监控工具
  • development efforts, for generic features like authentication, tech maturity or skills build-up

    开发工作,用于认证,技术成熟度或技能积累等通用功能

This high-level perspective is key when assessing the economic value of serverless, as serverless encompasses TCO’s 3 variables in one bill.

当评估无服务器的经济价值时,这种高层观点是关键,因为无服务器在一个账单中包含了TCO的3个变量

To give a concrete example:

举一个具体的例子:

  • A service such as Lambda is managed, monitored and auto-scalable by design, which means reducing the operational burden to handle classic performance issues and system maintenance.

    诸如Lambda之类的服务可以通过设计来管理,监视和自动扩展,这意味着可以减轻操作负担,以处理经典的性能问题和系统维护。
  • Another service like Cognito is pre-packaging an always up-to-date industry-standard way of handling authentication, users and authorisation, seamlessly auto-wired to other AWS services, which means you won’t have to spend developer days on rebuilding or rewiring something similar in your architecture.

    诸如Cognito之类的另一项服务正在预先打包一种始终最新的行业标准方式来处理身份验证,用户和授权,并自动自动连接到其他AWS服务,这意味着您无需花费开发人员的时间进行重建或重新布线您的架构中的类似内容。

Yan Cui wrote a good case explaining how serverless indeed lowers costs when looking through the TCO lens. Deloitte published a white paper on the topic in which they compare serverless vs more traditional approaches on each TCO component using real examples.

Yan Cui 撰写了一个很好的案例,解释了无服务器如何通过TCO镜头确实降低了成本。 德勤发布了有关该主题的白皮书 ,他们在其中使用真实示例比较了每个TCO组件上的无服务器方法和传统方法。

无服务器成本控制:借助正确的技能,该技术可实现功能级成本优化 (Serverless costs control: With the right set of skills, the technology enables feature-level cost optimisation)

There are many examples showing how cloud costs can get out of control (like this fresh one). With AWS, you cannot define cost ceilings. You can only create cost alarms. Which is not as reassuring as it should be.

有许多示例说明了云成本如何失控( 例如,这一新的成本)。 使用AWS,您无法定义成本上限。 您只能创建成本警报。 没有那么令人放心。

The possibility of being hit by an over-spending is real. Just like the possibility of slow, or worse, crashed, systems in a classical architecture because of un-planned traffic. This is a direct consequence of the big shift in paradigm that serverless is. It is also an amazing opportunity: cloud providers are giving us the power to scale instantly, which reduces the effort of hiring and managing a dedicated team.

被超支击中的可能性是真实的。 就像由于未计划的流量而导致传统体系结构中的系统变慢甚至崩溃的可能性一样。 这是无服务器模式发生重大转变的直接结果。 这也是一个了不起的机会:云提供商正在为我们提供即时扩展的能力,这减少了雇用和管理专门团队的工作量。

To counter this over-spending fear, some Ops and Architect tasks are moving towards FinOps. As a FinOps you optimise your system “slightly” less for performance and maintenance reasons, and a lot more for financial ones. Serverless gives you the tools for a complete and granular cost control over each feature and each piece of your architecture. You can see where you spend more than you should. You can assess the very ROI of a feature to better understand its impact on the business. Which is what a company always ends up looking at. Cloud providers are “merely” abstracting generic complexity away, and creating a shortcut toward more financial control.

为了应对这种过度支出的担忧, 一些Ops和Architect任务正在向 FinOps转移 。 作为FinOps,出于性能和维护方面的考虑,您对系统的“稍微”较少的优化,而对于财务方面的,则需要更多的优化。 Serverless为您提供了工具,可以对您的每个功能和体系结构的每个部分进行全面,精细的成本控制。 您可以看到花在哪里的钱比应该花的多。 您可以评估功能的投资回报率,以更好地了解其对业务的影响 。 公司总是要看的是什么。 云提供商“仅仅是”消除了通用的复杂性,并创建了实现更多财务控制的捷径。

一些固定的体系结构意见有助于估算无服务器项目成本 (Some fixed architectural opinions help estimate a serverless project cost)

To help people estimate the cost of a serverless project and to share best FinOps practices, we decided to build an AWS serverless cost calculator. This calculator is meant to be easy to use while including each component of a complete architecture.

为帮助人们估算无服务器项目的成本并共享最佳FinOps做法, 我们决定构建一个AWS无服务器成本计算器。 该计算器易于使用,同时包含完整体系结构的每个组件。

Why is it different from what you can already find online? Because it relies on an opinion of what a serverless architecture should look like. That’s where we used our FinOps skills, arbitrating what services and how to use them to simplify the process of estimating an AWS serverless app cost.

为什么与您已经可以在网上找到的东西不同? 因为它依赖于无服务器架构的外观 。 那就是我们使用FinOps技能的地方,可以仲裁哪些服务以及如何使用它们来简化估算AWS无服务器应用程序成本的过程。

I agree that all architectures are different, and costs can change many-fold because of some differences. But at the same time most web applications share a lot of common elements: authentication, a database with some models, an API to get and update those models, a few files on a system, some asynchronous tasks and a couple of advanced workflows (think e-commerce checkout funnel or multi-step identity validation).

我同意所有架构都是不同的,并且由于某些差异,成本可能会发生许多变化。 但与此同时, 大多数Web应用程序共享许多公共元素 :身份验证,具有某些模型的数据库,用于获取和更新这些模型的API,系统上的一些文件,一些异步任务以及一些高级工作流程(请考虑一下)电子商务结帐渠道或多步骤身份验证)。

By standardising what a typical serverless architecture can be, it makes easier the task of estimating costs for typical use cases. It also creates a place for thorough discussions and welcome challenges within the community to aim for consensus toward always more optimised systems.

通过标准化典型的无服务器体系结构,可以简化估算典型用例成本的任务。 它还为在社区内进行全面讨论和迎接挑战提供了场所,以期就不断优化的系统达成共识。

These opinionated principles can be found in my previous article: What a typical 100% Serverless Architecture looks like in AWS! I invite you to read it to fully understand the calculator.

这些自以为是的原则可以在我以前的文章中找到: AWS中典型的100%无服务器架构是什么样的! 我邀请您阅读以充分了解计算器。

使用计算器,您可以通过两种方式进行估算:以预定义的方案为指导,或者使用自己的输入进行定义 (With the calculator, you have two ways to estimate: either be guided by pre-defined scenarios, or define one with your own inputs)

⚠️ This initiative is a continuous work in progress, it is based on our experiences at Theodo. So some scenarios or hypotheses might not reflect well your own use-case. Simplifying and generalising a way to calculate costs of complex systems is hard, and requires more learnings from experiences.

initiative️该倡议是一项持续不断的工作,它基于我们在Theodo的经验。 因此,某些方案或假设可能无法很好地反映您自己的用例。 简化和概括计算复杂系统成本的方法非常困难,并且需要从经验中学习更多。

🙏 Please share your experience with us! Either will we give you tips on better practices, or you will teach us something that will help refine the calculator for the community. To contribute, you can leave comments in the original spreadsheet, in this article or contact me on Twitter.

🙏请与我们分享您的经验! 我们要么为您提供更好的实践技巧,要么您可以教给我们一些有助于改进社区计算器的知识。 要做出贡献,您可以在原始电子表格中,本文中发表评论,或 在Twitter上 与我联系

The calculator is accessible here 🤘. You can access it as a “Commenter”, then duplicate it and try it on (note: dropdowns don’t work in “Commenter” mode).

可在此处访问 计算器 。 您可以将其作为“评论员”进行访问,然后将其复制并尝试使用(注意:下拉菜单在“评论员”模式下不起作用)。

The spreadsheet is divided into two types of tabs: The first tab is the main dashboard where you’ll get your total cost estimation. You fill in as-easy-as-can-be inputs and get a total cost and a per AWS service drill down.

电子表格分为两种类型的标签: 第一个标签是主仪表板,您可以在其中获取总费用估算 。 您填写尽可能容易的输入,并获得总成本和每个AWS服务的深入分析。

Image for post

You have two options here:

您在这里有两个选择:

  • Pre-defined: Select a scenario to get a very general idea of costs. You can go for an e-commerce with a high traffic, let us do the rest of the estimation and see the final result on the right in the “Pre-defined” green frame.

    预定义 :选择一种方案以获得非常一般的成本概念。 您可以选择流量大的电子商务,让我们进行其余的估算,并在右侧的“预定义”绿色框中查看最终结果。

  • Custom: Input finer grained variables based on your business specificities (type of features and users behaviour) then see the result in the “Custom” blue frame.

    自定义 :根据您的业务特点(功能类型和用户行为)输入更细粒度的变量,然后在“自定义”蓝色框中查看结果。

The other tabs are the detailed calculations of each AWS service used. It has a list of the AWS cost constants, the hypotheses we made for the calculation variables, a progressive detail of the calculations and of course the total at the end.

其他选项卡是所使用的每个AWS服务的详细计算 。 它包含一个AWS成本常量列表,我们对计算变量所做的假设,计算的逐步细节以及最后的总计。

Image for post

That’s where the magic of our calculator really operates. The amount of variables required when using the official AWS cost calculator is huge. Even when you know well those services, it still takes time to properly fill each of them. So from experience, by narrowing down basic use cases, we fixed certain services, certain variables and thus simplified the estimation process.

这就是我们计算器真正发挥作用的地方。 使用正式的AWS成本计算器时所需的变量数量巨大。 即使您对这些服务非常了解,也仍然需要时间来适当地填充每个服务。 因此,根据经验,通过缩小基本用例,我们固定了某些服务和某些变量,从而简化了估算过程。

在中小型项目上,直接的成本收益是显而易见的,但是在考虑总体拥有成本时,大型和复杂项目仍然可以从该技术中受益。 (Straight cost benefits are obvious on small and medium-sized projects, but big and complex ones still benefit from the technology when considering the TCO.)

Let’s take a shot at it together by going over some examples. We will try to see if serverless is worth it, and you’ll be able to compare those costs with your own.

让我们通过一些示例来一起看一下。 我们将尝试看看无服务器是否值得,并且您可以将这些成本与自己的成本进行比较。

对于平均流量或以下的流量,我们无需计算总拥有成本即可见证无服务器价值 (For average traffics or below, we don’t need to calculate the TCO to witness serverless value)

Low traffic: 50 sessions/day

低流量:每天50次会话

Image for post

Using the calculator, at this traffic a e-commerce app costs ~1.6$/month (free tier included), and a blog ~0.5$.

使用计算器,在这种流量下,电子商务应用程序的费用约为每月1.6美元(包括免费套餐),而博客的费用约为0.5美元。

In comparison, the cost per month of the smallest EC2 VM, the t3a.nano, is 3.43$ (official EC2 pricing here).

相比之下,最小的EC2 VM t3a.nano的每月成本为3.43美元( 此处EC2官方价格 )。

Result: Advantage serverless, even more because it comes extra boosted with services. Compared to a VM, which is basic, where you’ll have to add a database, monitoring, manage scalability yourself, etc.

结果 :无服务器的优势,甚至更多,因为它通过服务得到了进一步的增强。 与基本的VM相比,您必须添加数据库,监视,自己管理可伸缩性等。

Medium traffic: 2k sessions/day

中等流量:每天2k会话

Image for post

A serverless e-commerce app costs ~70$/month, and a blog ~20$.

无服务器的电子商务应用程序的费用约为每月70美元,博客的费用约为20美元。

The cost of one corresponding EC2 VM, like the m6g.large, is ~62$.

一个相应的EC2 VM(例如m6g.large)的成本约为62 $。

Result: Advantage serverless, for similar reasons as for low traffic.

结果 :无服务器的优势,原因与低流量类似。

高流量和非常高的流量更难评估,但认为TCO开启了无服务器的潜力 (High and very-high traffics are more difficult to evaluate but thinking TCO opens up serverless potential)

High traffic: 40k sessions/day — Very high traffic: 1m sessions/day

高流量:每天40k会话-极高流量:每天100万会话

Image for post

A high traffic serverless e-commerce costs ~1.7k$/month, and a very high ~49k$.

高流量的无服务器电子商务成本约为每月1.70万美元,非常高的约为4.9万美元。

A blog, respectively ~475$ and ~12k$.

一个博客,分别为〜475 $和〜12k $。

Note for very high traffic: AWS offers important discounts not reflected here.

高流量说明:AWS提供重要折扣,此处未反映。

For such traffic, cost estimation becomes a bit more hazardous. Triple confirmation with some community and AWS folks who faced real world experiences showed similar costs (in magnitude) ✅.

对于此类流量,成本估算变得更加危险。 与一些面对现实世界经验的社区和AWS人员的三重确认显示出相似的成本(数量级)✅。

Now, comparing VMs to a serverless architecture of this size is not as representative. Those systems are much more complex, in size and mix of technologies.

现在,将虚拟机与这种规模的无服务器架构进行比较并不具有代表性。 这些系统的规模和技术组合都更加复杂。

That’s where we can bring the TCO notion back. Deloitte says that, with serverless, systems maintenance time can be divided by 8. So for the sake of the exercise, let’s consider that a serverless Ops team is half the size of a more traditional one, and that a high traffic traditional website needs a team of 2 Ops.

那就是我们可以带回TCO概念的地方。 德勤表示,在无服务器的情况下,系统维护时间可以除以8 。 因此,为了便于练习,让我们考虑一个无服务器的Ops团队是一个传统团队的一半,而一个高流量的传统网站需要2个Ops团队。

The cost of one of those engineers for a company in Paris would be 140k$/year. This employee cost includes: her/his salary, the company-paid taxes, the healthcare participation, the office space rent and more. With serverless, our Ops team goes down to 1 Ops, which allows us to “save” 12k$/month.

在巴黎的一家公司中,一名工程师的费用为每年14万美元。 员工成本包括:她/他的薪水,公司缴纳的税费,医疗保健参予,办公室租金和更多。 使用无服务器,我们的运营团队降至1个运营,这使我们“每月”节省了12,000美元。

Result: Still pretty positive for serverless: when you pay 1.7k$/month to AWS, being able to redirect 12k$/month to business differentiated tasks looks like a great idea!

结果 :对于无服务器仍然相当乐观:当您每月向AWS支付1.7k $时,能够将12k $ /月重定向到业务差异化的任务似乎是个好主意!

试试吧,挑战您的现状,如有任何问题或改善,请与我联系! (Try it, challenge your status quo, and reach me for any question or improvement!)

I hope this initiative gave you some new perspectives and answered or raised questions! That was the whole point: taking a step back, looking at the big picture with concrete examples and formulas, and witness together the potential of serverless.

我希望这项倡议能给您一些新的观点,并回答或提出问题! 这就是重点:退后一步,用具体的示例和公式查看全局,一起见证无服务器的潜力。

What’s next? With this first release, we want to gather plenty of feedback and aim for a wider, easier-to-use version by the end of the year (a web application would be neat). We would definitely like to add other cloud providers to provide better context on vendor choice. If you’re interested in future developments of the tool follow me on Twitter.

下一步是什么? 在第一个发行版中,我们希望收集大量反馈,并希望在今年年底之前开发出更广泛,更易于使用的版本(Web应用程序会很整洁)。 我们绝对希望添加其他云提供商,以在供应商选择方面提供更好的环境。 如果您对该工具的未来发展感兴趣,请在Twitter上关注我。

资料来源 (Sources)

Calculators

计算器

Articles / Books

文章/书籍

FinOps Tools

FinOps工具

翻译自: https://medium.com/serverless-transformation/is-serverless-cheaper-for-your-use-case-find-out-with-this-calculator-2f8a52fc6a68

服务器功耗计算器

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值