Azure Container Instances vs. CoreOS rkt / Container Linux (project ended)

It is very well suited for local testing where one knows what is being worked on and knows all the dependencies of the software project. On the other hand, it would be less appropriate in situations where a simple chroot can do the trick without the overhead of running a Go application.

Incentivized

• Running a secure container without messing up with low-level details
• Very clear and straightforward approach to building a container
• A way to go for new projects thinking of containers
• Comprehensive and well-written documentation compatible with UNIX keep it simple way of thinking

Incentivized

• Market share, it's often very difficult to find new talent who use CoreOS rkt.
• Lack of wow features, CoreOS rkt doesn't necessarily offer any immediate advantages over other container solutions.

Incentivized

We evaluated CoreOS rkt and Docker when selecting software solutions for my department. We ended up using CoreOS rkt because of how well it fits with CoreOS and the choice of gRPC for the API. We provide a managed service that runs CoreOS on a bare metal server, CoreOS rkt was a logical choice for compatibility. We also found that developers were having better scusess interacting with gRPC than other container engines REST protocols. It was a close race but eventually there were just enough small benefits to push CoreOS rkt in front of the competition.

Incentivized

• Developers spend less time configuring and more time coding.
• Less time training developers as CoreOS rkt lets them use whatever hardware and operating system they want.
• Reduced our IT costs, solutions are containerized using CoreOS rkt meaning they can write one solution with many developers in mind.

Incentivized