Question

Has anyone done a port from a monolithic server application to a service and what are the hidden ‘gotchas’ I need to be aware of to accurately estimate the cost of this?

We have an existing single threaded monolithic server application written in Java. It performs fine as it sits, but we want to start extending it. Extending it would mean many more people would use it and the server would not be able to handle the extra load. There was a significant development investment in this code base, and the code base is large. The cost of multithreading the server would be crazy.

I had a harebrained idea about breaking it up into logical service components, removing them from the application and hosting them on Axis2 or Tomcat, and pushing them into a SOA cloud.

I have written many services for Axis2, worked plenty with SOA clouds, and written multiple monolithic servers and it seems straight forward. Eliminate as much shared state as possible – then push that to a DB of some kind, pull out logical services from the monolithic app, repeat until done.

But I have a bad feeling that the devil is in the details and I am certain I am not the first person to have an idea like this.

Answer 1

My experience in these types of system/architecture migrations, the time-sinks and killers tend to be:

• Identifying all use-cases and functional requirements. Roughly 50% will not be documented. Out of the 50% that are, 50% will be incorrect. Out of the 50% that are both document and correct, 50% will not be valid anymore.
• Ensuring backwards compatibility. Just because you are moving to a new architecture generally doesn’t mean that all clients will move with you at the same time.
• Migrating existing data into new structure/model/architecture. This always takes a lot longer than you think. Take the worst case scenario you can imagine in terms of time/cost, double it and you’ll still be short by about half.
• Access control model.
• Documenting your services in a clear and useful way. Your shiny new SOA architecture won’t be worth squat if no one can use it.
• Performance testing. It’s mind boggling how often this is skipped or done at the very end of the project. Establish performance scenarios, testing infrastructure and baseline values first thing and then continually test and measure against them. This should be to an architect what unit testing is to a developer.

These are the things that make projects fail, go over budget and over time if you don’t address them early in the project.