++1
> On May 31, 2016, at 1:21 AM, Adi Raju <adi.r...@confluxtechnologies.com>
> wrote:
>
> I would expect there would be X number of microservices which are core/heart
> of the application which no deployment can do away with. I would suggest
> these to be rele
> <adi.r...@confluxtechnologies.com> wrote:
> > My thought would be to keep core microservices as single repo and single
> release.
>
> FWIW: that'd be my preference as well.
>
> Thanks,
> Roman.
>
On Tue, May 31, 2016 at 6:51 AM, Adi Raju
<adi.r...@confluxtechnologies.com> wrote:
> My thought would be to keep core microservices as single repo and single
> release.
FWIW: that'd be my preference as well.
Thanks,
Roman.
My thought would be to keep core microservices as single repo and single
release.
Regards,
Adi
-Original Message-
From: Myrle Krantz [mailto:mkra...@mifos.org]
Sent: 31 May 2016 18:54
To: dev@fineract.incubator.apache.org
Subject: Re: Microservices release question
Adi,
I like your
Adi,
I like your approach. So within the core set of microservices, we'd take
solution 2 right?
Greets,
Myrle
*Myrle Krantz*
Solutions Architect
RɅĐɅЯ, The Mifos Initiative
mkra...@mifos.org | Skype: mkrantz.mifos.org | http://mifos.org
<http://facebook.com/mifos> <http://www.tw
I would expect there would be X number of microservices which are core/heart of
the application which no deployment can do away with. I would suggest these to
be released as a single package/release.
All other microservices should be optional based on the deployment/end user
requirements
installing a valid certificate for their domain in their docker
image easy.
The answer to that question for larger organisations who want to take
advantage of the scalability that microservices offer, particularly ones
which wish to adjust the code before deploying it in their environments
Hi Fineract,
I'm starting a new thread for a question which Roman asked in the multiple
repos thread. He asked how we'd like to release if we are dividing our
code into microservices. Assuming we want to do clockwork releases, there
are three major alternatives:
1.) Release each microservice
h 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
to the end user.
Hope this helps a bit.
Best,
Markus
.::YAGNI likes a DRY KISS::.
> Date: Tue, 24 May 2016 19:41:28 -0700
> Subject: Re: Microservices
> From: vish...@confluxtechnologies.com
> To: dev@fineract.incubator.apache.org
>
>
> .::YAGNI likes a DRY KISS::.
>
>
>
> > Date: Tue, 24 May 2016 10:23:56 +0100
> > Subject: Re: Microservices
> > From: keithwoodl...@gmail.com
> > To: dev@fineract.incubator.apache.org
> >
> > Myrle,
> >
> &g
. For this we will keep
the implementation free from any new concept we are thinking about.
Best,
Markus
.::YAGNI likes a DRY KISS::.
> Date: Tue, 24 May 2016 10:23:56 +0100
> Subject: Re: Microservices
> From: keithwoodl...@gmail.com
n follow along.
> > >
> > > Given your are going to go ahead with developing a proof of concept
> > > starting from a blank canvas it might be good to layout a scope and
> some
> > > goals to get to in a time-boxed period of time. I would suggest
> something
> > &
ment related capabilities
> >
> > The emphasis on this would be to show off the tech approach/pattern
> > involved in implementing a microservice over the domain of the
> microservice
> > so feel free to choose a simpler area
> >
> > This hopefully could be provided i
gs.
>
> 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.
>
>
l Loan Product / Loan area of
Fineract
Makes sense to takcle the meat of the platform to show off qualities of
microservices approach
By the end of this you will have two microservice examples and that will
bring up the questions around deployment and service discovery and how that
will be imple
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://micr
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
, 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
delve into how it could be achieved if going that direction.
regards,
Keith.
On Wed, May 18, 2016 at 11:14 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> Hi Myrle,
>
> microservices are indeed a nice architectural pattern with an exponentially
> growing adoption
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
Myrle,
Microservices seems to be one of the big popular themes at OSCON this year
- Drew and I are going to attend some sessions to get up to speed from a
layperson's view :)
http://conferences.oreilly.com/oscon/open-source-us/public/schedule/grid/public/2016-05-18
<https://web.chilipiper.
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
23 matches
Mail list logo
