I have now configured my Eureka server and I can see all my micro-services there. But I have added extra key-value pairs, related to my micro-services, to the metadata-map of instances.
Is it possible to show these extra parameters in the Eureka dashboard?
To simply put it:
is there some way that I can modify what I see on the Eureka dashboard other than the standard parameters and standard layout?
Related
We need to use two differnet endpoints from aws amplify with datastore in flutter.
The documentation from aws uses an singleton for amplify, so we can only have one endpoint, or am i miss something?
We use this plugin: https://pub.dev/packages/amplify_datastore
Is there a way to use the two endpoints?
I tried two instances of the class AmplifyClass, but it does not work, I also just got one database file, so I think that way wont work.
I am developing monolithic applications since many years and want to try microservices and containers now.
For learning microservices and containers I am planning a small calendar application (as a web application), where you can create dates and invite others to them. I identified three services that I have to implement:
Authentication service -> handles login, gives back a JWT
UserData services -> handles registration, shows user data, handles edits of user data (profile picture, name, short description)
Calendar service -> for creating, editing and deleting dates, inviting others to dates, viewing dates and so on.
This is the part I feel confident about, but if I did already something wrong, please correct me.
Where I am not sure what to do is how to implement the database and frontend part.
Database
I never used Neo4j or any graphbased database before, but they seem to work well for this use case and I want to learn something new. Maybe my database choice may not be relevant here, but my question is:
Should every microservice have its own database or should they access the same database?
Some data sets are connected, like every date has a creator and multiple participants.
And should the database run in a container or should it be hosted on the server directly? (I want to self-host the database)
For storing profile pictures I decided to use a shared container volume, so multiple instances of a service can access the same files. But I never used containers before, so if you have a better idea, I am open to hear it.
Frontend
Should I build a single (monolithic) frontend application, or is it useful to build some kind of micro frontend, which contains only a navigation and loads other parts like the calendar view or user data view from the above defined services? And if yes, should I pack the UserData frontend and the UserData service into one container?
MVP
I want the whole application to be useable by others, so they can install it on their own servers/cloud. Is it possible to pack the whole application (all services and frontend) into one package and make it installable in kubernetes with a single step, but in a way, that each service still has its own container? In my head this sounds necessary, because the calendar service won’t work without the userdata service, because every date needs a user who creates it.
Additional optional services
Imagine I want to add some additional but optional features like real time chat. What is the best way to check if these features are installed? Should I add a management service which checks which services exist and tells the frontend which navigation links it should show, or should the frontend application ping all possible services to check if they are installed?
I know, these are many questions, but I think they are tied together, because choices on one part can influence others.
I am looking forward for your answers.
I'm further along than you but far from "microservice expert". But I'll try my best:
Should every microservice have its own database or should they access the same database?
The rule of thumb is that a microservice should have its own database. This decouples them, making it so that your contract between services is just the API. Furthermore it keeps the logic simpler within a service in that there's less types for data that your service is responsible for handling.
And should the database run in a container or should it be hosted on the server directly?
I'm not a fan of running a database in a container. In general, a database:
can consume a lot of resources (depending on the query)
sustains long-lived connections
is something you vertically scale, rather than horizontally
These qualities reflect a poor case for containerization, imho.
For storing profile pictures I decided to use a shared container volume
Nothing wrong with this, but using cloud storage like Amazon S3 is a popular move here, just so you don't have to manage the state of the volume. i.e. if the volume goes away, do you still want your pictures around?
Should I build a single (monolithic) frontend application?
I would say yes: this is would be the simplest approach. The other big motivation for microservices is to allow separate development teams to work independently. If that's not the case here, I think you should avoid yourself the headache for micro-frontends.
And if yes, should I pack the UserData frontend and the UserData service into one container?
I'm not sure I perfectly understand here. I think it's fine to have the frontend and backend service as part of the same codebase, which can get "deployed" together. How you want to serve the frontend is completely up to you and how it's implemented. Some like to serve it through a CDN to minimize latency, but I've never seen the need.
Is it possible to pack the whole application (all services and frontend) into one package and make it installable in kubernetes with a single step?
This is use-case for Helm charts: A package manager for kubernetes.
Imagine I want to add some additional but optional features like real time chat. What is the best way to check if these features are installed? Should I add a management service which checks which services exist and tells the frontend which navigation links it should show, or should the frontend application ping all possible services to check if they are installed?
There's a thin line between what you're describing and monitoring. If it were me, I'd pick the service that radiates this information and just set some booleans in a config file or something. That's because this state is isn't going to change until reinstall, so there's no need to check it on an interval.
--
Those were my thoughts but, as with all things architecture, there's no universal truth. Some times exceptions are warranted depending on your actual circumstances.
Reading from the documentation, the suggestion for passing values between CDK Stacks within an app is to simply pass the value.
If the two stacks are in the same AWS CDK app, just pass a reference between the two stacks. For example, save a reference to the resource's construct as an attribute of the defining stack (this.stack.uploadBucket = myBucket), then pass that attribute to the constructor of the stack that needs the resource.
But it seems this only works if the CDK stacks are within one account.
Upon checking the generated templates, it generates a stack Output and Input and uses that for the passing values. And stack input and outputs does not work beyond the account they are created on.
What's the recommended way to pass values from stacks deployed in different accounts?
I don't think you can think about this as being a single CDK application. Such a single application is intended to be deployed in a single account. What you are trying to do is use this application construct to deploy two different stacks in two different environments and share data between them. However, you are bound to the same restrictions that CloudFormation itself has when it comes to sharing data from services that have been deployed in the stack. So you'll have to work around this issue.
So I don't think there is any recommended way of doing this, but maybe you can create some cross-account roles that allow writing/reading from the SSM parameter store and combine this with custom resource lambdas to read/write the data from/in the SSM store of the other account. Given this, it might be easier to just write some CICD tooling that does this without needing any AWS services and which just passes on the value from the output of one stack to the input of the other stack during deployment.
I want to use the variants to customise different filter and table variants on a SAP Fiori application, that use SAP Hana Cloud and Java backend.
As a background info:
I'm using a smartTable that is connected to the smartFilter by filterId property. On the table/filter I am able to access directly the data from the metadata by filing the entitySet / entityType property. I am using a real server not a mock server. In the table the properties regarding the personalization and variants are enabled (useTablePersonalisation="true", useVariantManagement="true"). I see that I have to specify the persistencyKey so that variants can display on the UI, but i don't know what value should i complete it with.
I read that smartTable and smartFilter are using SmartVariantManagement(a custom control of VarinatManagement) to accessed directly (without user interaction) SAPUI5 Flexibility Services regarding personalization data and management of the variant. But on SAP Help it says that:
Flexibility services are currently not available in SAP Hana Cloud Platform.
The services run on the ABAP front-end server and NetWeaver 7.31 SP11 or higher
Here is the link: http://help.sap.com/saphelp_hanaplatform/helpdata/en/a8/e55aa2f8bc4127923b20685a6d1621/frameset.htm
It is possible to use the variants and personalization?
How can I do it regardind my application specification?
Does anyone have an example application?
Thank you !
You can use them both at the same time.
For me the useTablePersonalisation="true" is working without any other changes. Rearding the useVariantManagement="true", I use showVariantManagement="true" also, and as you said persistencyKey="SmartFilter_Explored" is also needed to see Variant Management icon.
This is an example: https://sapui5.hana.ondemand.com/explored.html#/sample/sap.ui.comp.sample.smarttable/preview
For me I can not test the variant management functionality when running the app from webide as it is needed an existing user for you. So I can test it only, when running it on launchpad.
PersistencyKey identifies the storage area and saves/retrieves the variants currently used.
This page helps you with persistency key (under Page Variant section):
https://sapui5.hana.ondemand.com/#/topic/06a4c3ac1cf545a7b51864e7f3aa02da
I hope it helped.
Can someone please point me to the right direction.
I need to be able to host my GWT application in a way that it allows multiple clients to use the same application which could be separated by url's but internally using the same application.
the different sites would probably be seperated by different configurations. eg. different database, different log path etc, etc,
any ideas.?
You could use the following way to arrange your projects :
- my.application.core.project : it holds all the business logic and views for the application except for the entry point
-my.application.customerX.project : it holds only the entry point and the property files used for having the connection to the db, probably customerX specific theme
-my.application.customerY.project : it holds only the entry point and the property files used for having the connection to the db, probably customerY specific theme
Such an organization of the projects would allow you to have a common core that is distributed to each of the customers and also the ability to build on top of the core customer-specific impelementations.
The url's per client can be done with URL rewriting. Be it with an apache server in front of your application and/or in combination with a Filter in your web application.
As for the configuration, logging, and/or database per client you want a solution that doesn't store a file per client on the file system next to your application. Preferable you store client specific settings in one database and have an admin interface to manage it. For the client's data you also don't want a separate database per client, because it doesn't scale well, and would be a maintenance mess if you need to upgrade your application and databases to a newer version. Look for a multitenant architecture.
I admit this is a vague answer, but without specific system and software descriptions it's kind of hard to give a concrete answer. Nevertheless I hope this answer does give you some direction.
I have successfully achieved this by setting up separate directories in tomcat for different clients and then creating soft-links to the main application within that folder. when it comes to database connection properties and other configuration properties, instead of pointing them to the main application I just created them separately.