Implementing Containerization in Enterprise: What Determines the Success of a Project

Containerization allows you to work with applications in isolated areas, so-called containers. It increases the flexibility and speed of development and management of IT infrastructure. Today, not all companies plan to implement this technology, but many unexpectedly begin to receive systems in Docker containers from vendors and contractors. First one, then another – eventually there are so many of them that without special software for managing containers, the team faces difficulties.

Maxim Morar (leader of Nova Container Platform, Orion soft) explains how to approach the implementation of containerization in this case, evaluate the resources and timeframes of the project, and what results it can produce.

Not everyone chooses containerization intentionally

There is still a large share of players on the market that do not have an active demand for the implementation of containerization technology. For example, a company's own development may be focused on 1C, and other systems are either boxed solutions or custom development from contractors.

But more and more contractors deliver their solutions in the format of Docker containers. At the same time, the implementation of applications often concerns key systems: mail services, MES, supplier relationship management systems, SCM and others. Companies do not always have time to prepare for this: for example, in the experience of Orion soft there was a case when it was necessary to organize management for more than 500 containers, and the customer did not have experience working with them, their own team of developers and DevOps specialists.

When the number of containers reaches hundreds, the team faces serious challenges: manual management, availability support, monitoring and attempts at basic automation, information security issues. In this case, there is a need for an orchestrator – a system for automated management of container infrastructure. In this case, the choice of Kubernetes as an industry standard suggests itself. This technology allows you to automate routine and free up the team for important tasks, especially if the number of containers continues to grow, which means that the complexity of managing them only increases over time.

Read more materials on this topic in Compass CIO

Build or buy?

In a situation where it is necessary to implement container orchestration software, the company faces a standard question: build it yourself or buy ready-made?

The first way is to take Open Source Kubernetes, enrich it with many additional modules, independently configure the infrastructure, automation and management, and then maintain the life cycle of all components on your own. The second is to implement a ready-made platform.

According to one of Orion soft's clients, a large industrial company, to create a production platform for an infrastructure of this scale, you need a team of at least 10-15 specialists: DevOps/SRE engineers, testers, backend and frontend developers. Forming a team from scratch takes 18 months. After that, another 2 years for design, architecture and development of the MVP version of the platform. The result is 3.5 years from the start to the finished solution, and this does not include further refinement and scaling.

The estimated cost of the project, taking into account such deadlines, reaches at least 1 900 000 USD. At the same time, the Orion soft team has encountered such cases in the market, when companies spent more than 6 million USD on developing their own orchestration platform and still did not have time to finalize all the necessary functionality on time.

A logical question may arise: “Why is it so expensive and time-consuming to install Kubernetes on a regular basis?” But a production-ready solution for a large company is not just “putting in a cube”. To create a platform of this level, you need:

• Multitenancy – separation of access and resources between teams from six data centers;

• Convenient interface for managing applications, loads and fault tolerance;

• Single authentication and authorization system – two-factor authentication and, depending on the scale of the organization, SSO (single sign-on technology);

• Comprehensive information security system – data protection, monitoring and integration with SIEM;

• Infrastructure management system – orchestration of resources and ensuring fault tolerance.

The creation and development of a proprietary Kubernetes platform of this level and scale is most often justified only for those companies that make money on IT products. At the same time, the average payback period for a “box” is about 2 years. Vendor support sometimes becomes an argument in its favor: when you place critical systems in production, and there is no deep expertise inside, it is important to be able to quickly get help and ask questions.

Why does creating your own platform require such resources? Just look at the project's technology stack.

Let's start with the foundation – the infrastructure level. Many Enterprise companies have two operating systems running in parallel. One of Orion soft's customers simultaneously supported Red Hat Enterprise Linux and RED OS, as well as two virtualization systems: foreign VMware vSphere and Russian zVirt. The Kubernetes platform must in all cases integrate with both systems: automatically deploy, work with storage, and scale.

Other components of the technology stack will also require implementation, configuration, and ongoing support. If we are talking about an Enterprise company, this list often includes a network and storage management system, a secrets and PKI management system, a monitoring, logging, and alerting system, GitOps deployment automation, backup, persistent storage, and others.

The larger the technology stack, the wider the project timeframe and budget.

