fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <mkra...@mifos.org>
Subject Re: Microservices
Date Wed, 25 May 2016 11:26:03 GMT
In answer to Nayan's mail:

Our shared end goal is not a beautiful architecture.  Our shared goal is
also not to make any particular company financially successful.  Our goal
is to make it possible for those people who today have no access to banking
services to attain access to secure and timely savings and loans.  This is
the key to expanding economies and bridging financial hard times.  This is
the single most effective way to fight poverty!  I believe we are in
agreement here.

I loved the article from Joel you included.  The author has many valuable
points, but he unfortunately assumes that all rewrites are initiated to
cure code rot.  If that were true, then he would be right.  When I read
Joel's article the first time, roughly a year after it was written, I was
working on my first major software project: a successful rewrite of a major
feature.  Microsoft's main business model is based on finding successful
products, then re-writing them better.  Many successful Open Source
projects, including several at Apache, do the same.  After reading Joel's
article, I decided to think about what makes some rewrites more successful
than the examples Joel listed.

Here are some factors which can make a rewrite necessary:

* new platforms for a piece of software to run on.  new standards software
needs to conform to.  (Smart phones, cloud)
* new libraries available.  A rewrite can actually *increase* code reuse be
replacing hand-spun implementations.
* significant new use cases.  For example a massive increases in scale, or
features which could not have been foreseen at the time of the original
implementation.
* the skill set of programmers available for work on the project undergoes
a significant change.  For example, it is nearly impossible to find COBOL
programmers for old banking systems.
* anti-patterns have begun to self-propagate faster than they can be fixed,
making it impossible to expunge them from the code.  I loved Joel's
"FuckedString" example.  That sounds like this sort of problem.  This is
the only kind of code rot I would admit as a reason.  For everything else
you're right; fix it where you find it.

Here is what can make a rewrite successful:

* Continue releasing versions of the previous gen of a product or feature
while the rewrite begins.
* Don't duplicate all features.  To counter Joel's example: it would be
wasteful to reproduce support for Windows '95.
* Choose an architecture and technologies that are attractive to potential
contributors. (Especially important in an open source project.)
* Carefully choose which use cases to focus on when migrating deployments.
It may make sense to focus on use cases *not* well-covered by the previous
gen, thus giving both product generations space to live during the
transition.

Joel's first example is particularly telling (written in April of 2000).
Yes the Netscape rewrite was a company-destroying failure.  The first time
I read that article it was on Internet Explorer (major rearchitecting for
version 8 released March 2009).  This time I read it on Safari (first
release January 2003).  I'm writing this e-mail using Firefox (first
release November 2004).  Some of you may use Chrome (first release
September 2008).

Apparently rewriting a web browser is not quite the death sentence Joel
believes it to be.  I leave it as an exercise to the reader to imagine why
some of these rewrites are successful, applying the criteria listed above.

Here's how I would apply these generalizations to Fineract:

* new platforms: Microservices are the best architecture for a cloud-based
or hosted platform.  These are much less expensive then purchasing the
hardware yourself.
* new libraries: For saving commands, Markus and I have picked Cassandra.
This would obviate any need for caching (mentioned by Vishwas), because
Cassandra handles that naturally via its distributed architecture.  For
service discovery we've picked Eureka and Ribbon.  For java-based APIs to
talk to REST, we've chosen Feign.  (There are more details here that I'm
leaving out because this e-mail is getting too long.)  The transition to
Cassandra and asynchronous commands alone, should give us a huge
performance boost.
* significant new use cases.  Here most of what we are seeing is increases
in scale.

* continue releasing previous gen: we are all in agreement here.
* carefully choose which features to duplicate: Fineract has always focused
on loans.  I believe the next gen should start by focusing on savings.
* attractive architecture and technologies: I suspect a lot of devs out
there are interested in Microservices and the accompanying technologies
right now.
* choose use cases: This area still needs considerable work.

So that's all for this week.  You won't hear from me again till next
Monday.  I'll try to make the focus more educational in my next e-mail.
(Feel free to wish for a topic.)

Greets,
Myrle



*Myrle Krantz*
Solutions Architect
RɅĐɅЯ, The Mifos Initiative
mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
<http://facebook.com/mifos>  <http://www.twitter.com/mifos>


On Tue, May 24, 2016 at 11:22 AM, Nayan Ambali <nayan.ambali@gmail.com>
wrote:

