2

We're currently in the process of designing our new version of an existing application. This new version will not reuse any existing code as the old code is over 10 years old and tightly coupled.

With this new application we'll be designing a persistence layer. And as we want to adhere to an agile development cycle. We'll need a way to have both the old and new applications running side by side. Personally I could think of two solutions to have the applications work on the same data, and I'd like to have your input in which solution is most viable. Of course if you know of a completely different solution feel free to answer that as well.

current setup

Currently we're running two MariaDB in master-master replication. Ids are auto incremented with one generating odd and the other even ids.

new setup

We've no clarity on this just yet. Except that we'd like to remove primary key generation out of the persistence and infrastructure layer. Another wish is scalability. The latter preferably with read write segregation (if that's relevant to the question)

1. Sync

Make code to continuously sync all data between old and new. This means it has to know about the old structure and new structure and be able to move it around. Biggest issue seems to be the latency the sync introduces whi I might lead to data anomalies. To reduce this we might make one of the sync ends the "master"

2. Implement new persistence in old

Basically the idea would be to have all persistence logic in its own codebase. That way we could pull it into our old application and write adapters to have it use the new system already. I like this approach as it enforces one source of truth. Issues with this approach might be that it could take far longer to implement the adapters; as well as that it might be problematic to get the legacy code to play along with the new structure. Not to mention, having to dabble in untested spaghetti code.

What would be the best course? (Preferably with objective arguments on the advantages over the other method 😉)

Improve this question
5
  • What kind of storage system is there for the existing application, and which one for the new application? Are you talking about a (central, transactional) database, or something else? Commented Jun 18, 2018 at 18:03
  • 1
    agile favoring working software doesn't preclude a switch-over, you could still have the old one be primary until the new one is ready to be primary, and the old one can be replaced or phased out; I would want to limit the amount of time both are running side-by-side. Commented Jun 18, 2018 at 18:40
  • @doc-brown updated the question with current setup information. Commented Jun 18, 2018 at 18:59
  • @esoterik that surely is an option. Though we'd probably end up making a sync from production to beta so we can see real data in the new application. Maybe post your comment as answer so it can be voted and discussed? Commented Jun 18, 2018 at 19:02
  • If you use a database that supports insert, update and delete operations on views (in conjunction with triggers on those views) you could turn the old schema into views that feed the new tables, thus providing backwards compatibility while letting the database handle the syncing. But then you have 2 problems. Or stored proc's to feed both? Commented Jun 19, 2018 at 0:33

2 Answers 2

Reset to default
2

Agile favors working software, but that doesn't necessarily mean complete software. From software engineering perspective, I would want to limit the amount of time both are running side-by-side.

You could keep the old system until the new system is ready to take over, and regularly keep importing/syncing the data from the old into the new, for testing, and so it will be ready after the switch over. Then you can remove or phase out the old system.

An issue with this approach, is feature parity, or when can we switch over; this could be helped if the system is designed such that you are only changing out the back-end, and features built upon it will still work. It may be worth refactoring the old system to allow this kind of migration, to reduce the amount of re/work to required.

Improve this answer
2
  • Correct me if I'm wrong, but in the first part of the answer you suggest making it possible to migrate data from old to new and do it periodically for testing purposes. And in the last part you hint at connecting the old system to the new data. So basically, do both solutions? :-D Commented Jun 19, 2018 at 6:39
  • 1
    @MaartenBicknese no you would abandon the old after switching to the new you never have to implement #2 Commented Jun 19, 2018 at 17:58
0

I think the answer is about tradeoffs. Deciding where you invest time now to save time later.

First of all is there anything wrong with the current db schema? If not then you could easily create copies or synchronise the data periodically.

Is this internal only or is it sold to customers? If its sold and supported then you may have to upgrade and migrate client systems. If that is the case, investing time in a repeatable update/ migration process makes sense.

In my mind the objective would be to get to the final result as quickly and efficiently as possible. Synchronisation and bidirectional updates sounds like huge amount of effort for questionable gain.

In my limited experience of agile, I would expect lots of incremental changes. Which means the schema will be constantly evolving, which means synchronisation would have to constantly evolve as well.

Improve this answer
1
  • Not sure where the answer is going but I can already tell you there's a lot wrong with the current schema. No sense keeping it Commented Jun 20, 2018 at 10:42

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.