[thoman23]

As someone who wants to pitch containerization at my enterprisey company, what is the takeaway message here? Do I still assume Docker/kubernetes is the way to go? Sounds like I don't want to stake my reputation on Docker Swarm? Is there another container platform this community recommends other than Docker?

[rodgerd]

1. Swarm lost, don't bother.

2. The interesting part of containers is the tooling people have built around them to make it easy to ship and run software stacks easily.

3. Building all this shit from primitives - downloading your own istio & k8s - is painful and will waste a lot of time and frustrate people.

Go get an opinionated k8s+containers solution that you can plumb into your dev tooling and will let you "commit code, spin up container fleet" easily, because that's the value: reliably increasing velocity.

OpenShift is one example I've worked with and like. There are others. Don't waste your time and money fucking around with individual bits of the stack.

[thoman23]

Thanks for the advice! Is there one opinionated offering that has solid Windows Server support? It looks like OpenShift is working towards it, but it’s not ready yet.

[whalesalad]

I’d upvote this twice if I could.

[rgovostes]

I've been wondering along the same lines. I work at an academic institution where small one-off applications are regularly developed for research projects. The technology stack is not consistent across applications and the scientists do not have the motivation to radically change their development habits.

I'd like to move these applications to a common platform, to reduce some of the maintenance burden, introduce monitoring, perform security audits, etc.

I vaguely imagine this platform as being self-service, where the user creates a project and points it to a git repository with a docker-compose.yml file, and then a minute later the service is reachable at https://projectxyz.____.edu.

[cpitman]

You are describing OpenShift (https://www.okd.io), a kubernetes distribution that adds on top a lot of common needs like monitoring, log aggregation, git->image build workflow, self-service via a CLI or web console, etc.

I work at Red Hat, happy to answer questions. We also just released OpenShift 4.0, which brings in all the features from the CoreOS acquisition, like single push button kubernetes and OS upgrades.

[rgovostes]

Thanks, I thought OpenShift sounded like it. Does the open source version include a web interface as well as the commercial product?

[cpitman]

Yeah, Red Hat's products are (almost across the board) 100% open source. No "extra" features that you have to pay for.

[wmf]

OCI+k8s is the standard but Docker may not be the best OCI implementation for you. Choose which k8s distro you want then use whatever runtime is included with that so you don't pay double.

[cyphar]

OCI is the "standard", it's just that nobody actually uses it. Everyone is still emulating the Docker format, and Docker doesn't even support OCI images (the pull request adding the most basic form of support is 2 years old[1]).

For the record, I work on the OCI specs (and maintain runc and image-spec) and would really love it if people actually used the OCI formats and we could freely innovate in an open spec. But that's not really the world we live in.

(I'm aware containerd supports OCI images and most folks now support the runtime-spec. But how many people use containerd directly? Not to mention that since the OCI distribution-spec is creeping along so slowly everyone still converts back to Docker to actually publish the damn things.)

[1]: https://github.com/moby/moby/pull/33355

[praseodym]

Recent containerd versions have CRI support built in, so Kubernetes (Kubelet) can use it directly.

[cyphar]

Images are still pulled from Docker registries, and thus there is still conversion to OCI rather than OCI being the primary format. cri-o has been doing the same thing for the past few years.

[streetcat1]

Yes. Assume Docker/kubernetes is the way to go. In general the sure bet right now is

Docker / Kubernetes / Istio .

You need all three for good micro-service platform.

[zenlikethat]

I'd hardly call Istio something you "need". Between Docker and Kubernetes you'll have your hands well full enough already and I'd recommend getting a good grip on those first and avoiding the service mess until you are very convinced your life will be worse if you don't slap Envoy, Mixer, Pilot, Citadel, and Galley on top.

More complex != better.

[streetcat1]

I think that the OP is looking for a standard/container based enterprise platform, so I would install both since only both provide the complete solution.

I.e. install and standardize on both, but start using features as needed (of course).

I.e. I would rather find out any architecture issues with istio sooner, than trying to bolt it on top of some kuberentes only app.

[williamallthing]

The service mesh doesn't have to be complex. If you want the value of the service mesh at a fraction of the complexity, start with Linkerd.

[reilly3000]

There certainly are others, but Docker ‘just works’. Start with a small team and show some value/velocity.

[nailer]

Reconsider it. Unless your enterprisey company is building a platform itself, you don't care about VMs, containers, or MicroVMs.

Build serverless workloads and run them on whatever compute is available.

[donmcronald]

How do you build serverless workloads that are portable between compute providers?

[k__]

You don't.

The the money you spend for being provider independent is the very money you save by going serverless.

Leaves the question: Is the risk worth the money saved?

[GordonS]

Azure's Function App engine is OSS, so you could go with Azure's FaaS, but retain the option to self-host on VMs or servers anywhere.

[alexellisuk]

OpenFaaS (around 2.5 years since launch) with 200 contributors, 17k stars and around 40 end-user companies in production. www.openfaas.com

[donmcronald]

Thanks for this! It looks very cool.

[kauboy]

How about Google cloud run?

[solatic]

Knative, but it's still immature, like most serverless frameworks.

[nailer]

Most serverless frameworks give you some degree of portability across the majopr providers. I work on architect (which is currently AWS only) which is going to add Azure support pretty soon.