Shulou(Shulou.com)06/01 Report--

Locally or in the cloud? This debate has been going on for a long time, especially during the rise of cloud computing, when people pondered whether to keep the workload in the local data center or migrate to the cloud host.

But the technological revolution brought about by Docker has taken the debate to a new level. As more and more organizations adopt containers, they are eager to know whether the best location for hosting containers is on-premises or in the cloud.

As you might think, there is no single standard answer for everyone. In this article, we will analyze the pros and cons of cloud and on-premises container deployment, and what factors your organization should consider if it is to make the right choice.

DevOps, containers, and Cloud

First, let's quickly review the basic relationship between DevOps, containers, and the cloud. In many ways, the combination of DevOps and containers is one way to do IT in the cloud. After all, the main reason why many people migrate applications to the cloud is that containers maximize scalability and flexibility, which is a key goal of the DevOps movement. Things like virtualization and continuous delivery seem perfectly suited to the cloud (or cloud computing environment), and it is quite possible that if DevOps originated in the agile world, it would naturally develop an IT practice process suitable for cloud computing.

DevOps and on-premises deployment

However, does this mean that containerization, DevOps, and continuous delivery are not suitable for local deployment to some extent, or even have nothing to do with local deployment? Not necessarily, "on premises" has changed, and it now has many of the features of the cloud, including a high degree of virtualization and the relative independence of hardware constraints through abstraction.

In general, local systems fit the definition of a "private cloud" and they are well suited to the automated development and operation cycles of the DevOps core.

In fact, many major vendors in the DevOps/ container space (including AWS and Docker) provide strong support for local deployment, while complex and powerful container management tools, such as Rancher, are designed to work seamlessly across public / private cloud boundaries. It is no exaggeration to say that containers are no longer much different for cloud or on-premises deployments.

Reasons for local deployment

Why deploy containers locally?

Local resources

Perhaps the most immediate reason is the need for direct access to and use of hardware functions such as storage or processor-specific operations. For example, if you use a graphics chip array for matrix-intensive computing, you may be bound to local hardware.

Containers, like virtual machines, always require a degree of abstraction, but locally running containers minimize the level of abstraction between the application and the underlying metal. You can access the underlying operating system hardware directly through the container, which is difficult for virtual machines on bare metal or containers in the public cloud.

Local monitoring

Similarly, you may need containers to monitor, control, and manage local devices. This may be an important consideration in an industrial environment or research facilities. Of course, you can also use more traditional software types to perform monitoring and control functions, but the combination of containerization and continuous delivery allows you to quickly update and adjust the software according to changes in the manufacturing process or research programs.

Local security control

Security may also be one of the major considerations when it comes to deploying containers internally. Because containers access resources from the underlying operating system, they have potential security vulnerabilities. In order to ensure the security of the container, positive measures such as adding security functions to the container system must be taken.

Most container deployment systems have built-in security features. However, local deployment plays a positive role in adding additional security layers. In addition to controlling access to physical facilities, internal container deployments can also take advantage of the built-in security features of the underlying hardware to improve security.

Traditional Infrastructure and Cloud Migration

What if you can't give up your existing on-premises infrastructure? If a company has a considerable amount of money invested in hardware, or is simply unwilling or unable to migrate from a large and complex interconnected legacy application at once, then maintaining the current state for a while may be the most practical (or cautious) short-term option. By introducing containers (and DevOps practices) internally, you can lay out a relatively easy path to gradual migration to cloud computing.

Test locally, deploy in the cloud

You may also want to develop and test containerized applications locally and then deploy them in the cloud. Local development allows you to closely monitor the interaction between the software and the deployment platform and observe its operation under controlled conditions.

By comparing the behavior of an application in the cloud with its behavior in a known controlled environment, it is easier to isolate unforeseen post-deployment problems. It also allows you to deploy and test container-based software in a trusted environment without worrying about possible leaks to your competitors.

Public / private cloud hybrid

There is another point to consider when comparing cloud and on-premises container deployments: public and private cloud deployments are not completely incompatible, and even in many ways, there is no clear distinction between them.

Of course, for traditional monolithic applications, it can reside on private servers while accessing remote users through a cloud-based interface, but through containers, public / private boundaries can be more blurred and flexible in due course.

For example, you can deploy most applications through containers in the public cloud to make certain functions run on local containers. This gives you fine-grained control over issues such as security or local device access, while taking advantage of the flexibility, broad coverage, and cost benefits of public cloud deployment.

How to combine correctly

Which type of deployment is better for your company?

In general, startups and small and medium-sized businesses don't have a strong need to bind to hardware, so they can easily migrate to (or start to migrate to) the cloud. Larger companies and companies that need to manage and control local hardware resources are more likely to prefer local infrastructure. In these enterprises, the internal deployment container can serve as a bridge between the entire public cloud deployment or the mixed private / public deployment.

However, the choice between public cloud and local depends on the specific needs of your business. There are no two identical enterprises in this world, and no two software deployments are the same, but no matter what your software / IT goal is and how you plan to achieve it, there is plenty of space between on-premises deployment and public cloud deployment to make the plan flexible.

Original source: Rancher Labs

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.