Vendor lock-in is truly a TERRIBLE idea ... says, er, Microsoft

The statement that John Gossman thinks "agility and portability are essential. You don't want to get locked in 'TOO MUCH' to a particular vendor, strategy, technology, whatever" does not indicate a sea change in attitudes and practices by (new) Microsof, since the two words "too much" are very telling in that what Microsoft thinks is "too much" cab be and is significantly different from the rest of technology industry, particularly the Free/Open Source Software (FOSS) community and organizations to whom Microsoft remains extremelt antagonistic and predatory - willing to destroy.

A good command and understanding of the English language and subtle nuances of (double) speak is still required by readers of Microsoft propaganda.

Pull the other one!

Microsoft has changed? Horseshit! The market has changed and Microsoft are desperately waddling along behind after it. What's happened now is that a modicum of competition in platforms has been introduced and Microsoft as well as every other proprietary legacy vendor are forced to react to something they never expected to see happen.

Microsoft loves Linux? It's more like they know that outside of Microsoft's own narrow circle "cloud" is pretty synonymous with "Linux". If you look at what is happening in the software development world, everything "cloud" that matters runs on Linux. Everybody except Microsoft is targeting to run on Linux. If Microsoft's Azure cloud doesn't offer Linux in a major way, then they can pretty much write off being considered a serious player in the cloud business.

Microsoft working with Docker in nothing new. Microsoft has been lobbying (and even paying sometimes) open source web oriented platform developers to port their software to Windows. In many cases, the software theoretically ran on Windows, but always as an afterthought. There would be Window specific bugs that languished in bug trackers, installing on Windows was an absolute pain, and the Windows oriented support community was non-existent. Meanwhile on Linux, it was always just "apt-get whatever" to install and get running in seconds, and there was loads of information and help available to get and keep things going. Microsoft saw all the "web 2.0" stuff almost exclusively going to Linux, leaving only legacy workloads for Microsoft. The same sort of rational is going into their work with Docker.

"You don't want to get locked in too much to a particular vendor, strategy, technology, whatever," (Microsoft man John Gossman) says.

That's the standard line from every also-ran vendor. "I'm not the vendor with a lock on the market? Well then, vendor lock-in must be a bad thing, or at least it is unless I get control of the market."

Oh, and if you're not in the cloud, or if you are in the cloud but only use one vendor then you should be fired? Let's deconstruct that a bit. "If you don't buy my product, then you should be fired". Or "if you buy my competitor's product and not mine, then you should be fired". Yes indeed, that's a very convincing argument about the technical and financial merits of Microsoft's Azure cloud product. Yes, I can see how Microsoft has indeed changed.

If you look at the cloud offerings by the market leaders (Amazon, Google, Microsoft), they're all about vendor lock-in. Moving a non-trivial site from one cloud vendor to another is as big of an effort as porting between operating systems. "Cloud" is the new operating system. It's a platform on which you run things. Moving from one vendor's cloud to another's is no more a push button operation than porting a C program from Windows to Linux is just a re-compile. These cloud vendors all know that once they've got enough of your non-commodity IT in their cloud, then for most normal businesses (i.e. companies who just use computers to do other things), the pain and cost of moving to a different vendor will keep you locked in just like those old VB6 and ASP programs keep you locked into MS Windows.

We had "public cloud" before. They were called time shares on mainframes. I've been paid in the past to move people off "public cloud" timeshare mainframes and on to PCs to get massive cost savings. It was a case of re-write from scratch rather than pushing a button.

