容器服务器
For the last couple of years both containers and serverless have been the cool new kid on the block, and the popularity is simply not dying down. There are pros and cons of managing your own containers versus letting serverless do it for you. We need to understand and stop comparing these unique technologies with each other because both have awesome valid pain points. Let’s see what they are.
在过去的几年中，容器和无服务器都成为了时尚新手，而且普及程度并没有下降。 管理自己的容器与让无服务器为您完成容器有优点和缺点。 我们需要理解并停止相互比较这些独特的技术，因为两者都有令人敬畏的有效痛点。 让我们看看它们是什么。
什么是无服务器？ (What is serverless?)
Serverless is a development approach that replaces long-running virtual machines with computing power that comes into being on demand, and immediately disappears after use.
无服务器是一种开发方法，它用需要的计算能力代替了长时间运行的虚拟机，并在使用后立即消失。
Even beyond the term, the application definitely has servers involved in running it. It’s just that the cloud service company operates these servers, whether it’s AWS, Azure or the Google Cloud Platform, and they’re not always running.
即使超过该期限，该应用程序肯定也包含运行它的服务器。 只是云服务公司运营着这些服务器，无论是AWS，Azure还是Google Cloud Platform，而且它们并不总是在运行。
Great examples would be to host static websites on S3, use serverless databases such as DynamoDB or Aurora Serverless, and, of course, running code without running Lambda servers. Also you can configure events that cause your serverless feature to run, such as API requests or file uploads. And when that action is complete, the server goes idle until you ask for another action and you are not paid for the idle period.
很好的例子是在S3上托管静态网站，使用无服务器数据库(例如DynamoDB或Aurora Serverless)，并且当然在不运行Lambda服务器的情况下运行代码。 您还可以配置导致无服务器功能运行的事件，例如API请求或文件上传。 并且，当该操作完成后，服务器将一直处于空闲状态，直到您请求其他操作，并且在空闲时间段内未获得任何付款。
无服务器的优点 (Pros of serverless)
The first advantage is you just pay for time while the operation is being executed by the server. As mentioned earlier, the server only operates when it is triggered by an event, and when the server is running, you will only pay for the short period. Save the money!
第一个优点是您只需为服务器执行操作的时间付费。 如前所述，服务器仅在事件触发时才运行，并且在服务器运行时，您只需为短时间付费。 省钱！
Additionally, you don’t have to manage any infrastructure. There are no operating system updates to install, no security patches, no worries, because the provider handles it for you. Making it much simpler than managing your own infrastructure and clusters
此外，您不必管理任何基础架构。 没有要安装的操作系统更新，没有安全补丁，也没有后顾之忧，因为提供商会为您处理它。 比管理自己的基础架构和集群要简单得多
As such, serverless architectures help you cut down on development time and bring your products to market more quickly. If you don’t have to focus on your infrastructure, then you can spend your time building the best possible product. This is one of the key benefits Jack and his team saw in the serverless world.
因此，无服务器架构可帮助您减少开发时间，并更快地将产品推向市场。 如果您不必专注于基础架构，则可以花费时间来构建最佳产品。 这是杰克和他的团队在无服务器世界中看到的主要好处之一。
Furthermore, serverless allows elasticity in your application. It can scale up automatically to handle a lot of concurrent users and scale back down when traffic subsides. This feature improves your app’s efficiency, while saving you money.
此外，无服务器允许您的应用程序具有弹性。 它可以自动扩展以处理大量并发用户，并在流量减少时缩减。 此功能可以提高应用程序的效率，同时又可以节省资金。
And because serverless functions do not require a long-term hosting location, you do not need to assign them to specific cloud servers and are not limited to specific availability zones. Essentially, this makes them highly available.
而且，由于无服务器功能不需要长期的托管位置，因此您无需将它们分配给特定的云服务器，并且不限于特定的可用性区域。 本质上，这使它们具有很高的可用性。
无服务器的缺点 (Cons of serverless)
Since servers remain cold before an application pinges them, there is a certain amount of latency involved in executing tasks. For applications where speed is paramount, such as e-commerce and search pages, serverless may not be an optimal solution. The initial invocation of a function for the container spin up takes around a second or two. If this is a problem, then rethink using FaaS.
由于服务器在应用程序对其进行ping操作之前仍然处于冷状态，因此执行任务会涉及一定量的延迟。 对于速度至关重要的应用程序，例如电子商务和搜索页面，无服务器可能不是最佳解决方案。 容器旋转功能的初始调用大约需要一到两秒钟。 如果这是一个问题，请重新考虑使用FaaS。
Another con of serverless is that you have very little control over the server. You can usually select the amount of memory your function gets, but then your CSP will assign a small amount of disk storage and decide for you the rest of the specifications. When you need something like a GPU to process large image or video files, it can be an obstacle.
无服务器的另一个缺点是您对服务器几乎没有控制权。 通常，您可以选择函数获得的内存量，但是CSP将分配少量的磁盘存储空间，并为您确定其余的规范。 当您需要诸如GPU之类的功能来处理大型图像或视频文件时，可能会成为一个障碍。
Because of the event-based nature of serverless, long-running apps don’t have the best option. Online games and apps that analyze very large data sets will not be a good fit for a serverless architecture, as serverless functions have time limits (typically five minutes) before they end.
由于无服务器的基于事件的性质，长时间运行的应用程序没有最佳选择。 分析无数数据集的在线游戏和应用程序不适合无服务器体系结构，因为无服务器功能在结束之前有时间限制(通常为5分钟)。
However the simplicity of deployment is what makes the serverless unbelievable. You deploy your Provider code and it works. No setups for Dockerfiles or Kubernetes.
但是，部署的简单性使无服务器变得令人难以置信。 您部署您的提供程序代码，它可以工作。 没有设置Dockerfiles或Kubernetes。
Finally, complex apps can be difficult to build using a serverless architecture. You ‘re going to have to do a lot of coordination and manage dependencies between all serverless functions, which can be a tough job for large , complicated applications.
最后，使用无服务器架构可能很难构建复杂的应用程序。 您将必须进行大量的协调并管理所有无服务器功能之间的依赖关系，这对于大型，复杂的应用程序而言可能是一项艰巨的工作。
什么是容器？ (What is a container?)
According to Docker, a container is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, and settings.
根据Docker的说法 ，容器是软件的轻量级独立可执行软件包，其中包括运行它所需的一切：代码，运行时，系统工具，系统库和设置。
Because containers share system resources with the host server instead of emulating a virtual operating system, they are more efficient than virtual machines.
因为容器与主机服务器共享系统资源而不是模拟虚拟操作系统，所以它们比虚拟机更有效。
In addition, by isolating the application from the external host environment, the containers allow the application to be deployed without friction. As long as your host server supports whatever runtime container you use, you can deploy containerized applications on it without having to worry about tweaking the configuration of the application or fighting environment variables to get things working. Containers fix the problem of running software when it has been moved from a single computing environment by essentially isolating it from the environment. For example, containers allow you to move software from development to staging and from staging to production, and run it reliably regardless of the differences in all environments.
另外，通过将应用程序与外部主机环境隔离，容器使应用程序的部署不会产生摩擦。 只要您的主机服务器支持您使用的任何运行时容器，就可以在其上部署容器化的应用程序，而不必担心调整应用程序的配置或应对环境变量进行操作。 通过将软件从单个计算环境中移出，容器可以从本质上将其与环境隔离，从而解决了软件运行问题。 例如，容器使您可以将软件从开发转移到阶段，从阶段转移到生产，并可靠地运行软件，而不管所有环境中的差异如何。
容器的优点 (Pros of containers)
The first advantage of the containers is their portability. The main draw of a container is that you can combine the application and all its dependencies into a neat little package and run it anywhere. This provides an unprecedented level of flexibility and portability and allows you to remain a cloud-based agnostic provider.
容器的第一个优点是它们的便携性。 容器的主要特点是您可以将应用程序及其所有依赖项组合到一个简洁的小程序包中，然后在任何地方运行它。 这提供了前所未有的灵活性和可移植性，并允许您保持基于云的不可知论者。
By default, using containers means that you won’t have any auto-scaling. It’s something you need to set up on your own. Luckily, vendor-specific tools like AWS Auto Scaling make it more painless. The advantage here is that you have full control of your resources and are in charge of scaling, which means that you can theoretically have infinite scalability. Well, as close as your provider allows you to do.
默认情况下，使用容器意味着您将不会进行任何自动缩放。 您需要自己进行设置。 幸运的是，特定于供应商的工具(例如AWS Auto Scaling)使其变得更加轻松。 这样做的好处是您可以完全控制资源并负责扩展，这意味着从理论上讲您可以具有无限的可伸缩性。 好吧，只要您的提供者允许您这样做。
You ‘re the master of your domain. You can control individual containers, the entire container ecosystem, and the servers they run on. You can manage all resources, set all policies, monitor security, and determine how your application is deployed and how it behaves. You can debug and monitor it as you please. This is not the case for serverless; it’s all managed by your CSP.
您是域的主人。 您可以控制单个容器，整个容器生态系统以及它们在其上运行的服务器。 您可以管理所有资源，设置所有策略，监视安全性，并确定应用程序的部署方式和行为方式。 您可以根据需要调试和监视它。 无服务器不是这种情况。 全部由您的CSP管理。
The ecosystem is so evolved that you’re not going to have any problems setting up the tools you need. Last but not least, your team’s containers will have the same development environment no matter which operating system they use. That makes it incredibly easy for larger teams to be efficient.
生态系统的发展如此之快，以至于设置所需工具不会有任何问题。 最后但并非最不重要的一点是，无论团队的容器使用哪种操作系统，都将具有相同的开发环境。 这使得大型团队的效率变得异常容易。
容器的缺点 (Cons of containers)
The first con is that containers take a lot more time to set up and manage.
第一个缺点是容器需要花费更多的时间来设置和管理。
In reality, all the control and power you have reveals a big drawback-the difficulty it adds. You need to know more about the environment and the different resources at your fingertips. It’s a steep learning curve for everyone, because basically you ‘re the one who deploys and handles the program. To order to have more flexibility and power, you must agree to the fact that the different moving parts will be complex. Unfortunately, this adds more prices. After all, you pay for the utilities all the time, whether you have traffic or not.
实际上，您拥有的所有控制权和能力都显示出一个很大的缺点-它增加了难度。 您需要随时了解更多有关环境和各种资源的信息。 对于每个人来说，这都是一条陡峭的学习曲线，因为从根本上讲，您是部署和处理程序的人。 为了具有更大的灵活性和功能，您必须同意以下事实：不同的运动部件会很复杂。 不幸的是，这增加了更多的价格。 毕竟，无论您是否有流量，都需要始终为公用事业付费。
Any time you make a change to your codebase, you will need to prepare the container and make sure that all the containers interact with each other properly before they are placed into production. You will also need to keep container operating systems up to date with periodic security updates and other patches. And you’ve got to find out which containers are running on which servers. All of this can slow down the cycle of growth.Containers face some scaling issues as well.
每次更改代码库时，都需要准备容器，并确保所有容器在投入生产之前都相互正确交互。 您还需要通过定期的安全更新和其他修补程序使容器操作系统保持最新。 您必须找出哪些容器在哪些服务器上运行。 所有这些都可能减慢增长周期。容器还面临一些扩展问题。
The first issue is monitoring. As the application grows, more and more containers will be added. And these containers are highly dispersed, scattered, and constantly changing, making monitoring a nightmare.
第一个问题是监视。 随着应用程序的增长，将添加越来越多的容器。 这些容器高度分散，分散并且不断变化，使监视成为噩梦。
First, there is no persistence of data when containers are rescheduled or destroyed, so data is often lost when changes are made. Next, given the distributed nature of the containers, it is difficult to move data between different locations or cloud service providers. Storage also doesn’t scale well with apps that lead to unpredictable performance issues.
首先，重新安排或销毁容器时不会保留数据，因此在进行更改时通常会丢失数据。 接下来，鉴于容器的分布式性质，很难在不同位置或云服务提供商之间移动数据。 应用也会导致无法预测的性能问题，因此存储的扩展性也不佳。
您应该在何时使用哪个？ (Which and when should you use each?)
Containers are best used for complex, long-running applications where you need a high level of environmental control and have the resources to set up and maintain the application.
容器最适合需要长期环境控制并拥有设置和维护应用程序资源的复杂，长时间运行的应用程序。
I’d urge you to choose containers and container orchestrators, like Kubernetes, when you need flexibility and full control of your system, or when you need to migrate legacy services.
当需要灵活性和对系统的完全控制或需要迁移旧服务时，我建议您选择容器和容器编排器，例如Kubernetes。
Containers are perfect for an app or a major e-commerce website. A site like this contains (pun intended) many parts, such as product listings, payment processing, inventory management, and more. You can use containers to package any of these services without having to worry about time limits or memory issues.
容器非常适合应用程序或大型电子商务网站。 这样的站点包含(双关语)许多部分，例如产品列表，付款处理，库存管理等等。 您可以使用容器打包所有这些服务，而不必担心时间限制或内存问题。
Choosing serverless is easier when you need faster development speed, auto-scaling, and dramatically lower running time costs. Serverless also links legacy systems as support services that are developed apart from the main codebase to address specific issues or business logic.
当您需要更快的开发速度，自动扩展以及显着降低运行时间成本时，选择无服务器会更加容易。 Serverless还将遗留系统链接为支持服务，该服务是与主代码库分开开发的，用于解决特定问题或业务逻辑。
Serverless is best used for apps that need to be able to perform tasks, but don’t necessarily need to run. For example, serverless is a great option for an Internet of Things ( IoT) application that senses the presence of water to detect leaks in a water storage facility. The app doesn’t have to run all the time, but it needs to be ready to act in the event of a leak.
无服务器最适合需要执行任务但不必运行的应用程序。 例如，无服务器是物联网(IoT)应用程序的绝佳选择，该应用程序可感测水的存在以检测储水设施中的泄漏。 该应用程序不必一直运行，但是需要准备好在发生泄漏时采取行动。
结论 (Conclusion)
Containers and serverless are two increasingly popular development technologies that seem to be constantly being compared and competing with each other. Are you debating whether containers or serverless is right for your applications? Have you considered integrating both of them? I’d love to hear your thoughts.
容器和无服务器是两种越来越流行的开发技术，它们似乎一直在被比较和相互竞争。 您是否在争论容器还是无服务器适合您的应用程序？ 您是否考虑过将两者整合？ 我很想听听您的想法。
如果您喜欢这个故事，请单击👏按钮并分享以帮助其他人找到它！ 随时在下面发表评论。 (If you enjoyed this story, please click the 👏 button and share to help others find it! Feel free to leave a comment below.)
容器服务器
1703
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
