We're developing an Azure IoT solution where each customer might have 5-15 devices and, in a year or two, we could easily have 500-1000 customers. We're having some debate on whether we want to assign a distinct hub for each customer or put as many customers as we think we can on each hub. There are pros and cons for each approach. Is there a best practice approach for determining this?
I suspect the pricing for Azure IoT Hubs would push you to share hubs across customers with that few devices; i.e. an S1 hub w/ 1 unit is $50/month. Multiplied by your 500-1K customers it's going to get very expensive to have hub/customer. It also depends on what those devices are doing - if they are hitting throttling limits (as stated above already) you'll need to add either units, go up a SKU, or add additional hubs.
https://azure.microsoft.com/en-us/pricing/details/iot-hub/
Related
We are evaluating a chat solution for a system we are developing. Twilio Conversations is our preferred option, as we also plan to use video. Our requirement seems to be a bit atypical of most solutions, and we are trying to determine the best architecture.
The solution is for a healthcare provider. Patients will be able to chat, via a mobile app, to a number of teams in the clinic, who will converse via a web app. Clinic staff can belong to several Teams. Chats can be initiated at both sides.
We are trying to determine the best architecture for Team members. Chat responses should come from the team, not an individualand any team member should be able to continue a conversation.
So, do we have one chat user per team? This seems to make sense, except a Team member could be in several teams, so we would need to handle multiple identities.
Or do we create a group comprising each team member plus the patient? This doesn't seem the rightr approach. We would need to hide the individual user identities, keep responses in sync using horizons, and I doubt would scale well?
I'm surpised this isn't a common scenario, so was wondering if there ws a recommended architecture? Thx
Hello to all the community. Within the Metatrader platform, there is a way to create accounts once the desired broker has been selected. My problem arises when I want to automate this process from code. From my search on the internet I understand that the solution could be using the .crv / .dat files, from within the config folder where said platform is installed, which contain the necessary information. But unfortunately it hasn't worked for me because I don't even know how to read them.
Specifically, I would like to know if there is any API that allows me to carry out the explained process (account management), as well as consult information (account balance, trades ...) which is also shown on the platform. Currently I am only interested in demo type accounts.
The closest solution I've found is using this API, but it's not free and also doesn't work for all brokers.
There is basically no solution to register demo accounts for any broker this way as not all brokers support registering demo accounts via MT terminal.
If a broker allows creating demo accounts via MT terminal, then it is also possible to register a demo account via MetaApi MT account management api.
For most applications the revenue application owner will earn per demo MT account is much higher than a fee MetaApi charges for API use, thus the fee just makes sense. It allows the MetaApi team to continue working on the project while not reducing application owner earnings significantly.
However if your application is low margin then you might want to automate it yourself. In this case you will also need to spend either time or money or both to implement your own solution.
As part of our journey towards API-led Connectivity, we have to group our resources (i.e. API endpoints) into multiple Mule applications for the experience APIs.
In order to have meaningful names for the Mule applications while maintaining the maximum re-usability, rather than associating the consumer names with the application names (which makes the experience API tightly coupled with the current application landscape), we propose to have Mule application names to reflect the essence of the business.
The list of the options are as follows. Which one do you think is more ideal? What approach have you used in your organization?
based on Channel/Consumer
A dedicated experience API for a consumer such as WEB, CRM, Mobile etc.
uri examples:
www.example.com/example-**web**-application/v1/
www.example.com/example-**crm**-application/v1/
www.example.com/example-**mobile**-application/v1/
Pro's: - applying channel specific policies is easier, management becomes easier, smaller outage window
Con's: - reusability reduces and chances of duplication of objects across api's increases
based on Business Domain
Company data model is used. Eg - Customer, Product, Payment etc.
uri examples:
www.example.com/example-**customers**-application/v1/
www.example.com/example-**products**-application/v1/
www.example.com/example-**payments**-application/v1/
Pro's: - promotes reusability, channel agnostic, same api can be used across different consumers.
Con's: management might get complex, larger outage window, multiple consumers might be impacted
based on Customer Journey
This approach is tied to the customer's lifecycle with the organization. Eg - Prospective Customer --> Lead --> Engage --> Payments --> Customer Retain
uri examples:
www.example.com/example-**prospect**-application/v1/
www.example.com/example-**lead**-application/v1/
www.example.com/example-**engage**-application/v1/
Pro's: channel agnostic, same api can be used across different consumers.
Con's: can get increasingly big and further breakdown might still be required
Thanks.
As far I understand your question; you would like to know what URIs to be using for the endpoints of the experience APIs, right?
Based on a recent blog entry from mulesoft (July 12 2017).
Experience APIs are:
Experience APIs are the means by which data can be
reconfigured so that it is most easily consumed by its intended
audience, all from a common data source, rather than setting up
separate point-to-point integrations for each channel. An Experience
API is usually created with API-first design principles where the API
is designed for the specific user experience in mind.
Based on the examples from MuleSoft and my understanding, the experience APIs are created for one given "experience"; web, virtual reality, mobile, etc...
You are trying to create an API for a given special experience to make the consumption of the API easy for this specific client.
According to my understanding the main goal on this level is not the re-usability. You focus on re-usability on the System API and Process API level, but the Experience APIs are supposed to make the life of the developers of the different clients easier by providing exactly the interface and data they need so they don't have to communicate directly with the system and process APIs, but they get a tailor-made API, suiting exactly their special needs.
Since the experience API is tailor-made for the special experience / channel / client-application; I think respresenting this in the URI is a good idea.
In short: What are the limits of both cloud projects and service accounts per project? How can they be increased? Is the architecture a good idea at all?
I am developing an IoT application with tens of thousands of planned devices in the field, having a few devices per customer and hundreds of customers. Every device will continuously (24/7) stream measurement data directly to BigQuery with one dataset (or table) per device at sample rates of at least 100Hz.
Of course, every device needs to be authenticated and authorized to gain tightly restricted access to its cloud dataset. As stated in the Auth Guide API keys are not very secure. Therefore, the most appropriate solutions seems to have one service account per customer with one account key per device (as suggested in this GCP article). However, the FAQs of Cloud IAM state that the number of service accounts is limited to 100 per project.
This limit could be reached quickly. If so, how easily/costly is it to increase this limit towards thousands or tens of thousands of service accounts per project?
In such a scenario also the number of needed projects could easily grow to hundreds or thousands. Would this be feasible?
Is this overall concept practical or are there better approaches within GCP?
I'm looking for a stockbroker but can't seem to find one that 'ticks all the right boxes' - can anyone help please?!
The essential requirements are:
Supports Shares ISA accounts
Access to ETFs on the LSE, especially iShares
Real-time price info/trading (with as low latency as possible)
Low fees/charges (preferably with a heavy discount for say 10+ trades per week)
Available to individuals, not just institutions
Execution-only is fine, don't need anything fancy. The ISA requirement probably restricts it to UK brokers I guess. There are loads of brokers that do all of the above, so then it comes down to my key additional requirement:
API access, e.g. FIX (for automated/algorithmic trading)
But I can't find any brokers that have both ISA support and API access. I guess it mustn't be a common requirement for individual investors in the UK but it seems commonly available from US brokers. I can probably live without API access if I really have to. (As long as there's a web interface, which they all seem to do nowadays. And I have no requirement for desktop/mobile trading platform software.)
My 'would really like but can be flexible on' requirements are:
Existing (open source/cheap) connector for Marketcetera or similar
Real-time level 2 price info at a reasonable price
DMA (Direct Market Access) on the LSE at a reasonable price (preferably without a massive 'professional client' process to have to go through)
Then the optional/'nice to have's are:
Demo/'monopoly money' account for testing
Ultra low latency pricing/trades
Can switch into CFDs/spreadbetting
Also supports SIPPs
So, does anyone know of any brokers that meet some/all these requirements?
The cheapest ones I've found that meet my essential requirements are x-o.co.uk and hl.co.uk, both currently charging £5.95. There's also share.com whose Premium account might be useful in the future but rather pricey up front - £3000 per year for unlimited trades with no other major charges. E*TRADE might have done the job but they're no longer trading in the UK. Interactive Brokers seems to be the only choice for API access in the UK (?) but they don't support ISAs. (They've said "After reviewing this we have decided not to support ISA's at this time." so it won't happen anytime soon.) There are some nice-looking platforms like Marketcetera/JBookTrader/tradelink/ActiveQuant - but if they can't connect to a broker that does ISAs they're skuppered for my purposes.
And some additional questions while I'm thinking:
Anyone know how much latency there actually is on a normal UK retail broker's web interface's "real-time" prices/trades?
Are stock prices pretty much the same across different brokers? I read in a review somewhere that one broker didn't offer as good a stock prices as others?! Is this down to the RSPs they use maybe?
Is it even possible to get DMA on the LSE at a reasonable price without a massive 'professional client' process to have to go through?
It seems that IG brokers may have both ISAs and and an API... Can't seem to find any others.