and we want to migrate it t ecs or eks on aws. I was in process of breaking code of mono into smaller pieces. I got one service code ready for testing or staging area. my only question is, after we deploy through docker, ecr to eks and or ecs containeraized job.. how do we connect that container to our current monolith application? like gradual deployments.. this is only i’m working on but if you guys have any better deployment patterns i would appreciate the input.. Wverything i understood well, from guthub actions ci and argocd to eks or ecs but how can we process this operation in our prod env? anyone please suggest
Why are you breaking up the code? Are you doing true microservices or are you just breaking up a monolith and leaving behind tightly coupled but independant services?
Like said, im new to devops...only goal is to migrate monolithic app into ecs/eks containers.. could you assist me how can i achieve this process please?
https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/
discuss here, everyone could learn
Great, perfect. Since we don't have Kubernetes expertise, we planned to use ECS or learn EKS, whichever works best. I have deployed containers to both ECS and EKS using Docker images from ECR. However, I find the deployment methods confusing. Here's what I want to do: gradually break services into smaller components and deploy the Docker image of each service to ECS. The overall concept is clear, but I need to understand the process in detail. Specifically, I want to take a service from the monolithic app, deploy it to ECS, disable the same service in the monolithic app, and connect the deployed container to the monolithic app. Is this possible? I've tried Googling and using ChatGPT, but I'm still confused. If this process isn't correct or practical, what is the best way to handle it? For context, we have a web application.
If you don't have enough expertise, consider the following: no eks, first of all. You cannot absorb that learning curve and you don't need it. Go on ecs. Take your monolith app, and adopt the mindset of breaking it down into multiple repositories. Identify a canary service, contained enough to be used as an experiment. Copy the current monorepo into another repository. Build and deploy both applications, now you have two monoliths. Now, from the first one, try to route all the requests to the canary service through the monolith with the canary. The goal is to: Move towards the results with baby steps. Measure everything. Don't do big bang refactoring. Tackle one microservice at time.
yes application LB right and it has a url. exactly this is my question.. lets say our app is in our own domain xyz.co and we can use route53 to map our own domain? because in realtime website, when a user clicks it should show our domain url only right not the actual lb url? correct me
You can have another R53 record known only to the first monolith if you need to, don't start playing with the cname as of now
have something like new.xyz.co and cname that to the ALB (use an alias record)
Firstly, why you want to change the monolithic app into microservice? In certain situations, even people that have run microservice change back their app into monolith. The answer to why is the most important
for flexibility, we have multiple teams and multiple services, just want them to deal with their own service like updates, restructuring etc., instead of taking down the whole app each time
With proper CI/CD, you can deploy monolithic app multiple times per day. Couple with blue/green and canary for easy roll back
Обсуждают сегодня