Being online is inevitable, but it is not enough. In today's fast-paced world, responding quickly to market needs is essential for every company. Can our existing IT systems and operations support such rapid business change?
If Agile methodologies, containerization, Dev(Sec)Ops are old friends, then you have already encountered the problem and are addressing the issue. If you belong to this group, feel free to skip to the last paragraph. If you're just getting acquainted, the following paragraphs will reinforce your resolve to take the plunge, because there's no question today that it's worth it.

The versatile container
In very simple terms, containerisation is a virtualisation technology that builds your application code and the software needed to run it into an executable package, called a container.
The process of going from code to deployed application is called the CI/CD pipeline.
This structure and the process closely linked to it offer many advantages.
- Containerised applications can be moved easily and quickly between development, test and live environments.
- If we've built the process right, a bug fix or new feature can be up and running in minutes at the touch of a button.
- No correspondence with maintenance, the eternal problem of discrepancies between development, test and live environments is eliminated and the evergreen classic "it worked for me" that everyone hears is greatly reduced.
- By separating the functions, a potential failure does not render our entire application unusable, but only the specific function.
- Automated security tests and integrated security analysis tools guarantee the same level of security, regardless of the developer's knowledge.
- The small size of the container, which can be self-starting, self-stopping, and can be moved, means lower unit operating costs for applications and easy tracking of load changes.

Should we containerise everything?
Despite the benefits, not everything can or should be containerised. Boxed products, where the license does not allow it, or large, complex applications such as a CRM or ERP system should not be forced into a container. However, when a new business need that is not yet supported by IT arises, it is definitely worth considering this architecture.
There are several ways to do this, depending on what is available.
If you have the infrastructure (from server room to network to backup), processes (development, operations, security) and human resources (developer, DevOps engineer), you can build an on-premise environment in-house.
If the infrastructure is in place, but the company lacks processes and engineers, it is worth outsourcing the entire development and DevOps process and tasks. This way, data is kept in-house, but with experienced professionals, the business gets a solution quickly.
In development teams, the business knowledge and DevOps Dev part is strong: they should look for a platform provider where they can get the right DevOps support in addition to the infrastructure.
And if only the infrastructure is missing (as it is for startups), the cloud is the logical direction. It can be public, private, international or domestic. The choice mostly depends on familiarity, existing experience and regulatory or security needs.
The war events of the past weeks and the subsequent sanctions also raise the issue of the availability of international public clouds, i.e. when a country disconnects itself from the international internet or when an international company restricts access from that country. If anyone has such doubts, it is better to choose a Hungarian provider.
Let's talk about Kubernetes application possibilities!
By Elek Richter - Business Development Manager, NKS