Hey James, hope this finds you well. (;
A few words about the current way the architecture is build. To be free of any container orchestration solution we use Netflix Eureka to register and discover microservices internally. Every microservice offers an API with a dedicated name including the version. To use your example, the customer and the accounting service both offer API classes registered with 'customer-v1' and 'accounting-v1'. Eureka takes care of all requests being routed to proper instance. The restriction for any services to be shaped differently is to keep this API and replace the underlying implementation as needed. All services are following the twelve-factor app methodology so we treat all dependencies (data stores, other services) as attached resources. In addition all services running on a containers of the same sort, e.g. customer, accounting, can be bundled in a service provided by the container orchestration. This allows the container orchestration to observe and scale based on the patterns used by it. At the end this can be any container technology, Docker, Rkt, or Garden. It was our purpose to build a microservice framework not imposing how you run it. You can still use all microservices without containers and call them using the RESTful interface, or place them in a docker container managing it yourself, or use Kubernetes, Cloud Foundry, OpenShift, or Nomad. Our approach follows a domain driven pattern. Every microservice 'reigns' over one specific domain within the overall architecture. Saying this, the customer service is responsible for customer related information (details about the person, id cards). If the accounting service would need some customer information it internally would call the customer service using it's API. This approach also allows the use of circuit breakers where useful, to prevent a caller from reaching an unknown state. To be a little be more specific I will enhance your sample by introducing deposit accounts. Deposit account management allows for the creation of specific deposit based products, e.g. Shares, Savings, and Checking. So the domain here is the management of a deposit products, and the assignment of this product to a customer. It's not part of the domain of that service to care about account and customer management, so it utilizes other services to do so. It does this by using the API of both services, so it becomes some sort of an orchestrator for this very specific use case. But it is not part of that service to manage any of the used services, it is only using them. So every service is in service to the overall financial provider domain. But some of them have a API based dependency to others. (; Saying this, we provide a set of services to allow a provider to build a solution as part of her value proposition. We don't impose any deployment to allow free choice of the tools she knows and uses. We are not providing the whole chain from source code to containers to orchestration to deployment, this is as mentioned part of the value proposition of the provider. All we provide is the code for microservices that allows her to create a deployment based and what she believes is best for her solution and customers. Cheers Markus .::Yagni likes a DRY KISS::. On Thu, Oct 12, 2017 at 10:21 PM James Dailey <[email protected]> wrote: > Hi - > > Some "thinking out loud" here.. I posed a question at the Mifos (just prior > to Fineract launch) meeting in Feb 2016 about the use of containerized > microservices - i.e. the use of different containers for each microservice > or collection of microservices and how they relate to each other. I don't > recall the answer but as a concept, there is this explanation on the > fineract site: > Containerization > > The patterns and specific implementation used allow the containerization of > any service provided by the framework. Because the bounded context provides > a clean distinction between services, an available API supports seamless > integration. Because of the stateless nature of every service, it is > possible and preferable to run each service in an isolated unit. > > We are achieving high availability, ephemeral behavior, and scalability by > utilizing containers and the ability to start and stop additional instances > fast and without side effects to other services. > > ( > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73634331 > ) > > --- > > but how does this actually work in implementation? Is there an > orchestration of microservices by a higher level container? For an > analogy, please see this post about the Kubernetes stack > https://thenewstack.io/introducing-microservices-hierarchy-needs/ . > > Does Fineract have a hierarchical approach or philosophy? How would it be > articulated? Would it be by *role of the microservice* in the service of a > larger architectural aim? e.g. customer management in service of account > management ? Or perhaps customer management in service to overall > financial provider domain? I suppose it is somewhat clear that with a > microservices architecture you have flexibility in how one relates them in > new and novel ways - more like the building blocks of a financial system > that can be put together in new and novel ways. But, I think this needs > some clarity - what is the limit of the flexibility? We know there are > trade offs - what will not be tolerated? > > Perhaps we should think about the namespace conventions as a way to address > this? or ? > > Thanks! > > James >