> Resending as some of the members of fineract dev list have not received the
> email.
>
>
> Hi Keith and Mryle,
>
> I want to share my thoughts,
>
> Mryle, first thanks for the information you have shared, and Markus has
> made very convincing and impressive pitch for moving towards new
> architecture and new code base, video and audio quality should have been
> better, can't see the code samples :(
>
> my thoughts about re-writing any software. (not really mine, I have
> borrowed from uncle Bob and Joel Spolsky and I agree with them)
>
>    - Software architecture is not the end goal it is just means to achieve
>    the end goal.
>    - End goal is what user wants and that is good working features.
>    - It’s harder to read code than to write it
>    - When you throw away code and start from scratch, you are throwing away
>    all that knowledge. All those collected bug fixes. Years of programming
>    work.
>    - You are throwing away your market leadership. You are giving a gift of
>    two or three years to your competitors, and believe me, that is a *long*
>    time in software years.
>    - There should be continues effort to keep code clean and make it more
>    readable, cleaning even one line at time is also good thing, imagine a
> code
>    based that is becoming more readable as time passes.
>
> It is difficult choice between re-write or 'fix the current problems', if
> there is no solution to fix the current problems and if we have reached the
> end of the road then only we should go with re-writing approach.
>
> In this case I mostly agree with Jeol's opinion about software re-write,
> read
> it here <http://www.joelonsoftware.com/articles/fog0000000069.html> and I
> understand we can't generalize every situation and I am also not against
> moving to micro services if that solves my users problems :)
>
> I do not have any hands-on experience on micro services so no comments on
> it.
>
> Assumption: Moving to micro services requires lot of effort to re-writing
> and/or restructure existing modules source code as they are not modular and
> will not be as simple as plug these modules to new architecture.
>
> My suggestion: If we have decided to move forward re-writing the Mifos X on
> newer and/or better architecture then we have to make sure it should *not*
> impact ongoing bug fixing, support and new features and new releases of
> current product till we really have new product that is as better as
> current product interms of feature set otherwise it will push the product
> and specialists to back in market.
>
> + Mifos Dev list.
>
>
> Thanks
>
> Nayan Ambali
>
>
>
> On Fri, May 20, 2016 at 3:19 AM, Keith Woodlock <keithwoodlock@gmail.com>
> wrote:
>
> > Hi Mryle,
> >
> > Thanks for your detailed reply, I added my comments (please remember I am
> > not involved in code base for sometime so might be missing alot) below
> but
> > its a pretty long email so I summarise what I think here:
> >
> > The decision to move from one approach to developing a system to another
> is
> > a big one and not without its costs. I am not really for or against it
> and
> > I'll be interested in seeing how things turn out whichever way the
> > community decides to go. If everyone really feels it will be the solution
> > to any problems that exist then they should go for it. The risk of course
> > is that its a very tech solution to things.
> >
> > I think Chris Richardson does a good job on http://microservices.io of
> > outlining the differences between the monolith (
> > http://microservices.io/patterns/monolithic.html) and the microservices
> (
> > http://microservices.io/patterns/microservices.html) approaches.
> >
> > You probably have the following 3 directions you can go:
> >
> > 1) Stay with the monolith and attempt to tackle the problems you see with
> > the system (domain, performance etc)
> >
> > 2) Gradually move services from the monolith into microservices (hope it
> > solves the problems you see and doesnt introduce new problems)
> >
> > 3) Re-imagine the fineract platform from ground up again (hope it solves
> > the problems you see and doesnt introduce new problems)
> >
> > - Approach 2 sounds like it will be a drawn out affair and take a long
> time
> > to reach the end with the drawback of having to support both approaches
> >
> > - Approach 3 it too would be alot of effort but you could use something
> > like http://eventuate.io/ to get to a poof of concept faster
> >
> >
> >
> >
> > Before devling into some of the points you raised I wanted to highlight
> two
> > aspects of the fineract platform:
> >
> > *- Everything is exposed a HTTP API / Service*
> >
> > All the functionality that exists in the platform is or should be exposed
> > by a HTTP API. This HTTP API is a techonology agonistic contract that
> > developers can build their apps/clients on or integrate with easily.
> >
> > Developers can choose to build their apps/clients in any technology they
> > wish and to use as much or as little of the platform API in their app.
> >
> > API documented here https://demo.openmf.org/api-docs/apiLive.htm
> >
> > *- All HTTP API Endpoints deployed together*
> >
> > The code is compiled and bundled as a .war file that is deployed to an
> > application server like tomcat.
> >
> > If one application server isnt able to handle the request load you can
> > easily scale horizontally by adding more application servers (as the
> > platform is stateless) and load balance the requests between the
> serrvers.
> > This would typically only be needed in a larger scale deployment.
> >
> >
> > *The Problems You Listed*
> >
> >
> >
> >
> > *1.) We are starting to have performance problems.  Conflux in particular
> > is running into this.  Mussoni is starting to have problems too.  All of
> us
> > would like to move to bigger customers and bigger markets, so this will
> > only get worse.*
> >
> > You should open up a new email thread within the community on these
> issues.
> >
> > It would be useful to provide some more details on what API requests in
> > praticular Conflux/Musoni and others are seeing performance problems
> with.
> >
> >
> > *2.) As we move to bigger customers, down-time becomes less and less
> > acceptable.*
> >
> > There shouldnt need to be a need for downtime with the existing
> > deploy-all-services-as-one approach.
> >
> > On tomcat you can deploy your new application in parallel with your old
> > one.
> >
> >
> >
> >
> >
> >
> > *3.) Loans products are hard-coded.  A lot of dev list mails read like
> this
> > “For my case, I want my interest/fees calculated at a different time/ on
> a
> > different basis than the ‘standard’ use case, how do I do this?”  If I
> were
> > a customer asking a question like this, some of the hacks being suggested
> > would feel brittle and unsatisfying.  Savings products look like they
> were
> > implemented as an afterthought and are also hard-coded.*
> >
> > Sounds likes a domain modelling / requirements issue or an implementation
> > issue.
> >
> > Different financial institutions in different countries have many
> different
> > flavours of the way they want their loan or saving products to work and
> its
> > an area that will continue to change into the future.
> >
> > Mifos started out with supporting one or two of the common models in use
> in
> > the field and it looks like more have been added in since based on
> content
> > in http://fineract.incubator.apache.org/
> >
> > You might be suggesting though that its time to revisit the Loan Product
> /
> > Loan area and re-model it based on what you know today?
> >
> >
> >
> >
> >
> >
> > *4.) Our adherence to the CQRS pattern is less than perfect.  Command
> > responses were hard coded.  Some work has been done to make proper
> command
> > handlers out of it, but there are still semi-commands handled in a big if
> > else block.  Handling commands is synchronous even though one of the
> > advantages of this pattern should be the ability to handle operations
> > asynchronously.  This contributes to the problems mentioned in 1 above.*
> >
> > Not sure what the hard-coded command response area is (been along time
> > since looked at code base)
> >
> > Its true that code that is responsible for identifying what command
> handler
> > to invoke based on the command is not great and suffered from the 'god
> > class' problems - the inital core of the platform was written in a
> > time-boxed three month period as proof of concept and as more
> apis/commands
> > got added it got bigger.
> >
> > That said, if you have a preferred solution its surely an area that could
> > of been improved in the last few years if it was that important?
> >
> > On the synchronous nature of them, yes we decided rather than going for
> an
> > eventually-consistent system that the api calls would be like a
> datatabase
> > transaction call, i.e when you get a response you know its either
> > successful or not
> >
> > Calling an api 1000's of times to do something in bulk of course would
> not
> > make much sense and you would expect to add a bulk api for the that type
> of
> > activity.
> >
> > Also if there are very long running tasks then of course they should not
> be
> > done through a synchronous api call, you should set up an api that
> supports
> > 'long running tasks' and pass back a id/key that the user can use to
> check
> > for the result later or something similiar.
> >
> >
> >
> >
> > *5.) There’s currently no standard way to connect to what I like to call
> > “money buses” (Swift, Stellar, UPI).  I did implement a bridge for
> Stellar
> > which listened for commands, but it wasn’t clear which commands to listen
> > for.  I ended up deciding on journal entries.*
> >
> > Not fully across what you are doing here but if its a case of integrating
> > some kind of third party payments api and invoking it based on some api
> > call like makePayment or disburse then that should be catered for by the
> > platform. If you werent clear on how to do its probably cause the
> platform
> > didnt try to support that type of integration out of the box first of
> all.
> >
> > Listening to journal entries might not be the best idea cause what If i
> > dont want to use the platforms accounting solution and turn it off?
> >
> > This use case should be designed into the praticular area in question.
> >
> >
> >
> >
> > *6.) In first world core banking systems, the back end and the front end
> > are carefully separated with clearly defined and limited communication.
> > This is to provide added protection against hacking of the type we’ve
> seen
> > in the news recently (Bangladesh’s central bank for example).*
> >
> > The front end (apps/clients) are totaly seperated from the back-end api
> at
> > present. In terms of limiting what apps can speak to what APIs, you
> > probably need to add that capability on top of the current
> > authentication/authorization capablity.
> >
> > At present there is fine-grained support for restricting what apis a user
> > is entitled to call, its not to much more to also limit what apis can be
> > called based on what app/client is being used.
> >
> > *How these things related to microservices pionts*
> >
> >
> >
> >
> >
> >
> > *1.) By chopping up database accesses into logical units, we can increase
> > capacity for only those units which need it.  This reduces costs.  In
> > particular, for the saving and reading of commands (for which we expect
> the
> > largest volume of write instructions), we can switch to a faster
> > persistence mechanism which works better in a distributed environment.*
> >
> > Your probably talking about switching to storing the commands/events in a
> > different persistence mechanism than a relational database. You could
> > choose to do that now if you wish.
> >
> > You might also be referring to breaking the current database schema into
> a
> > database per service approach (
> http://microservices.io/patterns/index.html
> > ).
> >
> >
> > I am not sure how this would reduce costs. Like any solution it has its
> > pros and cons (
> > http://microservices.io/patterns/data/database-per-service.html)
> >
> >
> >
> > *2.) We can run multiple instances of a microservice, and, with careful
> > design, perform rolling updates, moving us towards the ability to have
> > 99.99% uptime.*
> >
> > Much like point 2 earlier,  you should be able to do this with the
> current
> > setup.
> >
> >
> >
> >
> >
> > *3.) A more modular approach with well-defined APIs would make it
> possible
> > among other things to separate out the loans and savings products and let
> > anyone implement their own loans and savings products who wants to.
> Things
> > like interest rates, fees, and repayments rates are very cultural, and as
> > we move into more countries we’ll need more flexibility here.*
> >
> > There should be well defined APIs at present. If you have a solution for
> > allowing people to create their own loans and savings products with
> > complete flexibiliy you should be able to roll it out now in the current
> > setup.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *4.) CQRS is a truly awesome pattern for this domain, partly because it
> in
> > theory, makes it possible to handle writes asynchronously.  If we can
> > decouple the commands for different domains from each other and actually
> > handle them asynchronously that would be a major step forward.  Of course
> > this doesn’t necessitate a microservices deployment model, at least not
> > until the question of what we do with the data we create while handling
> the
> > commands.  If, for example, a command for creating a user causes
> different
> > data to be adjusted then a command for starting a payment, why should
> > creating a user cause a slowdown in working through payments?  Those two
> > kinds of processing don’t even have to execute on the same hardware...*
> >
> > As you say, if you want to implement a more fully blown implementation of
> > the CQRS+Event Sourcing pattern you could implement that now for the
> areas
> > your believe need it and still respect the existing API
> >
> > The example you given isnt a good one as you wouldnt expect there to be a
> > high throughput of users created but I understand that your saying that
> if
> > there was 'intensive' operations going on on the platform, it might be
> > usefult to be able to split them into a seperate unit that runs on
> seperate
> > hardware so it doesnt impact more important functionality that might have
> > an SLA on it like payment processing etc
> >
> > The question is, what are these intensive operations that might be
> > affecting other areas of the platform so badly?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *5.) Writing ‘money bus’ plugins as microservices is a great way to
> > separate functionality and be sure that even if one bus is down, the
> others
> > can still be up and running.  My stellar bridge component essentially
> > applied this pattern.  If we can standardize the interface that bridge
> > components implement, we could make these easier to write and improve
> Mifos
> > connectivity to other systems.  These don’t need to be a standard part of
> > deployment, in different countries, different networks are popular, and
> > these things change over time too.  Connectivity to other systems is, in
> my
> > humble opinion, one of the most important factors in the success of a
> > product.*
> >
> > Yes its very important to be able to integrate with other systems and I
> > dont see why the kind of functionality you want to implement and
> integrate
> > into mifos/fineract cant be done today in a clean way. I dont see how
> > having all the current services split out into deployable units helps
> this
> > use case.
> >
> >
> >
> >
> >
> >
> >
> >
> > *6.) Separation of core systems from customer-visible systems will
> require
> > a duplication of some functionality.  This functionality would need to
> run
> > in separate processes and only have access to data duplicated out of the
> > back end system.  Most data would only flow from back to front (probably
> > via some kind of ETL process).  If we divvy up our data based on the
> > functionality groups which need it, it will be much easier to determine
> > which data should be copied “forward” and which should “stay behind”.  A
> > microservice is such a functionality group.*
> >
> > Its probably not a good idea to mix customer-visble functionality with
> core
> > business-functionality. It terms of large financial institutions you
> would
> > be talking about 100,000s to millions of potentional users for customer
> > visible functionality whilst the core business-functionality would be
> > significantly less.
> >
> > So they really are two different systems at some level.
> >
> > regards,
> > Keith.
> >
> >
> > On Thu, May 19, 2016 at 2:07 PM, Myrle Krantz <mkrantz@mifos.org> wrote:
> >
> > > This is a big topic, and I’m trying to decide if I should chop it up
> into
> > > multiple threads.  I’m going to leave it as one for now, since I
> detect a
> > > healthy scepticism about the question of whether we need to do this at
> > all,
> > > and I don’t want to preclude that discussion.  Here are some of the
> > > problems I’m seeing:
> > >
> > > 1.) We are starting to have performance problems.  Conflux in
> particular
> > is
> > > running into this.  Mussoni is starting to have problems too.  All of
> us
> > > would like to move to bigger customers and bigger markets, so this will
> > > only get worse.
> > > 2.) As we move to bigger customers, down-time becomes less and less
> > > acceptable.
> > > 3.) Loans products are hard-coded.  A lot of dev list mails read like
> > this
> > > “For my case, I want my interest/fees calculated at a different time/
> on
> > a
> > > different basis than the ‘standard’ use case, how do I do this?”  If
I
> > were
> > > a customer asking a question like this, some of the hacks being
> suggested
> > > would feel brittle and unsatisfying.  Savings products look like they
> > were
> > > implemented as an afterthought and are also hard-coded.
> > > 4.) Our adherence to the CQRS pattern is less than perfect.  Command
> > > responses were hard coded.  Some work has been done to make proper
> > command
> > > handlers out of it, but there are still semi-commands handled in a big
> if
> > > else block.  Handling commands is synchronous even though one of the
> > > advantages of this pattern should be the ability to handle operations
> > > asynchronously.  This contributes to the problems mentioned in 1 above.
> > > 5.) There’s currently no standard way to connect to what I like to call
> > > “money buses” (Swift, Stellar, UPI).  I did implement a bridge for
> > Stellar
> > > which listened for commands, but it wasn’t clear which commands to
> listen
> > > for.  I ended up deciding on journal entries.
> > > 6.) In first world core banking systems, the back end and the front end
> > are
> > > carefully separated with clearly defined and limited communication.
> This
> > > is to provide added protection against hacking of the type we’ve seen
> in
> > > the news recently (Bangladesh’s central bank for example).
> > >
> > > So how does this relate to Microservices?  From here on out, I’m going
> to
> > > assume you all know what a Microservice is, so I hope you read those
> > links
> > > in my original e-mail : o).
> > >
> > > 1.) By chopping up database accesses into logical units, we can
> increase
> > > capacity for only those units which need it.  This reduces costs.  In
> > > particular, for the saving and reading of commands (for which we expect
> > the
> > > largest volume of write instructions), we can switch to a faster
> > > persistence mechanism which works better in a distributed environment.
> > > 2.) We can run multiple instances of a microservice, and, with careful
> > > design, perform rolling updates, moving us towards the ability to have
> > > 99.99% uptime.
> > > 3.) A more modular approach with well-defined APIs would make it
> possible
> > > among other things to separate out the loans and savings products and
> let
> > > anyone implement their own loans and savings products who wants to.
> > Things
> > > like interest rates, fees, and repayments rates are very cultural, and
> as
> > > we move into more countries we’ll need more flexibility here.
> > > 4.) CQRS is a truly awesome pattern for this domain, partly because it
> in
> > > theory, makes it possible to handle writes asynchronously.  If we can
> > > decouple the commands for different domains from each other and
> actually
> > > handle them asynchronously that would be a major step forward.  Of
> course
> > > this doesn’t necessitate a microservices deployment model, at least not
> > > until the question of what we do with the data we create while handling
> > the
> > > commands.  If, for example, a command for creating a user causes
> > different
> > > data to be adjusted then a command for starting a payment, why should
> > > creating a user cause a slowdown in working through payments?  Those
> two
> > > kinds of processing don’t even have to execute on the same hardware...
> > > 5.) Writing ‘money bus’ plugins as microservices is a great way to
> > separate
> > > functionality and be sure that even if one bus is down, the others can
> > > still be up and running.  My stellar bridge component essentially
> applied
> > > this pattern.  If we can standardize the interface that bridge
> components
> > > implement, we could make these easier to write and improve Mifos
> > > connectivity to other systems.  These don’t need to be a standard part
> of
> > > deployment, in different countries, different networks are popular, and
> > > these things change over time too.  Connectivity to other systems is,
> in
> > my
> > > humble opinion, one of the most important factors in the success of a
> > > product.
> > > 6.) Separation of core systems from customer-visible systems will
> > require a
> > > duplication of some functionality.  This functionality would need to
> run
> > in
> > > separate processes and only have access to data duplicated out of the
> > back
> > > end system.  Most data would only flow from back to front (probably via
> > > some kind of ETL process).  If we divvy up our data based on the
> > > functionality groups which need it, it will be much easier to determine
> > > which data should be copied “forward” and which should “stay behind”.
> A
> > > microservice is such a functionality group.
> > >
> > > There are other advantages to microservices that are more general in
> > nature
> > > and not specific to our use case; read the links I sent in my first
> > e-mail
> > > and you should start to get a feel for it.
> > >
> > > (Roman, I’m going to watch and see if your questions are answered as we
> > > discuss.  If not I’ll circle back to them, and see what was missed.)
> > >
> > > Greets,
> > > Myrle
> > >
> > >
> > > *Myrle Krantz*
> > > Solutions Architect
> > > RɅĐɅЯ, The Mifos Initiative
> > > mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
> > > <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
> > >
> > >
> > > On Thu, May 19, 2016 at 1:01 AM, Keith Woodlock <
> keithwoodlock@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Myrle,
> > > >
> > > > First off, thanks for starting a conversation around this within the
> > > > fineract dev community. I was wondering when this was going to come
> up.
> > > >
> > > > Rather than delving into the technicalities of what a microservice is
> > and
> > > > isnt I thought it would be good if the people proposing this could go
> > > into
> > > > a bit of detail here of why they are proposing it, the pros and cons
> > of a
> > > > microservice approach over the existing approach and the existing
> > > problems
> > > > within fineract/mifos that it will help solve/remove.
> > > >
> > > > I think that could promote some good discussion and following on from
> > > that
> > > > later we could delve into how it could be achieved if going that
> > > direction.
> > > >
> > > > regards,
> > > > Keith.
> > > >
> > > >
> > > > On Wed, May 18, 2016 at 11:14 PM, Roman Shaposhnik <
> > roman@shaposhnik.org
> > > >
> > > > wrote:
> > > >
> > > > > Hi Myrle,
> > > > >
> > > > > microservices are indeed a nice architectural pattern with an
> > > > exponentially
> > > > > growing adoption in the enterprise. It typically leverages some
> kind
> > > of a
> > > > > PaaS
> > > > > solution to be available for deployment. My current understanding
> is
> > > that
> > > > > your
> > > > > deployment model today is a traditional appserver. Are you going
to
> > > > change
> > > > > that?
> > > > > If so, what will be the deployment requirements for the project?
> > > > >
> > > > > Thanks,
> > > > > Roman.
> > > > >
> > > > > On Wed, May 18, 2016 at 2:35 AM, Myrle Krantz <mkrantz@mifos.org>
> > > wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > As many of you know Markus and I are thinking through a
> > > rearchitecting
> > > > of
> > > > > > Fineract into microservices. Markus gave some of you a preview
> into
> > > our
> > > > > > work at the Mifos tech conference in Amsterdam in March (those
of
> > you
> > > > who
> > > > > > are interested and weren’t able to attend can check it out
on
> > Youtube
> > > > > here:
> > > > > > https://www.youtube.com/watch?v=iIrnZpoNZ9A -- my apologies
for
> > the
> > > > poor
> > > > > > video quality)
> > > > > >
> > > > > > If you want to get an introductory understanding of what a
> > > microservice
> > > > > is,
> > > > > > this is a good place to go:
> > > > > >
> > > > > > http://martinfowler.com/articles/microservices.html
> > > > > >
> > > > > > If there is interest, (and I have time), I’ll try to send
you
> more
> > > > > > information about my ideas as they take shape.
> > > > > >
> > > > > > Greets,
> > > > > >
> > > > > > Myrle
> > > > > >
> > > > > > P.S.  Here’s Spring’s take on this:
> > > > > > https://spring.io/blog/2015/07/14/microservices-with-spring
> > > > > >
> > > > > >
> > > > > > *Myrle Krantz*
> > > > > > Solutions Architect
> > > > > > RɅĐɅЯ, The Mifos Initiative
> > > > > > mkrantz@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
> > > > > > <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message