[Devtools] Great podcast: Kelsey vs John :-)

Burr Sutter bsutter at redhat.com
Mon Dec 11 15:30:26 UTC 2017


On Mon, Dec 11, 2017 at 8:53 AM, Gorkem Ercan <gercan at 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.


>
> Hopefully that makes sense.
>>
>> Because I am now fairly certain this is the right way to go :-)
>>
>> Burr
>>
>
>
> _______________________________________________
>> Devtools mailing list
>> Devtools at redhat.com
>> https://www.redhat.com/mailman/listinfo/devtools
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/devtools/attachments/20171211/b46c543a/attachment.htm>


More information about the Devtools mailing list