4 ms·

> Phase 3: Then deal with the stateful monoliths. These are your large monolithic databases. This is usually where private cloud journey hits the wall due to th

by snarfy 10y ago

> Phase 3: Then deal with the stateful monoliths. These are your large monolithic databases. This is usually where private cloud journey hits the wall due to the risk and complexity in making such monoliths cloud native. We are tasked with moving to the cloud, and this is where everything stops. Over the years, instead of fixing the monolithic database design, the company instead kept beefing up the hardware for the database. A bigger cpu and more ram is cheaper up front than re-engineering the entire company infrastructure. And now we are paying for it. Our db hardware now is the highest end hardware the db software supports. None of the cloud providers db support can handle it. We are forced to fix the monolithic design if we are to move to the cloud. It will be a multi-year effort.

mooreds 10y ago
> It will be a multi-year effort And the company is willing to go through it because the public cloud offers so much? Just curious if this was going to stop the overall project or not.
- snarfy 10y ago
  We were bought out by investors and this is their major initiative. I assume it is to reduce long term operating costs.
cyberpunk 10y ago
My current gig had a similar problem; changing the DB or putting a layer in front of it at a large scale or really er 'mature' codebase is basically a rewrite, and that's not really the smart way to play it and it's probably not possible anyway. Start from the top instead of the data. Moving various bits of the API to new implementations/microservices and modernize the stack -- new features, make 'em all standalone services and try to deal with your logic in the app instead of in the db. Move /send/giant_dildo_to?uzer=cyberpunk out of the monolith and to a sep service, and eventually you might get to the point where not a huge amount of the legacy code is actually being hit by anything besides your new code. At that point, the cost of redoing the persistence bit is way less than it was when you started. Depending on your app, you might even get away with creating a new DB and using the orig as a kind of 'feeder' which you run on batch -- all options are open right? But obv it depends what you're doing.

by snarfy 10y ago

mooreds 10y ago

> It will be a multi-year effort And the company is willing to go through it because the public cloud offers so much? Just curious if this was going to stop the overall project or not.

snarfy 10y ago
We were bought out by investors and this is their major initiative. I assume it is to reduce long term operating costs.

cyberpunk 10y ago

My current gig had a similar problem; changing the DB or putting a layer in front of it at a large scale or really er 'mature' codebase is basically a rewrite, and that's not really the smart way to play it and it's probably not possible anyway. Start from the top instead of the data. Moving various bits of the API to new implementations/microservices and modernize the stack -- new features, make 'em all standalone services and try to deal with your logic in the app instead of in the db. Move /send/giant_dildo_to?uzer=cyberpunk out of the monolith and to a sep service, and eventually you might get to the point where not a huge amount of the legacy code is actually being hit by anything besides your new code. At that point, the cost of redoing the persistence bit is way less than it was when you started. Depending on your app, you might even get away with creating a new DB and using the orig as a kind of 'feeder' which you run on batch -- all options are open right? But obv it depends what you're doing.