back to article Containers make life easier for the software vendors you buy from, and that's why they'll win

Welcome to the latest Register Debate in which writers discuss technology topics, and you – the reader – choose the winning argument. The format is simple: we propose a motion, the arguments for the motion will run this Monday and Wednesday, and the arguments against on Tuesday and Thursday. During the week you can cast your …

  1. amanfromMars 1 Silver badge

    Test Drivering Real Gold Standards ...... for COSMIC Apps

    Once you can only buy the apps you need as containers, it’s game over ....Simon Sharwood, APAC editor

    Quite so, Simon. Are we there yet,.... where IT's All at ‽ .

    Obviously we think so here.

  2. Anonymous Coward
    Anonymous Coward

    Very interesting point

    That's all.

  3. elsergiovolador Silver badge

    Take a step back

    If think we are at a point where we need to take a step back and rethink whether software companies are getting too much power.

    Mandating where or how you have to run the software you bought is wrong. It's like saying the phone you bought can be used only in your kitchen and you can only call five numbers.

    Another aspect is the right to repair. I think the days of closed source software are coming to an end as consumers should have a right to take the software they bought and get it fixed if there are any bugs that manufacturer won't fix.

    1. Anonymous Coward
      Anonymous Coward

      Re: Take a step back

      I'd argue it's more like whether it comes on CD ROM vs download vs rent it in the cloud

      1. elsergiovolador Silver badge

        Re: Take a step back

        The rent seeking is another thing government should tackle. Manufacturer should always have an option to buy or rental should always end in an ownership after max 24 months or 24 instalments.

        1. Cinderellaphant

          Re: Take a step back

          Not if software feudalists have their way

    2. AMBxx Silver badge

      Re: Take a step back

      >> It's like saying the phone you bought can be used only in your kitchen and you can only call five numbers.

      Don't give Apple any ideas! Next, you can only call other Apple users.

  4. Anonymous Coward
    Anonymous Coward

    Market Forces

    There are lots of positions to adopt when explaining the future of historical success or failure of a product. But the strongest of all determinants - in my view - are the will of sellers, and their supply chain, and the accommodation of buyers, buoyed by sales and marketing. It is a complex mix to counter.

  5. Anonymous Coward
    Anonymous Coward

    Just wait ...

    ... this debate will be made obsolete as soon as someone can get around to inventing (re-inventing?) a hybrid "Virtual Container" technology.

    But there'll still remain many important decisions. For example, what colour should it be? :-)

  6. ciaran

    Answer in the text

    "But VMs are already a well-understood, mature, technology for almost everything other than delivering easily iterated applications." Therefore containers aren't mature, QED.

    Honestly I haven't studied containers at all, but I'd understood that the container interface isn't perfectly stable between versions and not identical across different implementations.

    Isn't a container pretty much like a servlet? Why don't vendors just sell their products as a WAR file? Probably because there are always outside dependencies?

    VM's are reliable, for me that's the winning feature.

    Ciaran

  7. Daedalus Silver badge

    Hmmph

    less time on multiple versions of their products, and more time innovating on your behalf

    Reality: less time supporting multiple versions, more time for marketeers to churn out ideas for new shiny add-ons that compromise basic functions.

  8. Snake Silver badge

    I must be missing something

    "[Analysts and VMWare] suggest it won’t be long before ISVs politely but firmly insist your next upgrade will also be a re-platforming project — from however you run an app today into containers."

    I question whether or not this will happen once accounting gets a hold of the ROV on that idea. Being told to re-platform on your next software upgrade, who will pay for this? On a full-scale system I am quite sure that can run into the hundreds of thousands to maybe even millions, once re-licensing, testing, administration, retraining and overall man-hours are taken into account - all to satisfy what, exactly?

    Containerization, in the very long term, sounds appealing. But companies act in quarters, not long-term any more, and it will probably be hard for an ISV to propose said company drop those kind of funds for, for the moment at least, a benefit that mostly tilts towards the ISV's direction.

    I foresee a lot of pushback on that early "re-platform" idea.

    Figure hybrid containerization on VM systems, for quite a while to come I would believe. Next major upgrade cycle, designing for containerization will come to the forefront of the discussion.

    1. Anonymous Coward
      Anonymous Coward

      Re: I must be missing something

      Indeed the author seems to concur

      > "They suggest it won’t be long before ISVs politely but firmly insist your next upgrade will also be a re-platforming project — from however you run an app today into containers."

  9. Lorribot Silver badge

    "But VMs are already a well-understood, mature, technology for almost everything other than delivering easily iterated applications."

    99% of the IT I support is not "iterated applications" but stand alone single instances with no scale up or out requirements. I am not sure where this idea of fast development of applications comes from, maybe those that live in web serving world but many of the people that live in manufacturing/distribution/engineering/creative environment are not looking for that sort thing.The closest we probablly come to a iterative application is the office install on users laptops.

    Can you run my bespoke automated warehouse system (the other AWS) in a container in AWS (need 3 ms latency or the warehouse dies)?

    1. daflibble

      Amazon probably know a lot about doing just that. It might be an interesting read one day.

      1. Claptrap314 Silver badge

        Building something for your own use is ENTIRELY different than building it for sale.

        Otherwise, Google would utterly dominate cloud computing.

  10. Henry Wertz 1 Gold badge

    I guess either way

    Wow, it's dead even (when I voted), over 1000 votes and it's 50/50!

    I voted "agreed", but...

    Virtual machines? Linux kernel on a VM is aware it's on a VM, it's tickless (so it's not generating interrupts and so slowing down the shared system when it's not doing anything) and the "virtual server" distros are pretty light. Running stuff on VMs is not too bad. But you have then a kernel running, virtualized disk access, then running through another kernel; multiple caches (both the VM and physical box will have a disk cache for example); you then have a in-VM scheduler and physical system scheduler... there's overhead there. But, the VM has it's own OS, there's no worrying over kernel differences or distro differences, or your app is for Linux but someone wants to run it on Windows. Security-wise, both the VM and the container are supposed to isolate everything, but the VM restricts the attack surface rather severely in terms of what can be done to the physical machine.

    BUT.. containers have nearly 0 overhead, you are not having to pre-allocate RAM or disk space, there's nice controls for the disk, RAM, and CPU usage (VMs let you change # of CPUs and at least on VirtualBox reduce % speed of the cores VirtualBox exposes, but the containers have nice CPU usage control too.) Modern containerization solutions in linux, the containerized app has it's own /proc and /sys, it's own process list, and some kind of user id mapping stuff so you can "be root" inside a container, but have no special privileges outside it. it can have it's own view of CPUs and available RAM or have access to the whole thing, etc., and that can generally be changed on the fly. Conversely to the VM, the container does have direct access to the real system kernel, you've got the real system kernel as an attack surface instead of having to get through a VM kernel, bust through the virtualization and then try to dick with the physical system.

    In the case of both, you have the disadvantage of not taking advantage of your distro's package mechanism, your distro is likely to update vulnerable libraries straight away, while a container or VM you are at the whim of whoever updating the whole package to replace vulnerable libs. But, there's plenty of containers and VMs where you simply don't expose them to the outside world, and it won't matter if you get these updates immediately or not.

    Edit: technology maturity. VMs have been around on IBM kit since the late 1960s, of course it was kind of "rediscovered" in the late 1990s/early 2000s for use on PCs, UNIX servers, etc. Plenty mature technology by now. Containers, they can be quite flexible, UNIX has had "chroot jails" since like the 1970s; the enhancements to make a /proc, /sys, seperate process list for "top", etc. and give a better illusion of being on your own full system came out more like late 90's-early 2000s too. But besides the cloud providers, you have shared web providers that run this stuff on a massive scale quite successfully, it's well-understood and mature technology too. I've used a few "shared server" setups where you update your own kernel; they're using a VM; a few where it seemed just the same but no kernel to update (you were in a container.) They're good enough now that that was literally the only apparent difference, it seemed like I was on my own (these were like a $5-10/month plan) 1 or 2-core server with 512MB or 1GB of RAM.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021