Hi Myrle - this is good information and clarity. I do have some comments inline here and some further suggestions.
On Mar 10, 2018 12:09 AM, "Myrle Krantz" <my...@apache.org> wrote: Hey James, Fineract CN is a from-the-ground-up rewrite. Most important: it includes a UI (fims). Fims is Apache-licensable and is actually part of the Fineract project, unlike the Mifos community app. As a result we can keep development on it onlist with no risk of splitting the community or creating confusion about what is Mifos and what is Fineract. Yes. Agree that this is a good thing, we want to avoid this confusion. If you’ll look closely at the strangler pattern it assumes a gradual synchronized rewrite of the backend *and* the front end. That is not what has happened here. Right. I wish we had been more conscious of how to enable a transition/migration - the important thing is to not strand our community of users. If you wish to take that course yourself you’d need to do the following: * create a translator API — this would be “shaped” the same as the current Fineract 1.x api but implemented by calling Fineract CN where Fineract CN has the necessary functionality. * create an event mapper — for the bidirectional transport of data between new and old systems that Fowler describes. * create a data mapper — for the import of data from the old system to the new system (and probably back again). This would give you the ability to continue to use the Mifos community app over Fineract CN. Because Fineract CN doesn’t support all the functionality of Fineract 1.x, you would have to deploy both until it did. This kind of deployment will require a sophisticated and expensive Ops team of a dimension that not even Kuelap has. Perhaps there is some entity out there which has this? Perhaps... and I'd only suggest this for institutions w sufficient requirements that can only be met w such a hybrid system. Seems unlikely. Nonetheless thank you for outlining the approach required and how difficult it could be. I, personally, do not have the resources to help out in this sort of programming effort required either. I believe it’s far more effort, with worse results, than a simple data migration targeted at the specific use cases which can be covered by Fineract CN today. And I feel no responsibility for refactoring the Mifos community app which is not part of the Fineract code base. 1.x and CN can co-exist in the Fineract project whatever migration strategy we follow, including no migration at all. No migration means that we will have two separate communities. I believe that is not the way to go. Instead, the Fineract community needs to address - over an appropriate period of time - the way to move from gen2 to gen3. I believe the new code was accepted on the basis of one community vision and high level roadmap. In any case, we should focus on how to either maintain Fineract 1.x and Fineract-CN or to enable a migration path that works for enough of the community... If you do want to implement the strangler pattern though: I assume you are already familiar with the Fineract 1.x REST API. I suggest you start by looking at the feign APIs of the Fineract CN services. There’s a package called “api” in every service module which contains the REST interface, domain objects, and event constants for that service. I do believe still that my observation about API completeness and match w Fineract-1.* Is important. It's an easy way of confirming functional completeness. Is there a reason not to use the API in that way? Ok, I will start to look at the feign APIs and compare w existing Fineract 1.x. I hope I can figure that out. If someone else on list has already done so, please let me know! Data migrations may be another way of approaching the software migration issue, however I don't believe that will fully answer the questions about functional match, and some migration issues will only become visible through a regression testing involving the same APIs. Changing all three: front end, API layer, and data model simultaneously seems really difficult to me to get right. Right? Thanks James Best Regards, Myrle On Sat 10. Mar 2018 at 03:56 James Dailey <jamespdai...@gmail.com> wrote: > Hi Ed and Devs, > > This thread deserves some comment and attention. For many of the > participants, the core MifosX (now Fineract 1.x) platform is all that they > have known and a move to a different platform has all sorts of issues > associated with it. With Fineract-CN, a key idea was to respond to some of > the issues identified by implementers in the field - namely that the code > was insufficiently flexible and extensible. > > It is vital for the community to determine a path from Fineract 1.x to > Fineract-CN. > > My previous understanding, when Fineract-CN was first discussed, was that > the code was going to be starting as a refactoring of the existing Fineract > code. I vaguely understood it to be consistent with Martin Fowler's > Strangler Application. > https://www.martinfowler.com/bliki/StranglerApplication.html In this > article he lays out how to deal with a migration path from one monolithic > API driven application to a microservices application. "The fundamental > strategy is EventInterception > <https://www.martinfowler.com/bliki/EventInterception.html>, which can be > used to gradually move functionality to the strangler and to enable > AssetCapture <https://www.martinfowler.com/bliki/AssetCapture.html>." > > IBM has this later explanation on Fowler's concept: > > https://www.ibm.com/developerworks/cloud/library/cl-strangler-application- pattern-microservices-apps-trs/index.html > > > Why is this useful for Fineract1.x --> Fineract-CN? Well, first it points > to the idea that the Fineract API needs to be maintained from one > generation to the next As a guiding principle, this helps to define the > "surface area" for the development effort. Once the API is able to run (or > perhaps 95% of the API is a better target), then the effort can shift to > versioning of the API or some other concept involving public APIs, internal > APIs and composition of APIs. It implies that existing front ends need not > be migrated initially. > > The strangler application concept also suggests that the microservices > "creep in" and "take over gradually", implying that there should be a way > for the Fineract-CN to relate to the existing code. Perhaps we could look > at certain areas of the Fineract-CN code to replace existing services in > the Fineract1.x. > > Useful way to move forward? > > James > > On Wed, Feb 28, 2018 at 9:44 AM Ed Cable <edca...@mifos.org> wrote: > > > Now that the Fineract CN repositories are on the Apache Github, > stabilized, > > and proper build documentation is coming together, momentum is starting > to > > build. > > > > I wanted to raise on the mailing lists a question and concern I know is > at > > the back of the minds of many members of the Mifos and Fineract > > communities. > > > > *What is the migration path from Fineract to Fineract CN? * > > > > During the genesis of Generation 3 now Fineract CN, we made the > commitment > > to a migration path so I want the dialogue to happen early so we can > ensure > > that as Fineract CN evolves and matures, we have in place the tools, > > scripts, documentation to bridge the communities. > > > > Hundreds of institutions and millions of clients supported by partners > from > > around the world currently rely on Fineract but would greatly benefit > form > > this new architecture. > > > > I want our community to have this open discussion about what they > envision > > for an ideal migration path and what can be practically be implemented to > > achieve the best migration path possible. > > > > So let's use this thread and this wiki page at > > > > > https://cwiki.apache.org/confluence/display/FINERACT/ Migration+Path+from+Fineract+to+Fineract+CN > > to discuss: > > > > - Use cases for migration path > > - Proposed solutions for a migration path along with pros/cons of each > > > > Some outcomes I'd like to see: > > - Proposed Design & Approach > > - Timeline and Placement on our Roadmap > > - Identify Volunteers to Drive this Forward > > - Scope out as a Potential GSOC Project > > > > I look forward to the discussion! > > > > P.S. If they're reading, this might be a chance for the folks at Apache > POI > > to get involved! :) > > -- > > *Ed Cable* > > President/CEO, Mifos Initiative > > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649 > > <(484)%20477-8649> > > > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > >
