CODEWITHSUNDEEP
javaoracle-databaseamazon-web-servicesamazon-ec2jboss
sromit
sromit

Reputation: 1114

Best option to lift and shift JBOss and Oracle database to AWS

I have a big application where there are 5 ears deployed in JBOss7.1.1EAP server running in Red hat Linux on-prem connecting to an Oracle Database on-prem. What is the best approach for lift and shift to AWS

Solution-1 : Create Jboss EAP instance in AWS EC2 and an RDS Oracle instance and deploy the ears and migrate the tables and data via aws DMS

Solution-2 : Dockerize JBoss EAP with ears in a container and also dockerize Oracle instance and create a network link between the two

Oracle DB size = 3847GB
Each ear size = 300MB

Which solution will fit the best and what are the pros and cons for each solution? Are there any other solution?

Upvotes: 1

Views: 1022

Answers (1)

Nick Walsh
Nick Walsh

Reputation: 1875

Quick preface, "best" is going to be subjective depending on how sensitive this project is to the amount of time for refactoring/learning new tools, how much you weigh cost savings, and the wildcard around managing more of the stack yourself. That being said, here are some considerations for the big two parts of your app:

RDS Oracle vs Containerized Oracle

Dockerizing the oracle DB means that you still need to handle security patching, and requires manual crafting of scaling up/out policies, something that RDS abstracts significantly. Amazon DMS makes it extremely easy to migrate your data from your existing on-prem database to RDS. Additionally, the move to RDS enables you to use other valuable co-features, like RDS Performance Insights, a tool that offers introspection into cluster resource impact from queries and operations, and RDS Proxy for handling connection pooling.

JBOss compute options

If you're currently running on-prem and are trying to lift and shift to cloud, the path of least resistance will be a direct migration to a properly sized EC2 instance. I'm not very familiar with the exact architecture here, but it sounds like there's a persistent server with various sub-applications (ears). In the long term, it sounds like a persistent compute layer (EC2, ECS, Fargate depending on your desired level of abstraction) for the core service, with various scaleable components (containers via ECS/Fargate) would make sense. If significant refactoring to a microservice architecture is not something you're looking toward, then keeping things as they are as a monolith on single node/EC2 instance/container would work.

Upvotes: 1

Related Questions