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.
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?
A few thoughts on this, firstly you are right to an extent - Docker doesn't give you portability completely due to binary dependencies, but if for example I wanted to move my app from the same major version of CentOS or RHEL on a virtual machine to something running with the same major version in the cloud it should be relatively straightforward. You are right though that this won't work going from something like Ubuntu to Suse for example.
The key bit is that we are starting to converge on a standard container for the Linux OS and with Red Hat working to get things working with SELinux we should have a pretty awesome container for our apps.
Given the above I'd rather standardise on an Open project that adds a lot more value to LXC and hides that complexity away and given the largest linux vendor is putting it's weight behind this I'd say this is rather awesome!
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.
Very true, this would be more compelling if Heroku got behind the project themselves because their build packs would be very portable and possibly a future standard.
It seems that Docker is becoming the container of choice but how apps are layered on top is still very much up for debate.
I really hope so, with the work that Red Hat and dotCloud are doing it will be possible for a Docker container to run on any Linux OS - which is a significant first step towards ubiquity.
Whether Heroku's Buildpacks are then able to be layered on top of a Docker container is the question, not impossible as they are open source but will Heroku come on board?
It seems Red Hat's OpenShift is making the moves towards this being possible with their cartridges which are the equivalent of the Heroku Buildpacks.
The key bit is that the community seems to be converging around some standards that could lead to true application portability for PaaS, something we don't really have yet.
Hi Chris, I don't think that the Docker team have gotten that far yet in knowing where they are going to go, but you can imagine that in the future I blogged about that you might be able to layer OpenShift's gears on top of Docker - now that would be very cool!
There is certainly some convergence going on here which is really exciting for PaaS.
This might cannibalise their business model in such an undeveloped market, they are all about lock in currently. There is definitely space in the market for an open source based MBaaS/BaaS that allows you to roll your own or use their hosted version.