David, I very much like what you are outlining here. On Sun, 27 Sep 2020, 14:30 David Yahalomi, <[email protected]> wrote:
> Hey, > > Just wanted to chime in as it is a topic we've talked about multiple times > internally. > There are a couple of drawbacks to using a microservice architecture that > I think we should address. The first of which is the difficulty in managing > the codebase and the deployed environment. > > Up to now, I feel like CN has failed to address those difficulties in a > good way. > At the moment, there is no way to run Fineract CN without a bloated > Kubernetes / Docker Compose setup. It also takes a decent amount of time > just to startup everything. Even if you are using a minimal set > configuration. > What I would expect is to have the same experience as Serverless delivers. > Using something like serverless would definitely support the composability > use case that is definitely there. > > Also, I think that co-existence with Fineract, should be a priority. > If I were to start from scratch, I would go in a path that transforms > Fineract to Fineract CN by doing the required work to split the > different modules of Fineract to microservices, but without changing the > logic or the API that is being exposed. > An example of that would be to take the users module > (org.apache.fineract.useradministration) of Fineract and turn it into a > microservice but the catch here would be that once you deploy this new > version, it migrates the related tables to the new microservice data source > (Postgres schema?) and it takes over the /users API. > > This way, organizations with existing Fineract deployments could also be > part of this new approach and could contribute their own use cases and > requirements to the mix. > > Adding to this approach, I think we should consider implementing those new > microservices with the language that has the most amount of open-source > attention, which is Javascript or better yet, Typescript. We're for one, > developing all of our services on top of Fineract with Typescript and get > to enjoy the rich open-source ecosystem around it that I feel like is > lacking in Java. > But that's a whole other topic which I think might have way more push back. > > Best, > > David Yahalomi > Co-Founder > > Rothschild Blvd 3, Tel Aviv-Yafo, Israel > mobile: + 972 52 817 9787 > email: [email protected] > <https://articode.co> > > > On Sun, Sep 27, 2020 at 2:27 PM Juhan Aasaru <[email protected]> wrote: > >> Hi! >> >> Fineract-CN hasn't managed to get a community that would actively push it >> forward. >> It could happen in the future or it could never happen. >> >> Anyway - rather than changing CN to a radically different direction I >> would rather advise >> to gather interested parties together and start from a clean perspective >> and name it >> something else - Fineract NS (New Start) or whatever. >> This doesn't mean it couldn't borrow code from Fineract-CN if needed. >> Also we have the ability to spin up new apache/fineract-* Github >> repositories whenever needed. >> >> The new start could only work if there is critical mass of interested >> parties on board from >> the start and they work together. If there is only one company >> outsourcing its work >> (without others having much say what technologies to use etc) then it >> won't be the apache >> way to build new software and thus not a very sustainable model. >> >> Juhan >> >> >> Kontakt James Dailey (<[email protected]>) kirjutas kuupƤeval L, >> 26. september 2020 kell 19:30: >> >>> Thanks Saransh for bringing this conversation forward and on-list. I >>> believe we need more ideas about fineract-CN, and I agree that a key >>> 'story' is accessibility of the code to developers and avoiding the >>> monolithic code base trap. >>> >>> I'll note that recently fineract 1.4 was released, a major improvement. >>> That needed our strong focus and is a community success. >>> >>> fineract-CN has not yet had the same level of focus, but I believe that >>> it should. >>> >>> It's important that we also have those with fineract CN in production to >>> help drive the roadmap. There are several and some of those folks have >>> proposed new directions as well. So, this is an active discussion. >>> >>> Previously we discussed on list the importance of the 'minimal set' of >>> microservices. Can you say whether you have the same list or a smaller >>> set? Or larger set as the required microservices for a 'release'? >>> >>> Or how should we think about composability? >>> >>> In terms of your re-architecting ideas, I look forward to >>> learning more. >>> >>> @jdailey >>> >>> On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <[email protected]> >>> wrote: >>> >>>> Hey folks out there , this email is intended for Fineract CN >>>> improvement, before setting the ground i would like to clear up a few >>>> things ; one this is not a separate project , this concerns overall change >>>> from ground up and possible variation of the existing project out there. >>>> >>>> Possible scenario >>>> >>>> We would like to propose fundamental changes to bring forward >>>> contribution that has been (if some of us are still wanting to contribute >>>> please come forward) >>>> >>>> Another possible design issue we could not figure out anything at first >>>> glance. >>>> >>>> Developer experience, we would like to contribute back to the community >>>> the finest development exp. >>>> >>>> Architectural change to fit close to the nature of Microservices >>>> >>>> I have created a Jira ticket š« let me know if anyone wish to discuss >>>> this and get it through this >>>> >>>> Possible Solution >>>> >>>> To get contribution back we need automation at the templating side (We >>>> would like to share our automated generator experience so far) >>>> >>>> Another important thing is the architecture needs to suit the needs of >>>> the partner and developers to quickly integrate with any services. >>>> >>>> Grouping these services from the partners together and making them >>>> available with existing solutions . >>>> >>>> Some Blockers >>>> Need to evolve from the idea of monolithic to to true Microservices >>>> approach >>>> >>>> Reference >>>> https://issues.apache.org/jira/browse/FINCN-239 >>>> -- >>>> 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. >>>> >>>
