Containers are Awesome!
Rick Petersen
Application Modernization and Developer Satisfaction Coach and Mentor | Helping organizations empower and retain talented developers to fuel AI and Cloud app modernizations
They are awesome... and the reality is, you probably do not need them.
Many companies today are purchasing the perceived flexibility of portability at the cost of timelines and, ultimately, successful implementation.
There are absolutely cases where containerization and even orchestration are called for, but it is the exception rather than the rule. Sometimes you inherit (or have overseen the creation of) a webserver filled with small applications that help drive your business. Even if some of the apps are external facing, they still have hundreds of users, not millions. Unless you need the ability to support highly scalable workloads, the value of containerization is often over-stated.
Containers solve three problems in my opinion:
Independent scalability
If you need the ability to scale certain parts of the system to extreme values while not changing your cost structure for the rest of the system, containers do have value. This is not scale for 100's or 1000's of users, but if you have traffic that varies to the tune of millions of requests up or down, definitely look at containers.
Encapsulation of dependencies (can help with 'works on my machine')
If a containerized application runs on a developer's machine and is then deployed to a remote system with a matching host OS, you can expect the containerized application to work similarly with a (not so) small exception. External dependencies - anything that the application relies upon outside the container, it will need to have line of site to those same things in its new environment. This could include external services, configuration/environment variables, etc. At least you will not run into GAC hell with containers.
领英推荐
Portability (somewhat)
This benefit is oversold; technically you can port the container to any other container host with same OS, but most of the time you surround your application with so many other non-containerized resources that it is simply not that portable. Did you containerize your storage? Logging and monitoring services? Firewall? Database? Maybe some solutions do go this far, but most of the time, simple mass-portability is an unfulfilled promise.
If not containers, then what?
PaaS (Platform as a Service) options generally provide the lowest barrier to entry into the cloud (aside from just moving a VM) combined with the least Cost to Operate. Take your code, target a PaaS host, deploy, click a button to turn on monitoring and Bob's Your Uncle (I honestly do not understand why people say that... they do say that, right?).
There are even great tools that will evaluate your application to point out the challenges and path to migrate it, even performing the migration for you if you so decide: https://aka.ms/AAm84y2
Obviously some details are glossed over in this picture, but this is a very common scenario I help customers with all the time. It is not that hard. It doesn't need to be scary. I am here to help (either me, if you happen to be one of my customers, or I can find a counterpart or partner that would be glad to assist).
Senior Manager - Enterprise Data and Data Ops
1 年Interesting read. Agree on PaaS being a cost saver if motivation is to save costs - cheaper than a self-service IaaS kubernetes rollout ( when not needed.) And there are PaaS solutions supporting containerization! IMO, containers/packaging mechanism itself isn’t the problem. Things go wild when granularity becomes a design obsession ( micro-services done wrong) and scalability obsession ( kubernetes complexity when scaling up/down has low ROI.) As Einstein once said “Make everything as simple as possible, but not simpler.”