This is the reason why it is important to plan Disaster recovery and also plan Multi-Cloud architectures.
Our applications and databases must have ultra high availability. It can be achieved with applications and data platforms hosted on different regions for failover.
Critical businesses should also plan for replication across multiple cloud platforms.
You may use some of the existing solutions out there that can help with such implementations for data platforms.
- Qlik replicate
- HexaRocket
and some more.
Or rather implement native replication solutions available with data platforms.
I am working on the world's first end-to-end Database Migration tool, supporting Oracle to PostgreSQL and MSSQL to PostgreSQL database migrations with AI for Schema Migrations.
Until now, people used different tools for Schema Migration and Data Migration/Replication.
During this process, we ended up building a data migration and replication tool supporting any databases between Oracle, SQL Server (MSSQL) and PostgreSQL databases.
For some applications it might be of great use but for a vast and complex applications architecture, the libyear metric might only oversimplify the complexity of dependency management,compatibility issues, updates and security patches, etc
I noticed that it focuses only on the age of dependencies without considering other factors like the how critical is the update, and how stable it is, and the improvements in newer versions, etc.
Right, but that means it's not a decent starting measure.
To me, "decent starting measure if there is no appetite for something more in-depth" sounds like "just drop it in, it's enough to get started, we'll figure out the rest later", but that could be temporarily harmful.
Exercising judgment is the opposite of that, no? Then you're going into depth.
At a previous company we had this big web-app (filterable) matrix which listed each project dependency, but the neat thing was that you can tag dependencies to add weight and importance.
Initially i thought it would need to be more complex, but but it was more than enough.
Relying on external APIs or databases within activities might lead to variability in workflow execution.
Also, on handling HTTP errors in activities by raising an "ApplicationError" based on the status code, might simplifies error handling but might need to see how it accounts for more complex scenarios where errors are transient or where a retry could be successful even for some client errors like rate limiting or temporary unavailability etc.
As the asyncio library itself does have a steep learning curve, integration of asyncio with workflow systems like Temporal that also uses Pythons native asynchronous features, developers should be careful about indirect or subtle bugs, especially in error handling and task management.
> Relying on external APIs or databases within activities might lead to variability in workflow execution.
This is why they are activities. Their results are stored in history, the workflow remains deterministic.
> might need to see how it accounts for more complex scenarios where errors are transient or where a retry could be successful even for some client errors like rate limiting or temporary unavailability etc.
Temporal allows you to specify whether an error is retryable or not.
If you already know, Orafce is an extension that emulates in PostgreSQL, a subset of functions and packages from the Oracle RDBMS.
This extension is very helpful while porting Oracle applications to PostgreSQL, avoiding application code rewrites in a performant way.
Do you think it is worth having a similar emulation of Oracle functions/packages on Snowflake and BigQuery ?