Hello Dojo,
We are currently working on a project involving managing multiple television stations nationwide. I'm seeking your advice and expertise on the best architecture.
Specifically, I'm wondering about two aspects:
- DMA architecture:
- Should we implement local DMAs at each station, or would a central DMA be more efficient for this setup?
- Database/StaaS:
- We are leaning towards using Storage as a Service (StaaS). How would this work practically? For example, do we need to establish direct connections to each location? What challenges might we face with data synchronization and consistency across all locations?
- Alternatively, would database clusters be a better option?
Any insights, recommendations, or experiences you can share would be greatly appreciated!
Thank you 🙂
Hi Wout,
- Architecture:
Both approaches are perfectly valid, but my personal preference goes to a central approach. This allows you to more efficiently manage your compute on a central location. This will be more efficient and easier. You could also opt for running that in the cloud, your own cloud of choice or in dataminer.services as DaaS (DataMiner as a Service).
The distributed architecture does have one advantage although, and if that advantage is a hard requirement, then you should choose distributed, otherwise I would go for central. The requirement is whether local monitoring and control is required when there is a major network outage. If the network is down, a central system won't be able to do anything, while a local system would still allow you to do something. Networks are very reliable these days, therefore I'm leaning towards a central architecture by default, but both approaches are valid and have their strengths. - Storage:
For me that's a no-brainer. STaaS is superior. Setting up your own cluster will just be a lot of work and maintenance, and you'll never reach the efficiency, security and reliability of the cloud native STaaS solution.
How does this work? Well, each DMA node needs to be able to access the storage, either your own database cluster or STaaS. In case of STaaS, it just makes a connection to that STaaS hosted in the Azure datacenter of your choice.
You don't need to worry about data synchronization or consistency, that's all take care of for you. You only need to choose a datacenter location and optionally if you want geo-redundancy in another location.
Let us know if you would have any additional questions.
Bert
Hi Wout,
DMA Architecture
Both are valid options, both having their own advantages, and your choice may depend on specifics for that ecosystem such as the connectivity, number of elements, etc. A centralized DMS can manage all the products across all the stations, of course there has to be IP connectivity from that central location such that the central DMS can communicate with all the products subject to management by DataMiner. The centralized architecture might result in a more efficient use of the DataMiner capacity that you have available, and might facilitate an easier management of the compute hardware. Of course, if connectivity between the central location and the products subject to management by DataMiner fails, there is no further data collection and one would no longer be able to control those products with DataMiner.
In a distributed constellation, where you put DMAs in each location, when connectivity is lost, the DMA at the location is still a fully functional DataMiner System by itself. So data collection would continue, and people working local can still use DataMiner to control those products. The downside might be that you the compute hardware assets are more distributed, and you might have a slightly less efficient utilization of the capacity of the combined DMAs that you deploy.
Again - it all depends a bit on the number of elements that needs to be managed on each site, the nature of the connectivity between the sites, the application of DataMiner (monitoring, control, orchestration, etc.), the expectations in the event that connectivity fails.
Things you do not have to worry about is for example security, because that's completely abstracted from the underlying DMA architecture and set-up. So you can freely decide which people can access which elements, irrespective of which DMA is used to manage those.
Database/STaaS
STaaS would definitely be your first choice, as it is overall considered by far the most cost-efficient choice and by far it offers the most convenience in terms of operation. In terms of connectivity, yes the DMAs require outbound access to the public cloud. There would no 'challenges' with respect to synchronization or consistency across the locations (i.e. there is no difference between a private storage solution based on Cassandra and OpenSearch, and the STaaS service).
I would say that a private storage would only be a better option if you want to operate on a location which is completely off the grid. In that case, it is obviously the only option.
Hi Wout
- DMA architecture:There are some considerations to be made here, do you have a lot of devices to monitor from each station, how far apart are these stations, how easy is it to unify the networks, or ensure you can access the devices at each station from a central location? Depending on the answers to these questions, you can decide on a central DMA vs one DMA per station and then cluster them. Note that if the locations are far apart you will need great connectivity between them to sync the DMAs.
- Database:Here we promote STaaS as the default for all deployments. Know that STaaS has a single endpoint so no connectivity to multiple sites/databases/locations is needed for this. Data synchronization is also not an issue since this is taken care of by STaaS in the background.
Database clusters are an option but they require more maintenance and depending on where you host the nodes (which you need to provide yourselves) you will also face issues in the syncing of the data if the nodes are spread far apart geographically.
This is of course not all the info, other people might come with more insights but this should get you started I think.
Wkr,