Kontena 1.0 Released: Developer Friendly Container and Microservices Platform(blog.kontena.io)
blog.kontena.io
Kontena 1.0 Released: Developer Friendly Container and Microservices Platform
http://blog.kontena.io/kontena-1-0/
4 comments
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.
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.
[deleted]
> 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.
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.
[deleted]
I would like to learn more too, but their learn page 404s [1] for me.
Click "learn more" on main website: https://www.kontena.io
[1]: https://www.kontena.io/learn
Click "learn more" on main website: https://www.kontena.io
[1]: https://www.kontena.io/learn
It looks like the right url is https://www.kontena.io/platform
I got there with the 'learn' button in the footer. They should probably update that link.
I got there with the 'learn' button in the footer. They should probably update that link.
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.
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.
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.
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!
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!
> 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.
But it's not about splitting it in as many services as possible. There's also nothing saying you can't live in a hybrid state, you don't need to go 100%. There's plenty of orgs that run a monolith and little by little break out components they need to. Or sometimes build something new as a microservice for other reasons (like the framework/language of the monolith is limiting them to solve a use case) and hook that up to their monolith.
But it's not about splitting it in as many services as possible. There's also nothing saying you can't live in a hybrid state, you don't need to go 100%. There's plenty of orgs that run a monolith and little by little break out components they need to. Or sometimes build something new as a microservice for other reasons (like the framework/language of the monolith is limiting them to solve a use case) and hook that up to their monolith.
I agree that microservices appear to move the complexity around (and add to it), rather than necessarily making things simpler.
My feeling is that they make a lot of sense for addressing the organizational problems of having multiple sets of developers working on different parts of the same product, so it's valuable for larger organizations. They have already paid for a lot of operations infrastructure, so breaking a multi-team monolith into a service per team is viable and useful for getting things done. People problems are the hardest problems in tech.
The organization that I work for almost never has more than a "two-pizza team" (eight people) on any one project, so monoliths are a more efficient way for us to build and ship products. We do use external services of course.
My feeling is that they make a lot of sense for addressing the organizational problems of having multiple sets of developers working on different parts of the same product, so it's valuable for larger organizations. They have already paid for a lot of operations infrastructure, so breaking a multi-team monolith into a service per team is viable and useful for getting things done. People problems are the hardest problems in tech.
The organization that I work for almost never has more than a "two-pizza team" (eight people) on any one project, so monoliths are a more efficient way for us to build and ship products. We do use external services of course.
For developers yes, I'm working on a similar platform just now - you wouldn't be developing a 3D game on these kinds of things, but containerised development environments are definitely The Sane Way To Do It, for various shades of 'it.'
> 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.
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.
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/
Things like this are still alpha/beta for a reason: http://kubernetes.io/docs/user-guide/petset/
> 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