Hacker News Reader

Comment by talawahtech | Hacker News Reader

I kinda wish Microsoft would just acquire the rest of the company and be done with it. It fits in very well with their Developers, Developers, Developers, Developers focus. Especially in the era of Open Source friendly MS.

VSCode, GutHub and Docker. Three peas in a pod.

View on HN

What a turn-around Microsoft has had: if you'd suggested to me 10 years ago that something like Docker should be acquired by MSFT, I would have recoiled. Yet here I am in total agreement.

While I think CNCF/Linux Foundations would be a better fit, I do agree that the rest should probably come under a more protective umbrella. Given the many options, MS is probably one of the better ones. Definitely wouldn't want to see Oracle step in, and while I appreciate RedHat they are much slower moving (since IBM's acquisition, and I'm not sure if for the better).

Red Hat has quay and podman/cri-o, that are basically competitors to docker.

My theory at work is that this is arbitrage. Docker wouldn’t sell to Oracle. So instead, Mirantis buys the Enterprise side and in 6 months will sell to Oracle. At which point everyone who has ever looked sideways at a Docker download will be subject to an Oracle licensing audit...

Hyper-V containers and VM instances are already more than enough.

It kind of wouldn't make sense because Azure doesn't support deploying with Docker (it is in preview mode but its almost unusable)

> Azure doesn't support deploying with Docker

Huh? Not sure what you mean by this - Azure has a wide range of container support, including:

  - Azure Container Registry
  - Azure Container Instances
  - Azure Kubernetes Service
  - Azure App Service with Web App for Containers

I'm sure there is other stuff I've missed too, and I seem to recall there is some kind of container support for a new spin-off from Service Fabric.

There's also support for deploying Dockerfiles from Visual Studio and Visual Studio Code

You can also run VS Code as a split-brain system with the UI in your OS and the extensions and the filesystem inside a Docker container, so that you can say, run VS Code extensions that rely on *nix utilities to run.

https://code.visualstudio.com/docs/remote/containers

It's pretty nifty.

That's really cool. I wonder if someone has made a docker-compose file that sets up "ever" language's "best" LSP server so you can, with one command, get an IDE that can work with any repo.

I know at least with Web App for Containers, Microsoft suggests explicitly not to use in production because it's in preview mode. I've used Web App for Containers and it's almost unusable and nothing has changed in the last 4 months.

I have to agree with Microsoft here, Azure is still not completely Docker-ready.

Anything MS is about driving traffic to Azure and avoid leaking traffic to AWS/GCP.

In this context, I am not sure how acquiring docker will do that?

How are VS Code and GitHub about driving traffic to Azure?

For VSCode, I think that Microsoft is introducing extensions for specific MS services. For exmaple, you can run ML experiminets directly from VSCode.

I would expect VSCode to slowly become azure services UI.

For GitHub, Look at the steps from the acquisition forward. For example, github actions is a CI/CD run on azure. Next step would be a gitops service that will integrate with AKS. Etc.

> Next step would be a gitops service that will integrate with AKS

That means Weaveworks swallowed up soon then[1], with its Flux GitOps for Kubernetes[2].

[1] https://www.weave.works/

[2] https://fluxcd.io/

I think VS Code and GitHub are mainly about branding and building a new reputation. Microsoft provides first-class development tools (VS Code and GitHub) to millions of developers every day now. Once this becomes the new normal to developers, Azure easily becomes a serious contender for running your applications as well.

First class, built in integrations.

While an open API is offered so anything can be integrated, nothing is going to beat custom built in integrations for user experience. Also, built in integrations are always a step ahead in terms of time to market too. Even if only by a few weeks or months, this really matters.

The example I'd point out is integration of Typescript vs Flowtype in VSCode. The Flowtype plugin maintained by the community was a good effort, but was always quite a way behind the native Typescript integration. There are more reasons for this than just technical, obviously, but that's one of the main ones.

I think, having been a user of both, the awesome native VSCode integration was a huge factor in Typescript 'beating' Flowtype. It'd be a similar idea for Azure too.

Reply on news.ycombinator.com