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. > > 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
