Re-platforming a Monolithic Application for Kubernetes

Micro-services is generally accepted as the only way to do cloud-native because the loosely coupling is considered a best practice for fault tolerant cloud architectures. However we believe its possible to reduce the capability of a monolith by extracting all of the non-business related functions and externalise them with cloud-native replacements. For example strip out any databases, caches, AMQ services and use cloud-native replacements. Using this principle you should be able to reduce the overall responsibility of the application by a considerable margin. We think there is a place for monolithic applications in the cloud but the resource demands and potential lack of fault tolerance of the application will provide many challenges. There are numerous tools and features available on Amazon Web Services like AWS Systems Manager that make managing some of this easier, however it is much more complicated recovering from a failure with a monolith. Loss of data is a likely scenario in the event of a issue with the application. If I had to prioritise any features it would be data access and local storage. Use a database managed service and a external cache and avoid writing to local storage for performance reasons. By externalising databases, caches and storage it would be possible for the monolithic hosts to be ephemeral and this will improve fault tolerance and reduce operational complexity.