Correlation Between Fast TTM and Containers

TTM and Software Architecture 

One of the critical factors for business success is Time to Market (TTM). TTM is the length of time from the moment of idea creation, which could be a new product or business, to launching the final product or service to customers. Markets move fast and delayed TTM may ruin the whole business idea. 

Therefore it is no surprise that TTM is a metric all product owners and businesses are concerned with. The delayed-release can seriously impact the potential to benefit from business opportunities. TTM directly affects revenues, and the faster a product is launched, the bigger advantage a company has over its competitors. TTM varies by sector, with the technology industry experiencing some of the fastest TTMs. There are many ways in which an organization can shorten TTM.

It is noteworthy that software architecture has a significant effect on TTM. However, businesses often use ineffective software instruments without paying attention to technical layers. This article explores how containers used in the IT industry affect TTM and why large containers might become an issue. 

On and Off-premises Software Difference

There are two important definitions to start with: on and off-premises. On and off indicate whether the software application is managed in-house or via external resources. The off-premise structure is often referred to as the cloud computing environment, where the company uses a vendor cloud for the application and requires external technical support. This type of development architecture reduces the cost and, at the same time, adds flexibility for the changes to the product. However, on-premises settings are considered to be more secure.

An off-premises development model is rapidly gaining popularity. Cloud infrastructure allows quicker TTM and flexibility to change the product further. Today, the cloud is preferred to the simple server structure (on-premises structure) due to the advantages a business gains when launching and scaling the product.

Cloud service also serves as a constructor, helping assemble a solution from ready-made blocks. Thus, a business can create a product MVP without delay, quickly test it, make changes, and release a finished commercial version.

Hence, the TTM of the product is reduced by several times. And the process of creation and launch itself becomes more predictable and reliable due to automated processes of development.

Containers' Role in Software and Cloud Architecture in Particular

Setting appropriate software infrastructure in the cloud requires research and a good level of expertise. A critical component of cloud computing is containers. The modern containerization idea originated in the chroot isolation system developed by Unix back in 1979. This mechanism further expanded into the containerization system in development and gained recognition after Docker's introduction in 2013. 

Containerization carries all application files in one box. These files are the code, dependencies, and configuration files, and they are packed in what is called a container image. A container is executed by a container runtime engine. Containers are now widely spread across the market, as well as services for their orchestration.

Containers fit perfectly well with microservices and cloud architecture, allowing for scaling, isolation, parity, and efficiency.

A few points to consider when implementing containers:

• Containers are getting loaded to your hardware and must be unpacked before the launch. This process is called provisioning. 

• Containers take/need disk space and operating memory.

Choosing a large container will result in a slow provisioning process, meaning that large containers delay app download time and scalability and even heighten security. 

Large size is also reflected in more extensive data volumes you have to store, meaning that the costs are increased due to information traffic. 

However, the large size is not driven by necessity. Containers sometimes include unused or unnecessary files. A container contains several layers inside. Some of these layers are unused files that exist in the package without practical need. Examples of such files are duplicated data, some unutilized distribution files, and developers' files not required for the application to run. 

In the beginning, all the containers were large. As business practice demonstrated the drawbacks of bulky containers, software companies started looking into how to refine them.

For JDK containers, the large size means that some image parts are not optimized. These parts are JVM code, extra unnecessary information for creating custom runtimes, etc. These parts of a large JDK container make it clumsy, so to say. 

The solution to mitigate the negative side effects of large containers is hidden in reducing the container size. The smallest known available containers on the market today are those based on Alpine Linux. Although it is technically possible to reduce the size even further, it rarely makes any practical sense. Alpine Linux is a tiny Linux distribution and still lacks some features of a full-fledged OS allowing for comfortable compatibility with OpenJDK, for example. 

To recap, I would like to emphasize an evident connection between TTM and containerization. The operating results confirm that cloud-based technology significantly improves TTM and other important application metrics, including scalability, speed of the download, and more. Containers are great for the cloud environment as their implementation strengthens the advances of correctly set cloud mechanisms. 

However, large containers might have a negative effect on TTM and other business requirements. Choosing a suitable container is the key here. 

Software development is moving towards the smaller sizes in containerization, taking out those extra files not utilized by large containers and optimizing the files left inside. No perfect microcontainer exists on the market yet, as even the popular Alpine Linux requires some bridges for the OpenJDK application, and Alpine-based microcontainers are still not the smallest possible examples. Technically, we aim to minimize the containers and make them more comfortable for any programming language, especially for Java, as one of the top enterprise languages.