Once upon a time in a Migration from Legacy to OCI Public Cloud

-

In my previous experience with AWS, Alibaba, Google and PTCL Public cloud I have been working with mostly green field deployment for in house solution with all in and out clear. This time I get challenge with a brown field migration from on-prem to OCI Public cloud for a big public service company. As I always say go with the basic and build from the scratch we start a kick-off meeting with the customer and ask about their plan for this migration and what they are planning for it after discussing we get to know that whole environment need to be migrated so at that time, we bring the most tough ask on the table as plan was that customer want to perform migration in phases with more than 20 application on-boarded in current environment as i studied during my AWS exam preparation it's never suggested to use same IPs across different environments to avoid complicity and better plan for the migration we ask for the change of IPs for the instances that includes Web, Application and DB tier which currently hosting the services eventually  application owners need to be on-boarded so from the first day of planning we had this alignment that this migration will not be  only depends on the infrastructure planning only we need to on-board the application team as main stake holder while doing the migration aim was to achieve micro-segmentation and enhance the security after initial kick-off meeting and gathering customer information we took our time and come up with our solution design for the implementation after getting the require approval from all the stake holders.

We build Hub and spoke topology using DRG services while building the proposed solution we kept both solution from our end as one was consisting of in-build OCI solution like OCI Firewall and OCI Load balancer with WAF Policy, second one which was consisting of the OEM solutions for Firewall and load balancing and WAF services after approval we did the deployment as per our plan and start the migration from on-prem to cloud i will not say it went easily all teams work really hard to achieve it but only thing which we were able to do without impacting the current production was testing and make sure that all services was working fine still many integration came out on the night of migration as they were too much but not enough to make a major impact on our migration plan and at the end it went fine.

Lesson learns from this migration always bring all the possibilities on the tables so other teams can understand the thought process, don't over promise and make sure that all parties understand their responsibilities and roles and at the end don't thing that after migrating workload to cloud it will be secure by default it need to be plan and then implement accordingly to make sure its fully secure.


Raja Shajeel Ahmad
Hybrid Data Center Network & Security Operations and Planning
Happy Learning
The limit is the sky.

Comments

Post a Comment

Popular posts from this blog

Flow with respect to Networks in AWS

-
Image
Flow with respect to Networks in AWS which need to be clear to expose any application on AWS and having some of services in on-premises. I will compare AWS services with on-prem technology, so it become ease to understand.                                                           Building Block of AWS Networking VPC: Consider it as a switch place in multiple Data center and all switches are connected with each other we can further have small subnets on it which can be part of all switches or only one depend upon the planning and requirements. Route Tables : Each subnet we create in VPC can have each route table or all subnets have one, Route table is used to control the routing of subnets and how traffic will be routed for any workload on the subnets. Route table can be attached to few other services of AWS as per requirements. NAT Gateway: I...
Read more

SDN Isn’t Magic – It’s Collaboration with Core Networking at Heart

-
Image
Since 2015 when first question I asked from my NOC team are they getting MAC on particular VLAN, I learn something new about networks/IT. First time I heard about SDN from my teacher he was a Cisco TAC Engineer knowing very little the first task assigned to us was find out how ansible works and what is the use case of it. We took two weeks to understand it and then successfully used it to configure a Router in our lab environment, We were too happy you can imagine a network Engineer doing configuration without a cli is kind of magic for us. Afterwards in same training we deployed OpenStack opensource code using blue stack and use it most of services to deploy a image and then use it as router with power of Linux, anyhow training finished and we did our all lab testing and it was end of SDN for us as we didn't get any more time for RND and don't have any solution and that time which were based on SDN in our data centers.  Fast forward in 2019  first time I used SDN base solutio...
Read more

Important concepts in ACI Physical/Access polices Concepts

-
Image
I know Cisco ACI has been around for a long time. The first time I got into it was in 2021. It was not that hard to relate the legacy concepts with ACI but doing a job via CLI and doing it via GUI have a lot of differences. In this particular blog, I will discuss the key concepts without explaining the ACI core components like leaf switches, spine switches, and APIC. Cisco ACI is a policy-driven solution in which everything has an object assigned to it, and you need to connect all those dots to make your network work. In a legacy network, we have devices like bare metal servers, L2 switches, L3 switches, routers, and firewalls. We connect the networks using different protocols to make our network work, but sometimes there are physical requirements that need to be fulfilled to get the required topology. In Cisco ACI, we have all these kinds of devices, and they are connected to our fabric. However, in ACI, we have a term called "domains," which include four different types: Ph...
Read more