容器服务器
What’s the job of a developer? Writing software, of course. But that wasn’t always the case.
开发人员的工作是什么？ 当然，编写软件。 但这并非总是如此。
Back in the days, each application had its own server. And as each server has a finite amount of resources, developers constantly had to think about not overloading the server’s capacities. If an application was needed to run from a different server, the whole thing had to be set up again.
过去，每个应用程序都有自己的服务器。 而且，由于每台服务器都有有限的资源，因此开发人员必须不断考虑不要使服务器的容量过载。 如果需要从其他服务器运行应用程序，则必须重新设置整个过程。
Enterprises soon realized that this was rather inefficient: on the one hand, developers weren’t happy because they had to worry about other things than their code. On the other hand, plenty of compute resources were going unused whenever an application didn’t take up 100 percent of the server’s capacity.
企业很快意识到这效率很低：一方面，开发人员不满意，因为他们不得不担心代码以外的其他事情。 另一方面，只要应用程序不占用服务器容量的100％，大量的计算资源就会被闲置。
Fast-forward to today: when was the last time you worried about some server architecture? Probably a while back.
快进到今天：您上一次担心某些服务器体系结构是什么时候？ 大概一会儿。
That doesn’t mean that we gotten rid of all considerations regarding memory, RAM, storage, and so on. Even though developers are getting liberated of such issues more and more, the process is far from over.
这并不意味着我们摆脱了有关内存，RAM，存储等的所有注意事项。 即使开发人员越来越多地从此类问题中解放出来，但这个过程还远远没有结束。
As of now, we’re not at the end of the road of virtualization and never worrying about servers again. And it’s not clear yet which technology will be the winner of it all. Will it be virtual machines? Containers? Or serverless computing? It’s an ongoing debate, and one that is worth studying in detail.
到目前为止，我们还没有走在虚拟化道路的尽头，也再也不必担心服务器。 目前尚不清楚哪种技术将成为所有技术的赢家。 会是虚拟机吗？ 容器？ 还是无服务器计算？ 这是一个持续不断的辩论，值得详细研究。
虚拟机的出现 (The advent of virtual machines)
Enter the 1960s, when virtual machines (VMs) were first invented. Instead of using bare-metal servers for one single application at a time, people started thinking about spinning up multiple operating systems (OS) on one server. This would allow multiple applications to run separately, each on its own OS.
进入1960年代， 第一次发明虚拟机(VM)。 人们不再考虑一次将裸机服务器用于一个应用程序，而是开始考虑在一个服务器上扩展多个操作系统(OS)。 这将允许多个应用程序分别运行在各自的操作系统上。
At IBM and other companies, they achieved just that: they emulate the physical server, i.e., they make virtual representations of it. A so-called hypervisor is in charge of allocating compute resources to the VMs and making sure that the VMs don’t interfere with one another.
在IBM和其他公司，他们只是实现了这一点 ：他们模拟物理服务器，即，对其进行虚拟表示。 所谓的虚拟机管理程序负责将计算资源分配给VM，并确保VM不会相互干扰。
Not only are compute resources of one server used more efficiently this way. You can also run an application on many different servers without having to reconfigure it each time. And if a server doesn’t have a VM with the right OS, you can just clone another VM.
这样，不仅一台服务器的计算资源得到了更有效的利用。 您也可以在许多不同的服务器上运行应用程序，而不必每次都重新配置它。 如果服务器没有具有正确操作系统的VM，则可以克隆另一个VM。
In addition to all that, VMs can make servers more secure because you can scan them for malicious software. If you find some, you can just restore the VM in an earlier version, which essentially erases the malware.
除此之外，VM可以使服务器更安全，因为您可以扫描它们以查找恶意软件。 如果找到某些虚拟机，则可以将其还原为早期版本，从而从本质上清除恶意软件。
With these advantages in mind, it’s no wonder that VMs dominate the space, and bare-metal applications are pretty rare. Linux and Ubuntu are often-seen guests in many VMs. Java and Python run on stripped-down versions of VMs, which enables developers to execute their code on any machine.
考虑到这些优势，难怪VM占据了整个空间，而裸机应用程序却很少。 Linux和Ubuntu在许多VM中经常出现。 Java和Python在简化的VM版本上运行，这使开发人员可以在任何计算机上执行其代码。
战地1：虚拟机与容器 (Battlefield 1: VMs versus containers)
A virtual machine emulates the hardware it runs on. In contrast, a container just emulates an OS, usually Linux. That’s why it doesn’t contain a virtual copy of the hardware it’s running on.
虚拟机模拟其运行的硬件。 相反， 容器只是模拟一个操作系统，通常是Linux。 这就是为什么它不包含所运行硬件的虚拟副本的原因。
Like VMs, containers can’t go without an OS, an application and its libraries and dependencies. But letting go of the hardware emulation results in the fact that containers are even more lightweight, fast, and portable. That’s why containers only take seconds to start, while VMs usually need a few minutes.
像VM一样，容器离不开OS，应用程序及其库和依赖项。 但是放开硬件仿真会导致这样一个事实，即容器更加轻巧，快速且可移植。 这就是为什么容器仅需要几秒钟即可启动，而VM通常需要几分钟的时间。
On the other hand, containers aren’t always as secure as VMs. If malevolent software gets onto a containerized system and makes it through to the OS, it can potentially hijack the whole machine.
另一方面，容器并不总是像VM一样安全 。 如果恶意软件进入容器化系统并进入操作系统，它可能会劫持整个计算机。
In contrast, VMs keep different operating systems separate from one another. So even if malware gets through to the OS of a VM, all other VMs on the machine remain untouched from the attack. This adds an extra level of security that can be crucial when dealing with confidential data, for example.
相反，VM将不同的操作系统彼此分开。 因此，即使恶意软件进入了虚拟机的操作系统，该计算机上的所有其他虚拟机也不会受到攻击。 例如，这增加了额外的安全级别，这在处理机密数据时可能至关重要。
Another advantage of VMs over containers is that you can use different operating systems. This is more work, of course, because you might need to implement bug fixes on each OS separately. But if you have an application that ought to run on anything else than Linux, containers aren’t the way to go.
与容器相比，VM的另一个优点是您可以使用不同的操作系统。 当然，这是更多的工作，因为您可能需要分别在每个OS上实现错误修复。 但是，如果您的应用程序可以在Linux以外的任何其他设备上运行，那么容器就不是路要走。
On the other hand, containers are great for anything with a microservice architecture, i.e., where a single application is composed of many smaller services that are only loosely coupled and can be executed independently. Each individual service can be put in its own container. Then, the only thing that developers need to watch out for is that the containers communicate properly among each other.
另一方面，容器非常适合具有微服务架构的任何应用程序，即单个应用程序由许多较小的服务组成，这些服务仅是松散耦合的，并且可以独立执行。 每个单独的服务都可以放在自己的容器中。 然后，开发人员唯一需要注意的是容器之间的正确通信。
战地风云2：Docker与Kubernetes (Battlefield 2: Docker versus Kubernetes)
There’s one technology that’s synonymous with container engines: Docker. But there’s another technology that’s often mentioned in the same sentence: Kubernetes. So what’s going on — are Docker and Kubernetes friends or foes?
有一种与容器引擎同义的技术： Docker 。 但是同一句话中经常提到另一种技术： Kubernetes 。 那么，发生了什么— Docker和Kubernetes是朋友还是敌人？
As Microsoft puts it, comparing Docker and Kubernetes is a bit like comparing apples to apple pie. Docker is a file format for containers and open-source technology to run applications from anywhere. Kubernetes coordinates and schedules many containers, and ensures that they communicate properly with each other.
正如微软所说，比较Docker和Kubernetes有点像比较苹果和苹果派。 Docker是一种用于容器和开源技术的文件格式，可以在任何地方运行应用程序。 Kubernetes协调和调度许多容器，并确保它们彼此之间正确通信。
Docker has its own container orchestration service, Docker Swarm. Here, however, the winner is clear: Kubernetes is way more extensive than Docker Swarm. Kubernetes can run across an entire cluster of machines, whereas Docker Swarm runs on a single node only.
Docker拥有自己的容器编排服务Docker Swarm。 然而，在这里，赢家是显而易见的：Kubernetes比Docker Swarm的应用范围更广。 Kubernetes可以在整个机器集群上运行，而Docker Swarm仅在单个节点上运行。
So unless you’re deploying containers on a single node, or otherwise have no need for the sophistication that Kubernetes brings, there’s no need to give Docker Swarm a second thought. If you think container orchestration, think Kubernetes.
因此，除非您在单个节点上部署容器，否则不需要Kubernetes带来的复杂性，就无需再考虑Docker Swarm了。 如果您考虑容器编排，请考虑使用Kubernetes。
On top of managing containers, Kubernetes allows you to orchestrate a cluster of VMs — yes, VMs — and schedule containers to run on seletcted VMs, based on the available compute resources and the requirements of each container.
除了管理容器外，Kubernetes还允许您根据可用的计算资源和每个容器的需求来编排VM集群(是的，VM)，并安排容器在选择的VM上运行。
You heard that right: VMs, Docker, and Kubernetes in one workflow. So far, this sounds less like a battle and more like a symphony. But wait, because there’s one more to come.
您没听错：一个工作流程中的VM，Docker和Kubernetes。 到目前为止，这听起来不像是一场战斗，而更像是一部交响曲。 但是，请稍等，因为还有更多。
战地3：容器与无服务器 (Battlefield 3: containers versus serverless)
If VMs took physical hardware off a developer’s plate, and containers stripped away any worries about operating systems (I’m talking containers like Docker plus optionally Kubernetes), serverless takes this journey another leap forward.
如果虚拟机从开发人员手中夺走了物理硬件，并且容器消除了对操作系统的任何担忧(我说的是诸如Docker以及可选的Kubernetes之类的容器)，那么无服务器将使这一旅程又向前飞跃。
You can see this visualized in the figure below: With serverless, developers don’t even have to worry about when and how their application gets executed, which containers they ought to put it in, or how many compute resources it will consume. They still need to write the applications, of course, but after they’ve uploaded it to their AWS Lambda, Aurora, or CloudFront service, they can call it a day.
您可以在下图中直观地看到这一点：使用无服务器，开发人员甚至不必担心应用程序的执行时间和方式，应将其放入哪个容器或将消耗多少计算资源。 当然，他们仍然需要编写应用程序，但是在将其上传到其AWS Lambda，Aurora或CloudFront服务之后，他们可以每天进行调用。
Their code will then lie dormant until it gets executed. You only pay for the machine-time that you really used, which makes the whole thing pretty economic. In contrast, you need to pay a monthly fee for Docker, and a per-cluster-per-hour fee for Kubernetes, regardless of how much you use it.
然后，他们的代码将处于Hibernate状态，直到被执行。 您只需要为您真正使用的机器时间付费，就可以使整个过程变得非常经济。 相比之下，无论使用多少，您都需要为Docker每月支付费用，为Kubernetes每小时按群集支付费用。
That doesn’t mean, however, that serverless is king. It’s a fairly new technology, and at the moments there still are limits wherever you go.
但这并不意味着无服务器才是王道。 这是一项相当新的技术，目前无论您走到哪里，都仍然有局限性。
For example, at the moment it’s quite difficult to pull off A/B testing on serverless, or make other sophisticated deployment options work. Also, serverless needs some time to get code initialized. So if you need your application to be very fast, you should use containers instead.
例如，目前很难在无服务器上进行A / B测试 ，或者使其他复杂的部署选项正常工作。 另外，无服务器需要一些时间来初始化代码。 因此，如果您需要应用程序非常快，则应改用容器。
In addition, serverless comes with restrictions regarding compute resources. So if you have a task that takes rather a lot of RAM or runs for a long time, you’d be better off using containers.
此外，无服务器还带有有关计算资源的限制。 因此，如果您的任务需要占用大量RAM或长时间运行，那么最好使用容器。
未来是什么样子的 (What the future holds)
All these limitations to serverless aren’t innate, so we can expect serverless to win more ground over containers in the years to come. It’s also gaining traction because it’s more beginner-friendly than container orchestrations, scales very easily and is very flexible and cost-effective regarding workloads.
无服务器的所有这些限制并不是天生的，因此我们可以预期，无服务器在未来几年会在容器上赢得更多的市场。 它也吸引了人们的注意，因为它比容器编排更适合初学者，可轻松扩展，并且在工作负载方面非常灵活且具有成本效益。
It’s therefore no wonder that the serverless architecture market is projected to triple in the next few years, grossing more than $21 billion by 2025. But that doesn’t mean that VMs and containers will die out.
因此，也难怪，在无服务器架构市场预计到三倍，在未来的几年中，2025年票房收入超过十亿$ 21但并不意味着虚拟机和容器将消亡。
It’s quite unlikely that we’ll only see serverless technologies in a decade or so. Just look at VMs, which have been around for half a century and are still very much in use. Instead, we’re quite likely going to see more symbioses of containers with serverless, just like containers and VMs work pretty well together. Services like AWS Fargate let you combine containers with serverless pretty seamlessly already.
我们几乎不可能在十年左右的时间里看到无服务器技术。 仅看一下已经存在了半个世纪并且仍在使用中的VM。 相反，我们很可能会看到更多带有无服务器的容器共生体，就像容器和VM可以很好地协同工作一样。 诸如AWS Fargate之类的服务使您已经可以无缝地将容器与无服务器相结合。
All these solutions — VMs, containers, and serverless — are good solutions and come with their specific strengths and weaknesses. Even though they’re sometimes competing on overlapping spaces, the good news is that you can mix-and-match them to suit your needs.
所有这些解决方案(VM，容器和无服务器)都是很好的解决方案，并具有各自的优点和缺点。 即使它们有时在重叠的空间上竞争，但好消息是您可以根据需要混合和匹配它们。
Big tech’s journey with virtualization is far from over. Except for increasing developer efficiency, we don’t even know what the destination will look like. But all the signs speak for an interesting, fascinating, and quite lucrative path looking forward.
大型技术在虚拟化方面的旅程还没有结束。 除了提高开发人员效率外，我们什至不知道目的地会是什么样。 但是所有的迹象都代表着一条有趣，引人入胜，利润丰厚的道路。
For all we know, serverless might not be the last step. Who knows, really, what technologies we’ll be playing with in the future?
就我们所知，无服务器可能不是最后一步。 谁真的知道，我们将来会使用什么技术？
容器服务器
2924
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
