On Mon, Dec 11, 2017 at 4:30 PM, Burr Sutter <[email protected]> wrote:
> > > On Mon, Dec 11, 2017 at 8:53 AM, Gorkem Ercan <[email protected]> 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 >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/devtools >>> >> > > _______________________________________________ > Devtools mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/devtools > >
_______________________________________________ Devtools mailing list [email protected] https://www.redhat.com/mailman/listinfo/devtools
