tenfourty

OP here, I agree. You can get super far with a service like fly.io/Heroku/Netlify/Vercel etc. (pick the one that works with your stack). VMs are an anti-pattern as well for the early stages of an application or startup.

[OP here] It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn't use Kubernetes and a bunch of other "cool" things for your product.

Most folks building software at startups and scale-ups should avoid Kubernetes and other premature optimisations. If your company uses Kubernetes, you are likely expending energy on something that doesn't take you towards your mission. You have probably fallen into the trap of premature optimisation.

Please don't take this post to be only aimed against Kubernetes. It is not. I am directing this post at every possible bit of premature optimisation engineers make in the course of building software.

wrong, read it all again!

so Window's licences will be free?

will Windows base images be made available on the Docker Hub? How will that work?

I completely agree that open source is/has taken over the world - and that that is a fundamentally good thing for everyone on this planet.

I did notice some things that aren't quite right though so here are some comments from a Red Hat employee - though these are my opinions and not necessarily those of my employer.

> The tenet of open source has always been to give away the “open core” for free, and then charge for additional features.

and

>Companies can try a simple version of an open source app for free, and if they like it, can pay for value-added enterprise features.

This is not actually true for the way Red Hat sells it's products, in fact we do something that is quite the opposite but far more powerful. All features are in our community projects like Fedora or JBoss Wildfly, these features might be a mix of whatever is the latest and greatest that people want as well as all the normal bits that you'd expect. When we make an enterprise ready product out of these community projects like Red Hat Enterprise Linux (RHEL) or JBoss Enterprise Application Server (EAP) our focus is actually on stability and longevity, in other words something that we can stand behind and support for up to 10 years or more! So we actually remove or don't pull in features from the project that aren't ready yet (which we know because we employ a lot of the professional engineers that are committers). We then have a rigorous testing process before releasing these enterprise ready products to our subscribers. One of the key bits that people don't understand is that once we release an enterprise product we will then back port from the latest and greatest community version all security and bug fixes for the supported life of the enterprise product.

Two things to note about this, the enterprise versions are open source as well and we follow an upstream first approach so bug fixes and security patches are applied to the upstream version as well as to the stable enterprise version so upstream has all the latest fixes BUT it also has all the latest features and changes so it's more like our R&D version that you can play with and do some development on but wouldn't be something we would stand behind for production environments.

I wanted to point this out as this is fundamentally different from the open core model you describe and which I seriously object to as an approach because it still locks you into the vendor who is selling you the extra bits.

> The first wave of open source leaders, including Red Hat, relied almost entirely on the community to build their products.

I'm not sure this statement is entirely true, Red Hat has been a top committer to the Linux kernel and to the JBoss projects for many many years and in fact around half of our company are professional engineers working on open source projects!

I guess the point here is that Enterprise Linux represents a significant share of the market and if Docker doesn't work on it then it can hardly be a standard. With Red Hat behind this project it's a significant boost to Docker becoming a standard around Linux containers. Does that make sense?

I'd say this is a very negative comment because you are purely criticising without proposing where the community is actually going in your point of view. It might be more constructive to give your opinion on where containers should go if not Docker. I agree with you that this has been a pivot by dotCloud, but my hat goes off to them for it and I totally respect them as a startup for doing it!

I absolutely agree with you, Docker is where the community seems to be converging for standardisation around linux containers. This is a great first step towards application portability from physical, virtual and PaaS. Now it will be interesting to see who/what will win when it comes to the cartridge/buildpack side of things.