Share on :

But what happens to them? Florian Lacommare tells us about his experience with the SDN.

13 July 2022 Alumni portrait
Viewed 1010 times

As part of the animation of the alumni community, Epita's alumni association decided to conduct a survey on the evolution of former students after graduation. This week, as part of the month dedicated to the TCOM speciality, we look back at the career of Florian Lacommare, a TCOM graduate in 2013.


Florian, can you tell us a little about your background and how you chose Epita and then the TCOM speciality?


Florian Lacommare : At the end of high school you have to find out what you want to do in life, and for me it was quite intuitive to choose IT because I didn't want to have a classic curriculum. So I chose EPITA rather than a general engineering school. Once in the school I chose the TCOM major because it was the one that most closely related to a subject that interested me and that I found a little mysterious: the network.


Following your studies at Epita, you did your end-of-study internship at Metanext, an ESN specialising in the Cloud. Can you tell us about your first steps in this company?


FL: I met Metanext during a company forum organised at EPITA. I was the second intern to be hired by them, there were less than a hundred of us at the time. I wanted to go into datacenter technology and my internship subject was to understand how a datacenter works and the tools used, both in networking and in systems and storage. At the time, I also had to learn about the technologies used in this ecosystem, in particular the Cisco Nexus product range, which was quite new at the time.

At the end of my internship I was hired on a permanent basis and I started a one and a half year assignment in the security teams at Carrefour. Security was not the area in which I was most at ease but they were looking for profiles to improve my skills so I accepted. After a second mission at ENGIE, Carrefour called me back for a position in the Datacenter architecture team because I had told them of my interest in the subject. The advantage is that Metanext is a company that listens to its employees and they easily accepted that I change my mission.

I then started a long period in this team with a great redesign project.

And then the world evolved and the technologies with it, I became interested in automation and Software Define Networks (SDN).

In 2018, we (Metanext and I) had the idea of having a team dedicated to these topics. It was quite precursory at the time, especially for an ESN of this size, but we took the gamble and despite the difficulties of lack of human resources and skills available on the market it took. And as the idea interested Carrefour, we also set up a team of this type with them.

I'm still there today and things are going very well.


Software Define Network and network automation, these are the subjects to which your team is dedicated. Can you explain these concepts to us?


FL: In 2013, when I got interested in SDN, it was an academic word that referred to having the network driven by software. The aim was to make savings by optimising, for example, the cost of internet access, which varies between operators, by configuring the network according to the price of the link or the criticality of the traffic. It could also be used to anticipate configuration changes in the event of a breakdown.

Today this concept has been somewhat lost and the term is in my opinion much more marketing when used by network equipment resellers. My definition would be a solution that has been packaged by a manufacturer and that drives the network. The best known are CISCO ACI and VMware NSX. Their principle is to have a controller which gives orders to virtual or physical boxes which remain intelligent and therefore autonomous whereas in the initial definition of SDN the box is not and depends 100% on the controller.

The strength of these solutions is that their controller exposes APIs that will allow the network to be included (its configuration, deployment, etc.) in self-service portal tools for private or hybrid clouds and ordering services on demand, as is the case with cloud solution providers (AWS, Azure, Google Cloud Platform).

On the definition of network automation, I also have my own definition: for me it is when instead of buying a controller from a publisher, we ourselves develop the use cases we need so that the network configures itself. This solution allows us to reduce the costs incurred by buying very generic software with many use cases that we don't necessarily need.  On the other hand, the software costs are replaced by human costs. To do this, we use network equipment that is capable of being automated because it has APIs, among other things. In this area, we find practically only open source technologies. 


You've been talking about network automation and box autonomy. Should I deduce from this that artificial intelligence has a place in this field?

FL: It's becoming more and more common, as it is in most fields, but I don't think the field is mature enough for it to work.

I've often seen it in tools that collect logs and try to predict risks on equipment.