Tech stack of one of the Orion soft projects, repeating the stack of the Kubernetes platform

The success of technology depends on people

Implementing containerization in a large company is not only about technology, but also about the ability to transform traditional practices. One of the projects implementing our container orchestration platform was planned to be completed in six months, but in the end it took nine. Why? The impact of the new technology on internal business processes played a role.

A company doesn't just implement a platform; it often changes its approach to work – methodology, interaction patterns, established practices. The changes affect many teams: from administrators and information security specialists to networkers and virtualization engineers. Each such group is a link in the decision-making chain.

Therefore, an important component of successful implementation is the role of internal change leaders. Without them, even the most advanced technology risks remaining unclaimed. The external vendor does not participate in all of the customer's internal discussions, which is why employees who will take on the role of change agents are so important.

They may have different motivations. A chief architect with 15 years of experience sees how to improve current processes and increase their efficiency. A manager of implementation engineers may use an implementation project as an opportunity to develop the team and speed up internal processes. A leading engineer wants to get away from routine tasks and implement modern technologies. Such people will promote a new approach from within: show the benefits at meetings, help colleagues see prospects, drive changes at all levels.

Applications are not always ready

Another problem that companies often face when implementing containerization is the need to modify applications. Custom software providers confidently declare that their solutions are ready to work in a Kubernetes environment. Unfortunately, the reality is often different. Many developers pack applications into containers without thinking about how the customer will work with them in a production environment: how dynamic scaling, transparent rollout of changes, work with storage, geo-distribution across several data centers, and so on will be ensured.

Therefore, before implementation, it is important to check the actual readiness of applications to work in Kubernetes, regardless of whether the company has its own development team or the customer cooperates with the vendor. Some of the tasks for finalizing applications may fall on the platform vendor, some on the customer, but the bulk, naturally, falls on the application developers themselves. This finalization can add 2-3 months to the project deadlines.

What “pains” does the implementation of a containerization platform solve?

The key "pain" of most customers at the start is the need to automate routine administration tasks. As a result of implementation, the team frees up to 80% of time for more important tasks.

The implementation of the platform also solves the problem of centralized security management for all Kubernetes clusters. If previously security could be limited to a basic antivirus on virtual machines, then with the platform it can be provided "out of the box". Today, only the Nova Container Platform solution has a built-in module of security tools on the market; other vendor platforms integrate with external information security tools. Using the built-in security module, a company can quickly create a single technological standard that will cover isolation policies, runtime vulnerability checks, launch rules in namespaces, and privilege control.

Using a containerization platform, you can also automate work with secrets. The IT infrastructure can combine various secrets: logins and passwords, certificates, tokens, encryption keys, SSH keys, API keys, secrets for Kubernetes microservices. Platform integration allows you to centralize work with them, make it secure, and set up a PKI infrastructure. Today, there is a choice on the market. You can implement a separate orchestrator and secret storage from one vendor, or you can use a more convenient option for companies that are just approaching containerization – purchase a platform with a built-in secret storage.

A useful practice when switching to containers is inventorying systems. It also has a positive effect: Kubernetes allows you to pack services more tightly and free up to 50% of the hardware, and request additional resources dynamically, which eliminates the need to keep a large stock of them constantly. This is usually not a goal, but a bonus for the project's economy, but it is worth considering – significantly fewer servers may be required.

Another bonus that can be discovered after the fact is saving up to 50% of infrastructure resources. The fact is that with the Kubernetes platform, the team switches to a dynamic resource provisioning model. It works like this: at the start, system administrators are given a small volume required for the task "here and now", and then, if necessary, they can request an extension of the resource quota and quickly get additional volume. At the same time, the platform administrator sees the full picture of consumption for each team and can also dynamically add or cut resources. This optimization leads to savings.

The implementation also affects the competencies of the technical and management teams. After training from the vendor, the company can develop its own expertise in containerization. As a result of the projects, many customers open DevOps/SRE departments and grow their own specialists who will be able to make the processes even more efficient in the future.

Such projects confirm that the success of Kubernetes implementation in a large company depends not only and not so much on technologies. People, processes, and readiness for change are important. And of course, you need to be patient – such transformations do not happen overnight. But the results are worth it.