just to add to the ideas ... neither kedge nor che will actually be able
to nor would want to have the full picture.
devs would probably often want to only work with a subset of services
and some probably with a mix of "mocks" or staged services...
dev teams will need a lot of skins for this cat.
/max
http://about.me/maxandersen
On 11 Dec 2017, at 17:13, Tomas Kral wrote:
On Mon, Dec 11, 2017 at 4:30 PM, Burr Sutter <bsut...@redhat.com>
wrote:
On Mon, Dec 11, 2017 at 8:53 AM, Gorkem Ercan <ger...@redhat.com>
wrote:
On 11 Dec 2017, at 8:17, Burr Sutter wrote:
http://devopscafe.org/show/2017/6/18/devops-cafe-episode-72-
kelsey-hightower.html
If you do not know about this podcast...well, take your Christmas
break
and
listen to about 40 hours worth of content - the vast majority is
amazing.
In this particular example, John (now an ex-Docker guy) talks about
the
value of Docker Compose and Kelsey slams it.
Here is the 'big idea':
Kelsey continues to make the point that Kubernetes is not a PaaS
and
that a
this kind of declarative solution must target a PaaS. My
interpretation
is
that a specific customer must first put all the "sub-components"
into
their
own custom "catalog" and the declarative composition crafted by the
developer must make selections from that "catalog". There are
just too
many details that Kubernetes, nor a vendor can choose up front.
Kelsey
rattles of a ton of them related to Redis like not just storage but
replication & clustering configuration, backup configuration,
sharing
configuration, security, etc, etc. All of those details should be
established by a particular customer's IT folks and then a
developer can
declarative just say "i want a Redis for my app".
This is the direction that I was looking at for Che. In addition to
subcomponents the metadata
also needs to include the relationships between those components.
Nowadays running a lonely
container does not mean much.
Like Microservices and unlike Highlander - there can never be only
one!
good point on the relationships - if my Redis service needs
underlying
storage then at ACME corp, we use XYZ storage configured like so, the
end-user (aka developer) need only answer a few questions.
This is what we are trying to do with Kedge. You would use Kedge to
define
just your application. For other standard services like databases that
your
app requires your would use Service Catalog or Helm.
You just define relationship to those services in your Kedge file.
This is still in the idea phase, but it is something that we have on
roadmap.
Hopefully that makes sense.
Because I am now fairly certain this is the right way to go :-)
Burr
_______________________________________________
Devtools mailing list
Devtools@redhat.com
https://www.redhat.com/mailman/listinfo/devtools
_______________________________________________
Devtools mailing list
Devtools@redhat.com
https://www.redhat.com/mailman/listinfo/devtools
_______________________________________________
Devtools mailing list
Devtools@redhat.com
https://www.redhat.com/mailman/listinfo/devtools
_______________________________________________
Devtools mailing list
Devtools@redhat.com
https://www.redhat.com/mailman/listinfo/devtools