I'm all in favour of the public cloud in the right applications. Saying though that it's the answer to everything is like saying that NOSQL databases are the answer to all data problems (because they're web scale).

I do think though that IT professionals are going to need to learn about Docker and other similar things in order to run applications on their own infrastructure. Once it is better developed, "private cloud" is going to be how people run their own on site systems, even at the small business level. It won't be about scaling to thousands of instances and global distribution. It will be about ease of installation and management. Done properly, all those nasty dependencies will get containerized, redundancy and migration will be built-in, and people will wonder how they ever did without it.

What everyone ought to be doing at this stage is to download at least one Linux distro that has good support for Docker and a large and active community around it, and start playing around with it so you can educate yourself. If you don't, you will end up like the mainframe guys who laughed at anything related to PCs or x86.

Still don't see what all this docker stuff buys you.

As someone who basically doesn't do windows - it's all linux or bsd.

So assuming you have a private repository of packages (debs/rpms/tarballs ).

And a base image with sane defaults configured to pull packages from your private repository.

Why am i using docker over just packaging an application as a meta-package depending on the bits I need.

So if i only want a sane webserver setup, I package corp-httpd and job done.

The only hard bit is to decide what a host will do, and that can be a shell script that sets a hostname and installs on first boot.

I don't really care what flavour of linux or bsd, it's roughly the same process, why would you bother with docker, when you can do all of this on a loopback mounts with a few hundred lines of shell.

I get that not everybody has access to the tooling to turn a debootstrap into a production webserver,

but it seems that with docker, you still have to do all the packaging right, and that's all the work.

The rest of it is basically unpack tarball and chroot install, which almost everybody has scripted away.

Gentoo does this with custom stage 4, debian does this with seeds, redhat does this with kickstart.

I'm hazy on the proper bsd way but it surely exists.

Most of the deployment stuff can really be boiled down to a kernel and rootfs image, at least on linux.

So Docker helps if I've got all that stuff, but if I've not got all that stuff then what does it buy me.

What am I missing here?

"What a load of total utter ballcocks. Locked in my ass - you're only locked in if you can't be arsed to learn how to cross platform your data."

Yes. And part of this is... if you use/used some vendor's products, they include support for mixing and matching with products from other vendors, and help move your data out if you have to. Other vendors, they range from pretending other vendors don't exist to actively hindering mixing and matching with products from other vendors, and hinder moving you data out if you have to.

IBM in the mainframe era was infamous for this, running from the hardware to the use of EBCDIC instead of ASCII all the way up through the software stack. Microsoft is well known for this; being pretty much the only vendor to not support ODF (until they eventually caved in and did); Exchange using proprietary data formats, with no provided solution of getting e-mail etc. in or out of it. Outlook, same. Various products (including .NET frameworks) that are tied in to SQL Server and only SQL Server (for example, I tried to use Entity Framework with MySQL since it claims to use SQL... it doesn't, I got it to *connect* to MySQL but it actually uses *T-SQL* i.e. non-standard SQL Server SQL and refuses to generate standard SQL for even basic queries.) The list goes on and on. If you're used to Microsoft products you might consider it the norm to have to purchase third-party software to perform some operations that competing software supports out of the box in the interest of interoperability and industry standards.

But, I think this time it's possible they are being genuine (rather than "embrace, extend, extinguish" of the past.)

I think they simply had to own up that many *many* pieces of "cloud" software, frameworks, and development environments, are for Linux and not Windows. Furthermore, I'm just not sure how much Windows-based cloud software will start coming out; Visual Studio is currently frankly a bit of dog's dinner (not that the software is necessarily bad; but the current state of the software and documentation makes it extremely hard for someone to either port software to a "cloud" or start from scratch.)

Lockin in this case fails, and just locks people *out* of using Microsoft products; if they want to sell much more than some hosted SQL Server and Exchange instances, they must support Linux and all that software people now use for cloudy-type services.

Similarly, the container formats, management utilities, and so on, are probably not Linux or Windows-specific. Microsoft past would not have supported this stuff, they would have preferred vendor lockin, viewing supporting standard container formats and so on as helping people move from Azure to other clouds. I think now they have recently realized potential customers will view "Well, these containers and utilities support most clouds and hypervisors except Azure and Hyper-V" as an excellent reason to go elsewhere for their cloud services and hypervisors, so they best support them when reasonably possible.

"Why am i using docker over just packaging an application as a meta-package depending on the bits I need.

So if i only want a sane webserver setup, I package corp-httpd and job done.

The only hard bit is to decide what a host will do, and that can be a shell script that sets a hostname and installs on first boot."

Packaging your application as a meta-package works fine for making your package easy to install on Linux distros that use the same package format as yours.

If you have (for political or business reasons, it really doesn't matter) multiple groups who cannot even agree on what distro they want to use but they don't want two largely-idle servers... well, the one group can use Redhat Enterprise Linux, the other can use Ubuntu, and more or less pretend they each have their own server. This isn't really possible without containerization or virtualization.

There's also the case of sloppy commercial software that the vendor won't support unless it's on "it's own" computer. If that's because they judge resource usage to be so intense it needs it's own machine, I don't expect them to support it under Docker either, you're still effectively violating the system requirements whether a second daemon is running in Docker or bare metal. if the software requires "it's own" computer because the installer's an unholy mess that spams the filesystem, or it requires particular versions of some libraries but doesn't include them in it's own private /.../lib directory, well, Docker would be perfect for that (just as chroot jails were effective for this in the past.)