ACI Network Centric to Application Centric Migration

[ig.ciocan]

We are planning to migrate our existing infrastructure to ACI in few steps. First to a Network Centric setup (EPG=VLAN=BD) with a L2 connection to the legacy infrastructure, migrate L3 to ACI and finally to an Application Centric design. 

Now, the question is, does it make any sense for the last step to be done into a new tenant? Any pros and cons to that?

[RedNectar · Accepted solution]

Hi @ig.ciocan ,

To be frank, the step that says "finally to an Application Centric design." doesn't make much sense to me anyway.  In fact I know of some people who refuse to believe there is such a thing as eitehr "Network Centric" or "Application Centric". I don't go that far. Both are theoretical concepts, and one is not necessarily better than the other. However:

• It is easier to migrate an existing infrastructure to "Network Centric" i.e 1 VLAN= 1 BD = 1 EPG
• There is no intrinsic benefit of moving from Network Centric to Application centric, unless you are charging by the hour and wish to gouge your customer

So, as for moving to "Aplicaiton Centric" in a new tenant, I would suggest that you leave this decision until well after you have completed the first stage of the migration. About that point you might start to realise some of the power of being able to organise Dev and individual projects within new tenants and later migrate them (or not). Don't worry about whether the design is either "Aplicaiton Centric" or "Network Centric" each application will have its own quirks that might suit one approach better than the other.

Sorry about the rave. 

I hope this helps

---

Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

---

[ig.ciocan]

Hi Chris,

Many thanks for your reply. I am just curious to see what approach did people have taken about organizing things in the ACI during and post migration and what are the benefits of each choice. 

But as you say, it will be something to figure out along the way giving the complexity of such a project.

[Claudia de Luna · Accepted solution]

Hi @ig.ciocan,

I have to agree with Chris.

We are way past Network vs Application. The value of "Network" is that it is easier for those who are relatively new to ACI to digest and I don't underestimate that value for the initial migration and operations. But it can be limiting and its not that big a leap to go to the next step.

These days I talk to my clients about a "hybrid" migration which is basically what Chris described. Its also important to understand if IPs are changing as that may give you a bit more latitude but one of the most powerful capabilities of ACI is that you can improve your security posture without changing IPs.

No client (that I have encountered) has a full understanding of all the moving parts of their applications and so you never really get to "Application".

However, many clients do know that these set of servers never need to talk to these other set of servers even though they are on the same subnet. Now you have two EPGs, EPG1 and EPG2 (and one bridge domain BD1). And maybe they know that the servers in EPG1 should never talk to each other. So now you can enforce Intra EPG Isolation for EPG1. They may also know that while their CRITICAL-APP1 currently in one VLAN/Subnet has these 10 servers and no one knows the internal communication between those 10 servers on that vlan, the inbound and outbound policy for that VLAN is well know. So thats your CRITICAL-APP1-EPG using CRITICAL-APP1-BD with Contracts.

Thinking about this up front, at least a little, can really help improve your security posture without too much extra work.

Maybe you are not sure if you can split the servers into EPG1 and EPG2. Separate them for your migration and use the default contract (allow all basically). Once you finish your migration, build a contract between EPG1 and EPG2 thats permissive and logs. This is a very time consuming way to do Application Dependency Mapping but you have all the tools you need to do it already (well maybe except for time :D).

But already, with your migration: 

• you have a control point between EPG1 and EPG2 (on the same subnet) that you didn't have before
• you have isolated the servers in EPG1 so if one is compromised the other servers in EPG1 are not, and
• your CRITICAL-APP1 is protected as well.

Those can be some big wins.

You also have some tools to help segment further, your time permitting.