@David Yahalomi <[email protected]> your approach is quite solid. On Mon, Sep 28, 2020 at 12:10 PM Michael Vorburger <[email protected]> wrote:
> 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. >>>>> >>>>
