Auto config at Provisioner CN

[Saransh Sharma <sa...@muellners.org>]

Hey Juhan , if you are reading this email.. I am looking to understand how
to make CN services more agnostic by providing more services config on
hand, as I see right now it's configured to have only postgres.

So essentially it's tied to postgres then (are we suggesting that we only
use postgres).

This can become problematic actually why ? because we cannot add more DB
support to standalone isolated env.

We are trying to have isolated services with individual service support of
DB and externally services connected to each service. This way we could add
independent services made out of any language and any DB.

Let me know your thoughts.


-- 
Thanks and regards,

Saransh Sharma
Research Partner

This mail is governed by Muellners®  IT policy.
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by e-mail.

Re: Auto config at Provisioner CN

[Saransh Sharma <sa...@muellners.org>]

Hey

This image attached here would make sense.

While upgrading services we realised there were some services which made
sense in the limited scope and most of the services are just constant and
using the same values here and there.  What we would like to achieve while
maintaining fineract CN codebase and contributing it back is that when we
make a new service we associate those features using redis hashes.

Why redis? Its easy to maintain(cassandra is also easy but i think
cassandra services are expensive also for small MFI maintaining such level
of service is too much)

We want multi-tenancy to maintain those things since cassandra is just
saving commands (after looking at code). So redis hashes would maintain and
provide these things at runtime.

Another limiting thing is adding and relying on code dependency like anubis
and etc.. , we want the developer to kick start with less actions and less
addition and dependency too.

We have kick started the UAA also since the identity service is also
limited in some scopes and can be thus achieved using a standalone Oauth.

To summarise the provisioner now creates the tenants , we will create those
services with features like having a new type of DB with configs etc.

Too many scattered thoughts :)

Let me know your thoughts on this.



On Mon, Jun 29, 2020 at 12:54 PM Juhan Aasaru <aa...@gmail.com> wrote:

> Hi!
>
> I quite don't understand what you mean.
>
> Is your question about making each micro service only have its own
> database that is not shared with other micro services? In my opinion this
> is doable and worth further discussion.
>
> Or do you have a need to use other database vendors besides Postgres. If
> this is the case then my answer is that we have limited resources and if we
> would support different database vendors it would consume too much of the
> limited development resources we have at hand.
>
> Kind regards
> Juhan
>
> Kontakt Saransh Sharma (<sa...@muellners.org>) kirjutas kuupäeval L,
> 27. juuni 2020 kell 19:54:
>
>> Hey Juhan , if you are reading this email.. I am looking to understand
>> how to make CN services more agnostic by providing more services config on
>> hand, as I see right now it's configured to have only postgres.
>>
>> So essentially it's tied to postgres then (are we suggesting that we only
>> use postgres).
>>
>> This can become problematic actually why ? because we cannot add more DB
>> support to standalone isolated env.
>>
>> We are trying to have isolated services with individual service support
>> of DB and externally services connected to each service. This way we could
>> add independent services made out of any language and any DB.
>>
>> Let me know your thoughts.
>>
>>
>> --
>> Thanks and regards,
>>
>> Saransh Sharma
>> Research Partner
>>
>> This mail is governed by Muellners®  IT policy.
>> The information contained in this e-mail and any accompanying documents
>> may contain information that is confidential or otherwise protected from
>> disclosure. If you are not the intended recipient of this message, or if
>> this message has been addressed to you in error, please immediately alert
>> the sender by reply e-mail and then delete this message, including any
>> attachments. Any dissemination, distribution or other use of the contents
>> of this message by anyone other than the intended recipient is strictly
>> prohibited. All messages sent to and from this e-mail address may be
>> monitored as permitted by applicable law and regulations to ensure
>> compliance with our internal policies and to protect our business. E-mails
>> are not secure and cannot be guaranteed to be error free as they can be
>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
>> to have accepted these risks if you communicate with us by e-mail.
>>
>

-- 
Thanks and regards,

Saransh Sharma
Research Partner

This mail is governed by Muellners®  IT policy.
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by e-mail.

Re: Auto config at Provisioner CN

[Juhan Aasaru <aa...@gmail.com>]

Hi!

I quite don't understand what you mean.

Is your question about making each micro service only have its own database
that is not shared with other micro services? In my opinion this is doable
and worth further discussion.

Or do you have a need to use other database vendors besides Postgres. If
this is the case then my answer is that we have limited resources and if we
would support different database vendors it would consume too much of the
limited development resources we have at hand.

Kind regards
Juhan

Kontakt Saransh Sharma (<sa...@muellners.org>) kirjutas kuupäeval L, 27.
juuni 2020 kell 19:54:

> Hey Juhan , if you are reading this email.. I am looking to understand how
> to make CN services more agnostic by providing more services config on
> hand, as I see right now it's configured to have only postgres.
>
> So essentially it's tied to postgres then (are we suggesting that we only
> use postgres).
>
> This can become problematic actually why ? because we cannot add more DB
> support to standalone isolated env.
>
> We are trying to have isolated services with individual service support of
> DB and externally services connected to each service. This way we could add
> independent services made out of any language and any DB.
>
> Let me know your thoughts.
>
>
> --
> Thanks and regards,
>
> Saransh Sharma
> Research Partner
>
> This mail is governed by Muellners®  IT policy.
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents
> of this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by e-mail.
>