Onboarding a Historical Company on the Cloud Journey

Editor's Notes

1. The IT department of the Customer encompasses the implementation and operation of a large number of business or technical applications It includes many professions, mostly IT professional oriented : infrastructure engineers, architects, technicians, and so on It relies pretty heavily on outsourcing different tasks like managed services, operations, production, expertize, or consulting to external companies (mostly via service and competency centers) Some services of the internal organization: Engineering Operations and Service (EOS) Production Service Information Security Service (ISS) Infrastructure Project Management
2. Owns a number of Data Centers hosting currently the infrastructure the applications The whole infrastructure is known as The Information System (IS) As The Customer joined The Group, their infrastructure’s networks got interconnected Today, a user from the IS is capable to connect to a service within the Group’s infrastructure, and viceversa However, various elements of the infrastructure (like networking appliances, identity systems, tooling, and so on) are different Also, there are differences in governance and procedures For the Customer and for the Group, there are very important security concerns and restrictions (due to their strategic activity)
3. Looking closely to the advancements of the main actors in the public Cloud : Microsoft Azure, Amazon AWS It seems that the Cloud may be the gate « Let’s try and see how it works and how it could help us » Key factor : onboard the Information Security Service (ISS) team from the very beginning This ensures there will not be [too many] blocking rocks on the road [TODO bienvieillance du DSI / IT Officer)
4. Requesting an Azure agreement via The Group An Azure subscription was provisioned The ISS team was the one using an Azure Subscription (fall 2016) Several basic deployments were made, and a site-to-site VPN connection was tempted The first learnings : some projects need to be interconnected with the SI others need rather to be separated/isolated from it (risky or unknown stuff running) Then, the advancements and works slowed down Also, the VPN was malfunctioning
5. The EOS engaged to initiate a dedicated Azure team Team directly attached to the chief of EOS 2 people, Azure experts, with knowledge in infrastructure, networking, security, and governance Not easy task, but people were found (at Cellenza)
6. First thing first: the VPN was fixed Not a big issue, the configuration was mostly good, but missing a « keep alive » option while no traffic (« Dead Peer Detection » set at 10s in local Juniper appliance) Second thing (during the works for the first): « security hole » detected (and solved) The « force tunelling » setup was envisioned but missing in configuration Results: The team gains the Customer’s confidence The Networking team is also very cooperative
7. Enthousiastic of the advancement, the Customer envisions moving on in the Cloud and eventually targetting production workloads Blocker : the Group strategy is not yet in phase with the Customer’s one regarding the Cloud The Group warns about production responsability in the cloud Result: agreement on an « experiment oriented » scope for the Customer’s Cloud works
8. VNET w/ VPN : Because of the Forced Tunelling, all traffic in Azure has now to be monitored and configured in local appliances (Palo Alto) The actual process of configuring the rules for projects takes days or weeks Solution: a set of 2 Network Virtual Appliances (Palo Alto) was configured and implemented in Azure They now allow the configuration of the rules to be directly implemented by the Azure team jointly with the ISS
9. by this, interconnected with the whole Group