[Container-tools] Rethinking Nulecule

[Aaron Weitekamp]

On Thu, Mar 10, 2016 at 7:18 AM, Burr Sutter <bsutter at redhat.com> wrote:

> I like the proposal! :-)
>
>
I agree we should encourage adoption, zero barriers, etc, but I think we
should go in the other ​direction with the spec:
- focus on the high-level definition of the application and service
discovery, e.g. I want to deploy and connect 2 services
- we push artifact generation AND parameterization[1] AND application
lifecycle down to the platform, e.g. kubernetes and openshift.

With this approach we add value to the platform without duplicating. We
stop chasing low-level platform artifact/api changes. We help people
compose and distribute applications.

[1] by parameterization I mean the platform should have its own mechanism
for parameterization that we simply hook into.


> On Thursday, March 10, 2016, Ratnadeep Debnath <rtnpro at gmail.com> wrote:
>
>> Hi all,
>>
>> Till now, Nulecule's focus has been to be a spec to package and ship
>> nested, composable multi container applications. Well, it helps us to
>> focus on a smaller problem and solve it well. This also keeps
>> implementation of Nulecule, e.g., atomicapp, lean and simple.
>>
>> However, is it enough?
>>
>>
>> I will try to highlight a few shortcomings of the current Nulecule spec:
>>
>> - the spec file does not fully describe the architecture of the
>> applications
>> - it's difficult to get started with Nulecule as it requires knowledge
>> of underlying providers
>> - it's not possible to use the same Nulecule spec to deploy a Nulecule
>> application across providers without writing artifacts for each
>> provider
>>
>>
>> So, we are thinking in the lines of extending Nulecule SPEC to
>> describe a multi container application completely in the SPEC file,
>> similar to Docker compose file. This will enable us to:
>>
>> - to automatically generate artifact files for underlying providers
>> from the SPEC file
>> - to override the generated artifact files, if needed
>>
>>
>> The advantages of such a change would be:
>>
>> - zero barrier entry for developers
>> - package once, in one language, and deploy anywhere
>>
>>
>> This move will be beneficial to:
>>
>> - developers, with little knowledge about openshift, k8s, marathon, etc.
>> - ISVs to package apps to run across multiple providers
>> - switch seamlessly to another provider
>>
>>
>> We're keen to hear your feedback on the above proposed changes. Will
>> this help to make Nulecule more awesome and user friendly? Let us know
>> what you think.
>>
>>
>> Thanks,
>> rtnpro
>> --
>> Ratnadeep Debnath,
>> https://www.waartaa.com
>> GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02  B785 2119 5486 F245 DFD6
>>
>> _______________________________________________
>> Container-tools mailing list
>> Container-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/container-tools
>>
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20160310/c1492122/attachment.htm>