0

We have about 10 applications in one Monolith that need to be refactored into Microservices.

Following an Agile approach, we would like to split work into vertical slices where each slice would be useful to the User. Each slice would include a persistence layer, a service, and a user interface. However, we are not sure how to handle the UI layer. Should we tie our new microservices into the old UI, or create a new UI that would be available to a few users?

The first option would require a lot of work to wire the microservice into the old UI. Further, we would eventually have to tie the services into a new UI. Hence, twice the work. The second option would require two UI's running in parallel and would certainly get less traffic until the project is finished. Since, it will likely have a subset of users that may not use it often I question, how useful it would be. The second option seems to make sense to me, but we have been toying with another option.

The other option would be to simply create the service layer only and add a new UI as a separate epic. Testing of the service could be done through an API testing tool, e.g., Postman. This approach seems simpler at first, but it has issues. First, it seems to fly against an Agile approach and follows more of a Waterfall methodology. Thus, we don't get true incremental feedback from the User since they really won't see anything usable until the UI is done.

So, I'm sure there are many ways to approach this problem, but wondering if there is a typical way of solving it.

4

To get to the answer for your question, you have to ask yourself what value you are going to create by completing the work incrementally. In agile, the idea isn't to do the work in slices just for fun, there should be some value from it. In its simplest form, that might be risk remediation. By confirming you get the same results from the microservices, you get some knowledge value in reduced risk with your last option - just testing against the service layer. I agree that this is the least agile because you are still committed to the whole refactor, but it is a big step up from just integrating at the end.

If there are some big performance or quality gains you get from the transition to microservices, it might actually be worth the effort to wire it up to the old UI. Yes, it'll add time and cost, but if the compounding value benefits from early use of the new architecture warrants it, then it might be a good trade.

Finally, here's another thing to consider:

How similar are the old and new UI? If they are too similar, you might ask yourself why. In most large rebuilds, the needs of the user have changed and our thinking around effective UI/UX has evolved. In most of these projects, teams should be asking themselves if they can solve their user needs better. If so, focus on the new UI flows where there is the most to gain for the user - this will counteract any aggravation from dealing with 2 UIs and can deliver some really huge value. Then, extract the services from the monolithic application to microservices that support those flows first. Chances are, it won't be clean lines and you'll end up moving some things that aren't strictly needed for those flows, but that's ok. That approach would probably be the most value-oriented if it fits your situation.

One final point: if you are creating a duplicate new UI, be careful of just testing that the new services work in the new UI ok. Old systems have all kids of odd edge cases that have developed over the years. I've seen a lot of projects like this wire up to a new UI and miss some nuance in the old UI that causes serious problems for the user.

  • Great points! The new UI will likely be very different to the old one which is why we were considering two parallel UI's with a small group of canary users using the new UI features as they come out. Seems to me we should be developing from the UI down rather than starting with a service. This would help us figure out exactly what the UI (and the business) needs to the job. Otherwise we might just create services that won't even be used. – navig8tr Nov 27 '18 at 18:32
0

If you wanted to keep your old UI, it would look something like this:

Db > App > UI is what your old application probably is, but when you put in microservices, it'd look like:

Db > microservice > App > UI, with microservice > App being a http(s) layer.

In this approach, App would be modified heavily but as long as the UI contract is fulfilled, 0 changes.

I wouldn't recommend it though, a new UI would make your app look more modern for less effort than implementing the micro services in most cases.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.