快速TTM和容器之间的相关性

本文探讨了IT行业使用的容器如何影响TTM，以及为什么大型容器可能成为一个问题。

TTM和软件架构

商业成功的关键因素之一是上市时间（TTM）。TTM是指从产生想法（可能是新产品或业务）到向客户推出最终产品或服务的时间长度。市场发展很快，延迟的TTM可能会毁掉整个商业理念。

因此，TTM是所有产品所有者和企业都关注的一个指标，这并不奇怪。延迟发布会严重影响从商业机会中获益的潜力。TTM直接影响收入，产品推出的速度越快，公司对竞争对手的优势就越大。TTM因部门而异，技术行业经历了一些最快的TTM。一个组织可以通过很多方式来缩短TTM。

值得注意的是，软件架构对TTM有很大影响。然而，企业经常使用无效的软件工具而不注意技术层。本文探讨了IT行业使用的容器如何影响TTM，以及为什么大型容器可能成为一个问题。

企业内和企业外软件的区别

首先有两个重要的定义：on和off-premises。上和下表示软件应用程序是在内部管理还是通过外部资源管理。非内部结构通常被称为云计算环境，公司使用供应商的云进行应用，需要外部技术支持。这种类型的开发架构降低了成本，同时也为产品的变化增加了灵活性。然而，企业内部设置被认为是更安全的。

非内部设置的开发模式正在迅速得到普及。云基础设施允许更快的TTM和进一步改变产品的灵活性。今天，由于企业在启动和扩展产品时获得的优势，云计算比简单的服务器结构（企业内部结构）更受欢迎。

云服务还可以作为一个构造者，帮助从现成的模块中组装出一个解决方案。因此，企业可以毫不拖延地创建一个产品的MVP，快速测试，进行修改，并发布一个完整的商业版本。

因此，产品的TTM缩短了数倍。而且，由于开发过程的自动化，创建和发布过程本身变得更加可预测和可靠。

容器在软件和云架构中的作用，特别是

在云中设置适当的软件基础设施需要研究和良好的专业知识水平。云计算的一个重要组成部分是容器。现代的容器化思想起源于Unix公司早在1979年开发的chroot隔离系统。这种机制在发展中进一步扩展为容器化系统，并在2013年Docker推出后获得认可。

容器化将所有的应用文件装在一个盒子里。这些文件是代码、依赖关系和配置文件，它们被打包在所谓的容器镜像中。一个容器由一个容器运行时引擎执行。容器现在已经在市场上广泛传播，还有用于其协调的服务。

容器与 微服务和云架构完美契合，允许扩展、隔离、平价和高效。

实施容器时需要考虑的几个要点:

• 容器被加载到你的硬件上，在启动前必须被解压。这个过程被称为配置。

• 容器占用/需要磁盘空间和操作内存。

选择一个大的容器将导致缓慢的配置过程，这意味着大的容器会延迟应用程序的下载时间和可扩展性，甚至会提高安全性。

大尺寸还体现在你必须存储更多的数据量，这意味着由于信息流量而导致成本增加。

然而，大尺寸并不是由必要性驱动的。容器有时包括未使用或不必要的文件。一个容器内部包含几个层。这些层中的一些是未使用的文件，它们存在于包中，没有实际需要。这类文件的例子是重复的数据，一些未被利用的分布文件，以及应用程序运行不需要的开发者文件。

开始时，所有的容器都很大。随着商业实践证明了笨重的容器的弊端，软件公司开始研究如何完善它们。

对于JDK容器，大尺寸意味着一些图像部分没有被优化。这些部分是JVM代码、用于创建自定义运行时的额外不必要的信息等。可以说，大型JDK容器的这些部分使其变得笨拙。

减轻大型容器的负面效应的解决方案隐藏在减少容器的大小中。目前市场上已知最小的可用容器是基于Alpine Linux的容器。尽管在技术上有可能进一步减小尺寸，但这很少有实际意义。Alpine Linux是一个很小的Linux发行版，仍然缺乏一个成熟的操作系统的一些功能，例如，允许与OpenJDK舒适兼容。

总结一下，我想强调一下TTM和容器化之间的一个明显的联系。操作结果证实，基于云的技术大大改善了TTM和其他重要的应用指标，包括可扩展性、下载速度等等。容器对云环境来说是很好的，因为它们的实施加强了正确设置的云机制的先进性。

然而，大型容器可能会对TTM和其他业务要求产生负面影响。选择一个合适的容器是这里的关键。

软件开发正朝着容器化的小尺寸发展，取出那些大型容器没有利用的额外文件，优化留在里面的文件。目前市场上还没有完美的微容器存在，因为即使是流行的Alpine Linux也需要为OpenJDK应用程序提供一些桥接，而基于Alpine的微容器仍然不是最小的例子。在技术上，我们的目标是将容器最小化，使其对任何编程语言都更加舒适，尤其是对作为顶级企业语言之一的Java。