The automation of server deployment has also existed for a long time, notably through the Ansible software, but it is only recently that they have integrated the network part. So we can see that the network is often a bit behind the system solutions. And that's quite normal because, in the end, everything depends on the network, and if it doesn't work, nothing works, so we have to be very reliable and use the precautionary principle. In this context, new technologies are slow to be implemented because they are considered risky.


When we talk about the data centre today, many companies talk about relocation to the cloud. How did automation come into play in this migration work?


FL: When you're in a big company you tend to want to do Infrastructure as Code to be able to exploit the advantages of the cloud (i.e. resource on demand and the speed of getting them). So there are some additional constraints in the cloud and different ways of doing things, and automation consultants are often more comfortable with these because it is the same philosophy. 

You also have to take into account that a company is rarely 100% in the cloud. We're often on hybrid models and automation will help ensure that business teams can use resources from both systems in the same way to make it easier for them and improve internal resource request processes.

Automation helps enforce standards and security in the cloud. For example, a business team that needs a new application will be able to 'order' a new account via a portal that is made available to them and this account will be created automatically while being subject to an overall access management and security policy. Sometimes this also involves network constraints and automation.

A company does not need to have automated its network to migrate to the Cloud. In the end, even if automating the on-premises network is not mandatory, there are undeniable advantages to doing so, but if we are talking about the network in the cloud, then yes, it becomes mandatory to automate it. And the icing on the cake is that network automation consultants are usually quite comfortable with handling cloud services.


You say that one of the objectives of automation is to make business teams more autonomous. Is there a policy of acculturation to basic network concepts in place to help them formulate their needs? 


FL: No, the network has always been a bit separate and is a fairly complex area. For me, a good network engineer must be able to translate business needs into technical and network needs.

But it's true that for the cloud, although a framework has been set up for security issues, we try to make the business teams and the systems teams aware of good practices in order to make them responsible, because the objective is not to lock down the network and security, but to make them autonomous.


Does this mean that a network engineer also deals with security issues or collaborates with security teams?


FL: Generally speaking, network engineers understand the whole language of infrastructure and therefore communicate easily with other teams whose tools rely on their infrastructure to function. Security is very much linked to the network, historically it was one team that dealt with both.


If we go back a bit, how has the training provided by the TCOM speciality helped you throughout your career?

Generally speaking, the philosophy of EPITA is to teach its students to be autonomous. And this is a strength, because as a talent recruiter within my company I notice that in other schools students are formatted and this makes them less comfortable when it comes to thinking outside the box.

In TCOM we really learn the basics of how the network works and it is therefore easier to understand all the technologies that come with it, however new they may be.

There are also Mr. Stephan's courses which teach us about life in a company with notions such as benchmarking and which sharpen our critical thinking. This is a great advantage when you enter the job market.

You have been working for Metanext since you left school, which is rare in the digital sector, which has a high turnover rate. How do you explain the fact that your company meets all your expectations in terms of professional development?


FL: I would take the question in reverse and say "why would I want to change company? At Metanext the management is great which I find very important and there are not 25,000 layers of hierarchy. Discussions are open and I don't have a problem saying when there is a concern. The managers are not sales people whose salary is indexed to my staffing rate, we invest in profiles and we don't want them to leave because they are placed on assignments that don't suit them.

We are not to be pitied from a salary point of view either. Once again, the employee's life and the market are taken into account, we don't work with grids.

I also like the fact that I am surrounded by infrastructure experts who help each other and create a community on a human scale with a good atmosphere.

Finally, it is clear from my example that the company trusts its employees to work together on projects such as the setting up of my team.


We are coming to the end of our discussion, do you have a final message to pass on?


FL: We need more engineers who are trained in infrastructure and the cloud and there is no French school that does this. We are often forced to look for our candidates abroad and this is a tragedy. I encourage EPITA to follow the market in this sense.


Thank you very much Florian for this very interesting exchange. 


I like

No comment

Log in to post comment. Log in.