mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-10 22:21:11 +08:00
Translated by qhwdw
This commit is contained in:
qhwdw
parent
ea24c3bdd1
commit
44b19cc1fd
@ -1,154 +0,0 @@
|
||||
Translating by qhwdw
|
||||
The Cost of Cloud Computing
|
||||
============================================================
|
||||
|
||||
### A day in the life of two development teams
|
||||
|
||||
|
||||
|
||||
|
||||
Over the last few months, I’ve talked with a number people who are concerned about the cost of public cloud services in comparison to the price of traditional on-premises infrastructure. To provide some insights from the discussion, let’s follow two development teams within an enterprise — and compare how they would approach building a similar service.
|
||||
|
||||
The first team will deploy their application using traditional on-premises infrastructure, while the second will leverage some of the public cloud services available on AWS.
|
||||
|
||||
The two teams are being asked to develop a new service for a global enterprise company that currently serves millions of consumers worldwide. This new service will need to meet theses basic requirements:
|
||||
|
||||
1. The ability to scale to meet elastic demands
|
||||
|
||||
2. Provide resiliency in response to a datacenter failure
|
||||
|
||||
3. Ensure data is secure and protected
|
||||
|
||||
4. Provide in-depth debugging for troubleshooting
|
||||
|
||||
5. The project must be delivered quickly
|
||||
|
||||
6. The service be cost-efficient to build and maintain
|
||||
|
||||
As far as new services go, this seems to be a fairly standard set of requirements — nothing that would intrinsically favor either traditional on-premises infrastructure over the public cloud.
|
||||
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
#### 1 —Scaling to meet customer demands
|
||||
|
||||
When it comes to scalability, this new service needs to scale to meet the variable demands of consumers. We can’t build a service that might drop requests and cost our company money and cause reputational risk.
|
||||
|
||||
The Traditional Team With on-premises infrastructure, the architectural approach dictates that compute capacity needs to be sized to match your peak data demands. For services that features a variable workload, this will leave you with a lot of excess and expensive compute capacity in times of low utilization.
|
||||
|
||||
This approach is wasteful — and the capital expense will eat into your profits. In addition, there is a heavy operational costs with maintaining your fleet of underutilized servers. This is a cost that is often overlooked — and I cannot emphasize enough how much money and time will be wasted supporting a rack of bare-metal servers for a single service.
|
||||
|
||||
The Cloud Team With a cloud-based autoscaling solution, your application scales up and down in-line with demand. This means that you’re only paying for the compute resources that you consume.
|
||||
|
||||
A well-architected cloud-based application enables the act of scaling up and down to be seamless — and automatic. The development team defines auto-scaling groups that spin up more instances of your application based on high-CPU utilization, or a large number of requests per second, and you can customize these rules to your heart’s content.
|
||||
|
||||
* * *
|
||||
|
||||
#### 2- Resiliency in response to failure
|
||||
|
||||
When it comes to resiliency, hosting a service on infrastructure that resides within the same four walls isn’t an option. If your application resides within a single datacenter — then you are stuffed when ( _not if_ ) something fails.
|
||||
|
||||
The Traditional Team To meet basic resiliency criteria for an on-premises solution, this team would a minimum of two servers for local resiliency — replicated in a second data center for geographic redundancy.
|
||||
|
||||
The development team will need to identify a load balancing solution that automatically redirects traffic between sites in the event of saturation or failure — and ensure that the mirror site is continually synchronized with the entire stack.
|
||||
|
||||
The Cloud Team Within each of their 50 regions worldwide, AWS provides multiple _availability zones_ . Each zone consists of one of more fault-tolerant data centers — with automated failover capabilities that can seamlessly transition AWS services to other zones within the region.
|
||||
|
||||
Defining your _ infrastructure as code_ within a CloudFormation template ensures your infrastructure resources remain consistent across the zones during autoscaling events — and the AWS load balancer service requires minimal effort to setup and manage the traffic flow.
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
#### 3 — Secure and protect your data
|
||||
|
||||
Security is be a fundamental requirement of any system being developed within an organization. You really don’t want to be one of the unfortunate companies dealing with fallout from a security breach.
|
||||
|
||||
The Traditional Team The traditional team will incur the ongoing costs of ensuring that the bare-metal servers that’s running their services is secure. This means investing in a team that is trying to monitor, identify, and patch security threats across multiple vendor solutions from a variety of unique data sources.
|
||||
|
||||
The Cloud Team Leveraging the public cloud does not exempt yourself from security. The cloud team still has to remain vigilant, but doesn’t have to worry about patching the underlying infrastructure. AWS actively works combat against zero-day exploits — most recently with Spectre and Meltdown.
|
||||
|
||||
Leveraging the identify management and encryption security services from AWS allows the cloud team to focus on their application — and not the undifferentiated security management. The API calls to AWS services are fully audited using CloudTrail, which provides transparent monitoring.
|
||||
|
||||
* * *
|
||||
|
||||
#### 4 — Monitoring and logging
|
||||
|
||||
Every infrastructure and application service being deployed need to be closely monitored with aggregated realtime data. The teams should have access to dashboards that provide alerts when thresholds are exceeded, and offer the ability to leverage logs for event correlation for troubleshooting.
|
||||
|
||||
The Traditional Team For traditional infrastructure, you will have to set up monitoring and alerting solutions across disparate vendors and snowflake solutions. Setting this up takes a hell of a lot of time — and effort and getting it right is incredibly difficult.
|
||||
|
||||
For many applications deployed on-premises, you may find yourself searching through log files stored on your server’s file-system in order to make sense of why your application is crashing. A lot of time will be wasted as teams need to ssh into the server, navigate to the unique directory of log files, and then grep through potentially hundreds of files. Having done this for an application that was deployed across 60 servers — I can tell you that this isn’t a pretty solution.
|
||||
|
||||
The Cloud Team Native AWS services such as CloudWatch and CloudTrail make monitoring cloud applications an absolute breeze. Without much setup, the development team can monitor a wide variety of different metrics for each of the deployed services — making the process of debugging issues an absolute dream.
|
||||
|
||||
With traditional infrastructure, teams need build their own solution, and configure their REST API or service to push log files to an aggregator. Getting this ‘out-of-the-box’ is an insane improvement fo productivity.
|
||||
|
||||
* * *
|
||||
|
||||
#### 5 — Accelerate the development
|
||||
|
||||
The ability to accelerate time-to-market is increasingly important in today’s business environment. The lost opportunity costs for delayed implementations can have a major impact on bottom-line profits.
|
||||
|
||||
The Traditional Team For most organizations, it takes a long time to purchase, configure and deploy hardware needed for new projects — and procuring extra capacity in advance leads to massive waste due to poor forecasting.
|
||||
|
||||
Most likely, the traditional development team will spend months working across the myriad of silos and hand-offs to create the services. Each step of the project will require a distinct work request to database, system, security, and network administrators.
|
||||
|
||||
The Cloud Team When it comes to developing new features in a timely manner, having a massive suite of production-ready services at the disposal of your keyboard is a developer’s paradise. Each of the AWS services is typically well documented and can be accessed programmatically via your language of choice.
|
||||
|
||||
With new cloud architectures such a serverless, development teams can build and deploy a scalable solution with minimal friction. For example, in just a couple of days I recently built a [serverless clone of Imgur][4] that features image recognition, a production-ready monitoring/logging solution built-in, and is incredibly resilient.
|
||||
|
||||
|
||||
|
||||
If I had to engineer the resiliency and scalability myself, I can guarantee you that I would still be developing this project — and the final product would have been nowhere near as good as it currently is.
|
||||
|
||||
Using serverless architecture, I experimented and delivered the solution in a less time that it takes to provision hardware in most companies. I simply glued together a series of AWS services with Lambda functions — and ta-da! I focused on developing the solution, while the undifferentiated scalability and resiliency is handled for me by AWS.
|
||||
|
||||
* * *
|
||||
|
||||
#### The cost verdict on cloud computing
|
||||
|
||||
When it comes to scalability, the cloud team is the clear winner with demand-drive elasticity — thus only paying for compute power that they need. The team no longer needs dedicated resources devoted to maintaining and patching the underlying physical infrastructure.
|
||||
|
||||
The cloud also provides development teams a resilient architecture with multiple availability zones, security features built into each service, consistent tools for logging and monitoring, pay-as-you-go services, and low-cost experimentation for accelerated delivery.
|
||||
|
||||
More often than not, the absolute cost of cloud will amount to less than the cost of buying, supporting, maintaining, and designing the on-premises infrastructure needed for your application to run — with minimal fuss.
|
||||
|
||||
By leveraging cloud we can move faster and with the minimal upfront capital investment needed. Overall, the economics of the cloud will actively work in your favor when developing and deploying your business services.
|
||||
|
||||
There will always be a couple of niche examples where the cost of cloud is prohibitively more expensive than traditional infrastructure, and a few situations where you end up forgetting that you have left some incredibly expensive test boxes running over the weekend.
|
||||
|
||||
[Dropbox saved almost $75 million over two years by building its own tech infrastructure
|
||||
After making the decision to roll its own infrastructure and reduce its dependence on Amazon Web Services, Dropbox…www.geekwire.com][5][][6]
|
||||
|
||||
However, these cases remain few and far between. Not to mention that Dropbox initially started out life on AWS — and it was only after they had reached a critical mass that they decided to migrate off the platform. Even now, they are overflowing into the cloud and retain 40% of their infrastructure on AWS and GCP.
|
||||
|
||||
The idea of comparing cloud services to traditional infrastructure-based of a single “cost” metric is incredibly naive — it blatantly disregards some of the major advantages the cloud offers development teams and your business.
|
||||
|
||||
In the rare cases when cloud services result in a greater absolute cost than your more traditional infrastructure offering — it still represents a better value in terms of developer productivity, speed, and innovation.
|
||||
|
||||
|
||||
|
||||
Customers don’t give a shit about your data centers
|
||||
|
||||
_I’m very interested in hearing your own experiences and feedback related to the true cost of developing in cloud! Please drop a comment below, on Twitter at _ [_@_ _Elliot_F_][7] _, or connect with me directly on _ [_LinkedIn_][8] _._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://read.acloud.guru/the-true-cost-of-cloud-a-comparison-of-two-development-teams-edc77d3dc6dc
|
||||
|
||||
作者：[Elliot Forbes][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://read.acloud.guru/@elliot_f?source=post_header_lockup
|
||||
[1]:https://info.acloud.guru/faas-and-furious?utm_campaign=FaaS%20and%20Furious
|
||||
[2]:https://read.acloud.guru/building-an-imgur-clone-part-2-image-rekognition-and-a-dynamodb-backend-abc9af300123
|
||||
[3]:https://read.acloud.guru/customers-dont-give-a-shit-about-your-devops-pipeline-51a2342cc0f5
|
||||
[4]:https://read.acloud.guru/building-an-imgur-clone-part-2-image-rekognition-and-a-dynamodb-backend-abc9af300123
|
||||
[5]:https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/
|
||||
[6]:https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/
|
||||
[7]:https://twitter.com/Elliot_F
|
||||
[8]:https://www.linkedin.com/in/elliotforbes/
|
||||
151
translated/tech/20180301 The Cost of Cloud Computing.md
Normal file
151
translated/tech/20180301 The Cost of Cloud Computing.md
Normal file
@ -0,0 +1,151 @@
|
||||
云计算的成本
|
||||
============================================================
|
||||
|
||||
### 两个开发团队的一天
|
||||
|
||||
|
||||
|
||||
|
||||
几个月以前，我与一些人讨论过关于公共云服务成本与传统专用基础设施价格比较的话题。为给你提供一些见解，我们来跟踪一下一个企业中的两个开发团队 — 并比较他们构建类似服务的方式。
|
||||
|
||||
第一个团队将使用传统的专用基础设施来部署他们的应用，而第二个团队将使用 AWS 提供的公共云服务。
|
||||
|
||||
这两个团队被要求为一家全球化企业开发一个新的服务，该企业目前为全球数百万消费者提供服务。要开发的这项新服务需要满足以下基本需求：
|
||||
|
||||
1. 能够随时扩展以满足弹性需求
|
||||
|
||||
2. 具备应对数据中心故障的弹性
|
||||
|
||||
3. 确保数据安全以及数据受到保护
|
||||
|
||||
4. 为排错提供深入的调试功能
|
||||
|
||||
5. 项目必须能迅速分发
|
||||
|
||||
6. 服务构建和维护的性价比要高
|
||||
|
||||
就新服务来说，这看起来是非常标准的需求 — 从本质上看传统专用基础设备上没有什么东西可以超越公共云了。
|
||||
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
#### 1 — 扩展以满足客户需求
|
||||
|
||||
当说到可扩展性时，这个新服务需要去满足客户变化无常的需求。我们构建的服务不可以拒绝任何请求，以防让公司遭受损失或者声誉受到影响。
|
||||
|
||||
传统的团队使用的是专用基础设施，架构体系的计算能力需要与峰值数据需求相匹配。对于负载变化无常的服务来说，大量昂贵的计算能力在低利用率的时间被浪费掉。
|
||||
|
||||
这是一种很浪费的方法 — 并且大量的资本支出会侵蚀掉你的利润。另外，这些未充分利用的庞大的服务器资源的维护也是一项很大的运营成本。这是一项你无法忽略的成本 — 我不得不再强调一下，为支持一个单一服务去维护一机柜的服务器是多么的浪费时间和金钱。
|
||||
|
||||
云团队使用的是基于云的自动伸缩解决方案，应用会按需要进行自动扩展和收缩。也就是说你只需要支付你所消费的计算资源的费用。
|
||||
|
||||
一个架构良好的基于云的应用可以实现无缝地伸缩 — 并且还是自动进行的。开发团队只需要定义好自动伸缩的资源组即可，即当你的应用 CPU 利用率达到某个高位、或者每秒有多大请求数时启动多少实例，并且你可以根据你的意愿去定制这些规则。
|
||||
|
||||
* * *
|
||||
|
||||
#### 2 — 应对故障的弹性
|
||||
|
||||
当说到弹性时，将托管服务的基础设施放在同一个房间里并不是一个好的选择。如果你的应用托管在一个单一的数据中心 — （不是如果）发生某些失败时（译者注：指坍塌、地震、洪灾等），你的所有的东西都被埋了。
|
||||
|
||||
传统的团队去满足这种基本需求的标准解决方案是，为实现局部弹性建立至少两个服务器 — 在地理上冗余的数据中心之间实施秒级复制。
|
||||
|
||||
开发团队需要一个负载均衡解决方案，以便于在发生饱合或者故障等事件时将流量转向到另一个节点 — 并且还要确保镜像节点之间，整个栈是持续完全同步的。
|
||||
|
||||
在全球 50 个区域中的每一个云团队，都由 AWS 提供多个_有效区域_。每个区域由多个容错数据中心组成 — 通过自动故障切换功能，AWS 可以在区域内将服务无缝地转移到其它的区中。
|
||||
|
||||
在一个 `CloudFormation` 模板中定义你的_基础设施即代码_，确保你的基础设施在自动伸缩事件中跨区保持一致 — 而对于流量的流向管理，AWS 负载均衡服务仅需要做很少的配置即可。
|
||||
|
||||
* * *
|
||||
|
||||
#### 3 — 安全和数据保护
|
||||
|
||||
安全是一个组织中任何一个系统的基本要求。我想你肯定不想成为那些不幸遭遇安全问题的公司之一的。
|
||||
|
||||
传统团队为保证运行他们服务的基础服务器安全，他们不得不持续投入成本。这意味着将不得不向监视、识别、以及为来自不同数据源的跨多个供应商解决方案的安全威胁打补丁的团队上投资。
|
||||
|
||||
使用公共云的团队并不能免除来自安全方面的责任。云团队仍然需要提高警惕，但是并不需要去担心为底层基础设施打补丁的问题。AWS 将积极地对付各种 0 日漏洞 — 最近的一次是 Spectre 和 Meltdown。
|
||||
|
||||
利用来自 AWS 的识别管理和加密安全服务，可以让云团队专注于他们的应用 — 而不是无差别的安全管理。使用 `CloudTrail` 对 API 到 AWS 服务的调用做全面审计，可以实现透明地监视。
|
||||
|
||||
* * *
|
||||
|
||||
#### 4 — 监视和日志
|
||||
|
||||
任何基础设施和部署为服务的应用都需要严密监视实时数据。团队应该有一个可以访问的仪表板，当超过指标阈值时仪表板会显示警报，并能够在排错时提供与事件相关的日志。
|
||||
|
||||
使用传统基础设施的传统团队，将不得不在跨不同供应商和“雪花状”的解决方案上配置监视和报告解决方案。配置这些“见鬼的”解决方案将花费你大量的时间和精力 — 并且能够正确地实现你的目的是相当困难的。
|
||||
|
||||
对于大多数部署在专用基础设施上的应用来说，为了搞清楚你的应用为什么崩溃，你可以通过搜索保存在你的服务器文件系统上的日志文件来找到答案。为此你的团队需要通过 SSH 进入服务器，导航到日志文件所在的目录，然后浪费大量的时间，通过 `grep` 在成百上千的日志文件中寻找。如果你在一个横跨 60 台服务器上部署的应用中这么做 — 我能负责任地告诉你，这是一个极差的解决方案。
|
||||
|
||||
云团队利用原生的 AWS 服务，如 CloudWatch 和 CloudTrail，来做云应用程序的监视是非常容易。不需要很多的配置，开发团队就可以监视部署的服务上的各种指标 — 问题的排除过程也不再是个恶梦了。
|
||||
|
||||
对于传统的基础设施，团队需要构建自己的解决方案，配置他们的 REST API 或者服务去推送日志到一个聚合器。而得到这个“开箱即用”的解决方案将对生产力有极大的提升。
|
||||
|
||||
* * *
|
||||
|
||||
#### 5 — 加速开发进程
|
||||
|
||||
现在的商业环境中，快速上市的能力越来越重要。由于实施延误所失去的机会成本，可能成为影响最终利润的一个主要因素。
|
||||
|
||||
大多数组织的这种传统团队，他们需要在新项目所需要的硬件采购、配置和部署上花费很长的时间 — 并且由于预测能力差，提前获得的额外的性能将造成大量的浪费。
|
||||
|
||||
而且还有可能的是，传统的开发团队在无数的“筒仓”中穿梭以及在移交创建的服务上花费数月的时间。项目的每一步都会在数据库、系统、安全、以及网络管理方面需要一个独立工作。
|
||||
|
||||
而云团队开发新特性时，拥有大量的随时可投入生产系统的服务套件供你使用。这是开发者的天堂。每个 AWS 服务一般都有非常好的文档并且可以通过你选择的语言以编程的方式去访问。
|
||||
|
||||
使用新的云架构，例如无服务器，开发团队可以在最小化冲突的前提下构建和部署一个可扩展的解决方案。比如，只需要几天时间就可以建立一个 [Imgur 的无服务器克隆][4]，它具有图像识别的特性，内置一个产品级的监视/日志解决方案，并且它的弹性极好。
|
||||
|
||||
|
||||
|
||||
如果必须要我亲自去设计弹性和可伸缩性，我可以向你保证，我仍然在开发这个项目 — 而且最终的产品将远不如目前的这个好。
|
||||
|
||||
从我实践的情况来看，使用无服务器架构的交付时间远小于在大多数公司中提供硬件所花费的时间。我只是简单地将一系列 AWS 服务与 Lambda 功能 — 以及 ta-da 耦合到一起而已！我只专注于开发解决方案，而无差别的可伸缩性和弹性是由 AWS 为我处理的。
|
||||
|
||||
* * *
|
||||
|
||||
#### 关于云计算成本的结论
|
||||
|
||||
就弹性而言，云计算团队的按需扩展是当之无愧的赢家 — 因为他们仅为需要的计算能力埋单。而不需要为维护和底层的物理基础设施打补丁付出相应的资源。
|
||||
|
||||
云计算也为开发团队提供一个可使用多个有效区的弹性架构、为每个服务构建的安全特性、持续的日志和监视工具、随用随付的服务、以及低成本的加速分发实践。
|
||||
|
||||
大多数情况下，云计算的成本要远低于为你的应用运行所需要的购买、支持、维护和设计的按需基础架构的成本 — 并且云计算的麻烦事更少。
|
||||
|
||||
通过利用云计算，我们可以更少的先期投入而使业务快速开展。整体而言，当你开发和部署业务服务时，云计算的经济性可以让你的工作更赞。
|
||||
|
||||
也有一些云计算比传统基础设施更昂贵的例子，一些情况是在周末忘记关闭运行的一些极其昂贵的测试机器。
|
||||
|
||||
[Dropbox 在决定推出自己的基础设施并减少对 AWS 服务的依赖之后，在两年的时间内节省近 7500 万美元的费用，Dropbox…www.geekwire.com][5][][6]
|
||||
|
||||
即便如此，这样的案例仍然是非常少见的。更不用说当初 Dropbox 也是从 AWS 上开始它的业务的 — 并且当它的业务达到一个临界点时，才决定离开这个平台。即便到现在，他们也已经进入到云计算的领域了，并且还在 AWS 和 GCP 上保留了 40% 的基础设施。
|
||||
|
||||
将云服务与基于单一“成本”指标（译者注：此处的“成本”仅指物理基础设施的购置成本）的传统基础设施比较的想法是极其幼稚的 — 公然无视云为开发团队和你的业务带来的一些主要的优势。
|
||||
|
||||
在极少数的情况下，云服务比传统基础设施产生更多的绝对成本 — 它在开发团队的生产力、速度和创新方面仍然贡献着更好的价值。
|
||||
|
||||
|
||||
|
||||
客户才不在乎你的数据中心呢
|
||||
|
||||
_我非常乐意倾听你在云中开发的真实成本相关的经验和反馈！请在下面的评论区、Twitter _ [_@_ _Elliot_F_][7] 上、或者直接在 _ [_LinkedIn_][8] 上联系我。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://read.acloud.guru/the-true-cost-of-cloud-a-comparison-of-two-development-teams-edc77d3dc6dc
|
||||
|
||||
作者：[Elliot Forbes][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://read.acloud.guru/@elliot_f?source=post_header_lockup
|
||||
[1]:https://info.acloud.guru/faas-and-furious?utm_campaign=FaaS%20and%20Furious
|
||||
[2]:https://read.acloud.guru/building-an-imgur-clone-part-2-image-rekognition-and-a-dynamodb-backend-abc9af300123
|
||||
[3]:https://read.acloud.guru/customers-dont-give-a-shit-about-your-devops-pipeline-51a2342cc0f5
|
||||
[4]:https://read.acloud.guru/building-an-imgur-clone-part-2-image-rekognition-and-a-dynamodb-backend-abc9af300123
|
||||
[5]:https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/
|
||||
[6]:https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/
|
||||
[7]:https://twitter.com/Elliot_F
|
||||
[8]:https://www.linkedin.com/in/elliotforbes/
|
||||
Loading…
Reference in New Issue
Block a user