"Implementing DevOps, making infrastructure a shared responsibility is probably the way to go" Abdel S., Google cloud Engineer

Abdelfetah Sghiouar, is a Strategic Cloud Engineer at Google, and was one of the speakers at the Devops2020 event. Our Squadians had the pleasure to interview him. We discussed the latest DevOps and Cloud Trends, as well as the what the future holds for those organisations that have started their journey towards cloud-based infrastructure.

We had the chance to see you at the DevOps 2020 with a interesting presentation about the Google Cloud Platform. What turn do you think the cloud will take in the coming years?


Well, it's certainly a very hot topic right now , if you've read all the articles coming from companies that do forecasting and analysis like Gartner, you will see the numbers saying that by 2020 all the companies will be using the cloud.

There is one trend I am noticing, is that CTOs and CIOs have a better understanding of the challenges. It's cheaper, more resilient and more secure because you cannot really hire as much security people as a company like Google or Amazon. Companies like providers are increasingly more interested in compliance and  obtaining certifications.

So, there is a value in moving to the Cloud, because if you really look into how people used to consume IT 20 years ago, there was also a procurement-like life circle. You start, you buy a couple of servers, and invest a couple of millions euros. You buy infrastructure, you hire people, you operate this infrastructure and then five years later, your infrastructure depreciates. So you have to buy more. So you’re stuck in this cycle.

It's very hard for companies, because as a company you might not do well in five years. So you might not even have enough money to be able to buy more infrastructure.

Regarding organizational difficulty, do you think the biggest difficulty in the DevOps transition is the organizational part or the technical part?

I think it's a little bit of both. But I would say it's more an organizational and cultural transition than a technical one because at the end of the day. I mean, at the end of the day, the implementation details are not the hard part.

The hard part is, in my opinion, adopting DevOps culture. There are many difficult things about it. There is the understanding of how to organise it, then actually putting it into practice.

The organizational part is understanding what DevOps is. I spend 50 % of my time on this, because one of the problems I have, is that when people use DevOps out of context, it doesn't mean anything.

The word DevOps is meaningless without context. It's a bunch of practices, but which of these make sense to the organisation depends on the company basis. Thus, the definition of DevOps depends on your organization.

The second difficulty is how willing people are to change the way they do things, because any change within an organisation means a lot of work.

So how much investment are people willing to put in terms of time and resources to face the challenge?

Do you think DevOps is the future for software development engineers and all operations engineers ?


I don't think so, even for companies that have adopted DevOps. Google is one of the pioneers of this whole DevOps culture. We have SRE which is like an implementation detail of DevOps, but they also participate in automation and how do you do things right.

Although SRE people at Google don't like people to call them DevOps, there are some similar aspects. If we look at Google specifically, we are not getting rid of software engineers, we still have software engineers that are not doing an SRE job. We have so many SRE people that are not doing software engineering, because these two jobs have two distinguished responsibilities.

There are situations where we need people to be software engineers and we need them to be vertically focused on specific tasks.

Software engineers writing banking solutions are people for with a very specific skill set, which is not only their technical skill set. It's also an understanding of the business and understanding of how a bank works as well as all the requirements and the rules of what makes a banking software a « banking software ».

Taking these people out of their job to transform them into DevOps teams, I don't see any value in doing that because we need these people to be specialized in what they do. Same thing goes for people doing AI and machine learning and data science…

What we're going to see is if you are a software engineer with a speciality, there will be a need for you to stay in that context. But, if you are a software engineer doing generic kind of work, writing generic software or something closer to automation, then you will be probably slowly shifting towards DevOps.

Now, the other aspect is operational. So that's much more likely to actually not entirely disappear, but kind of shrink and become DevOps, because, people don’t understand that there is a value in having things done by code and not by humans.

Operations as it has been done up to a few yers back means people are clicking around on interfaces and running command lines on the terminal. People now are understanding that's not necessarily efficient, not necessarily secure, not safe. Somebody might be having a rough day not having enough coffee and then running around command and just breaking production.

If you write code for a specific change, you can test it and look at it before it goes actually into production… If it has some failsafe due to breaker switches, this means that the system is designed in such a way that it will keep failing.

I would say that going forward, pure operations as we know them will not exist anymore. They will be called DevOps or some sorts of DevOps, some flavor of DevOps. There are lots of words, to describe it.


Squad has decided to take the DevOps and DevSecOps turn by helping its employees to grow up their expertise with training and feedback in order to improve skills on CI/CD, Development, Security By Design, Cloud technologies, Containerization, etc... What do you think about it ? Is it a good strategy ?


Well, it's certainly a good strategy if there is demand. Squad is a consulting company. If there is demand for such a role, then I would say that training or teaching software engineers, how to do CI/CD., there is certainly value in doing that.

People have been doing CI/CD without really knowing doing CI/CD for a very long time, it's simply writing a bunch of Python or a bunch of Bash scripts that do all the build and deployment on their behalf. It’s just that instead of being triggered by a system, it's triggered by human.

So understanding the value in setting up a CI/CD pipeline once, and then letting it do its thing without you thinking about it means that as a developer, you are focused on actual code-writing rather than debugging. It's certainly a good strategy.

If an organization has a bunch of people that are specialized, like software engineers, in a big organization, it is probably better for them to have dedicated teams that built this common infrastructure for software engineers, So the software engineer does not have to do it themselves.

In a small organization, you don't necessarily have the luxury to do that because you probably have 10 or 20 people.

So implementing DevOps, making infrastructure a shared responsibility is probably the way to go until you get to a size that would allow you to have dedicated teams doing that

Today, we're working with customers of all sizes and one aspect, which is kind of related to DevOps and communities, is running consolidated community clusters, which I’m a big fan of.  It's more efficient, it's potentially more secure, it’s very valuable. So we have customers, for example, that are big organizations and then, we go there and they want to do 20 community clusters, because they want one microservice and one community cluster. And I'm like « why do you want to do that, it’s so inefficient » and we are going to distribute your knowledge across 20 teams.

We're trying to take these customers and push them towards having centralized operations and centralized devops teams taking care of infrastructure software. As a developer, I just write code, dress a Docker file, push it and then don't have to care how it gets to production. It's not my problem.

This is what I would call « development done the Google way », because that's how it works. The developer at Google is productive from day one. You have CI figures for you, you have testing, you have security features. You don't have to do any of this stuff. You probably have to write a small configuration file, but that's it.

For small organizations. I would say there is probably value in having this knowledge kind of embedded in the entire team so that everybody has a responsibility towards implementing the DevOps practices and then thinking about them as they are developing the applications.

More articles ⤵