
Kontena 1.0 Released: Developer Friendly Container and Microservices Platform - saanak
http://blog.kontena.io/kontena-1-0/
======
dchuk
Interesting that their "What is Kontena" doesn't actually tell you what it is:

> Kontena is an open source container & microservices platform designed for
> software developers. It is easy to set up, use and maintain. The platform
> has all essential features built-in so there is no need to spend time
> tinkering with it. That means you can focus on what matters most – your
> software.

Replacing "all essential features" with a list of the actual features would be
a good idea in my opinion

~~~
jondubois
This looks like a pretty standard offering for 'orchestration as a service' \-
Essentially hosted Kubernetes/Swarm/Mesos (or whatever orchestrator they're
using).

What I'm sceptical about is the $0 price tag on their core service. They say
they'll make money on support, but what makes them qualified to provide
support for MY particular system? Sure, they'd have expertise to help resolve
any generic container/orchestration issue that I might have, but what if the
issue is related to my own code, the framework, database engine and/or
library/module that I'm using? It's not always easy to tell.

Can they truly help fix my issues efficiently if they don't fully understand
how my system works? They'd have to be really involved in my product to be
able to have the necessary knowledge to provide adequate support.

Maybe this is not 'hands-on support' \- More like over-the-phone support -
That makes more sense I guess.

~~~
torspo
> This looks like a pretty standard offering for 'orchestration as a service'
> \- Essentially hosted Kubernetes/Swarm/Mesos (or whatever orchestrator
> they're using).

It's not hosted. The hosted web-ui thing will probably include some premium
features or some enterprise installation deal, like Ansible has with Ansible
Tower.

> They say they'll make money on support, but what makes them qualified to
> provide support for MY particular system?

Github doesn't offer support for developing YOUR application, only for issues
related to using Github.

------
al2o3cr
All you need now is a homemade wifi booster made out of a Pringles can, then
you can deploy your containers to Kontena using your cantenna.

------
brilliantcode
Is there a valid reason for using microservice unless you have 1000+ engineers
working on a product?

The microservice argument is compelling to begin with but shifts the
separation of concern to the extreme, to the point that you now have intra
service level delegation bubbling up with complexity.

Suddenly, fetching a blog post now involves multiple context switching than
something written in RoR deployed on beantstalk.

If I was forced to use microservice architecture I would not try to deploy it
myself instead using Azure Fabric because breaking a monolithic framework
codebase itself is such a monumental task especially when you are dealing with
legacy code.

I feel as if microservice is the "blockchain" of backend architecture space
where it's actively solving problems that isn't there. Much like moving to a
cryptographic linked-list with decentralized consensus creates ton of drama,
splitting services into as many pieces as possible seems like asking for
trouble.

~~~
stevekemp
There are cases where it makes sense. In my own case I've splitup several
parts of a "simple web application" into services.

For example if a new user joins my site I want to send them a welcome email.
The traditional way to do that would be to have the back-end send the mail
directly. But of course sending email can block and take a while, so you
really want to do it in a different process, not inside your Rails/PHP/Perl
CGI process.

So in this case I submit a "new.user.joined" event to a work queue. I then
have a micro-service which pretty much sits idle, until it sees such an event,
and then it sends the mail.

I have a bunch of these little services that just listen for events that they
care about, and do one specific job. If I were in ruby they could be sidekiq
workers, but since I'm not I'll just call them "microservices". They can be
started/stopped independently, and though they do have application knowledge
(e.g. where to load email templates from) they're pretty decoupled.

Perhaps I could have picked a better example, but I think it still counts!

------
daenney
> Among those features was support for stateful containers and multi-region,
> something no one else was doing in the container platform world.

Stateful containers? Depending on what you mean by that it seems to me that's
a rather bad idea. The idea is that containers don't contain state. Doesn't
mean it can't be an application that stores state somewhere else, but the
container itself shouldn't be stateful.

If you mean being able to run a database through a container (while still
storing the data not in the container) then yes, sure, stateful container. But
that's been feasible for a long time. I don't think it's fair to claim that no
one else was doing that in the container platform world.

~~~
gtirloni
Feasible, yes. Easy to coordinate, not so much.

Things like this are still alpha/beta for a reason:
[http://kubernetes.io/docs/user-guide/petset/](http://kubernetes.io/docs/user-
guide/petset/)

