Abdelfetah Sghiouar is a Cloud Engineer at Google and was one of the speakers at the Devops2020 event. Our Squadians had the pleasure of interviewing him. We discussed the latest DevOps and Cloud trends, as well as what the future holds for organizations that have begun their journey toward a cloud-based infrastructure.
Squad had the opportunity to attend your conference at DevOps 2020 on the Google Cloud platform. What will be the major trends in cloud computing in the coming years?
This has been a hot topic lately. If you read articles in specialized media such as Gartner, you will see "By 2020, all businesses will be in the cloud."
I've noticed something: CTOs and CIOs have a better understanding of the issues at stake. The company's core business is not IT, so there's no reason to get involved in IT. It's better to let someone else who is qualified take care of it and switch to a cloud infrastructure.
It's cheaper, more resilient, and more secure, because you can't hire security experts like Google or Amazon who have the capabilities to do so.
Companies, like service providers, want to be increasingly compliant, with the transition to multiple certifications, particularly to meet the needs of businesses.
So there is real added value in moving to the cloud. If we look back 20 years, the IT lifecycle was different. It all started with the purchase of several servers for a few million euros. You used them, you bought the infrastructure, you hired staff, you operated them, and five years later, your infrastructure became obsolete. So you had to buy more, and you entered a new cycle.
If companies do not have the financial means, they will not be able to purchase more infrastructure after five years, especially if it is too old.
Thanks to the cloud, the "Pay As You Go" model allows you to pay only for what you use. You can reduce or increase your budget, and it's easier than having servers in your own data center.
What do you think the limits are?
Today, the problem I see is that the cloud requires a lot, not only in terms of technical aspects, but it also requires a major change in corporate culture.
That's why we really talk about a "journey" to cloud transition, because it's not like we have to flip a coin. It's a slow transformation, because not all IT systems are optimized and providers don't offer everything you would want in a data center.
Another trend is that cloud providers are trying to bring the cloud to the customer. We are seeing companies offering a service that you can set up in your physical infrastructure, while being managed from a cloud platform. This is commonly referred to as a "hybrid" or "multi-cloud" platform.
This is an interesting aspect and a challenge for the coming years, because doing so offers real added value in the sense that customers will be able to carry out their transformation more "slowly."
There are other aspects: large companies that we never imagined would turn to the cloud are now doing so. Lufthansa, one of the largest airlines, which has been around for hundreds of years, has a very old SAP (* Systems Applications and Products) system.
They understand the benefits of transitioning to the cloud. We will see many of these big names choosing the cloud. It's only a matter of time, as I said earlier about the old systems and servers that companies have today.
Regarding organizational challenges, do you think that one of the biggest challenges of DevOps is more of an organizational transition or a technical transition for the operational team?
I think it's a bit of both. But I would say it's more of an organizational and cultural transition than a technical one because, at the end of the day, it's just code, isn't it? It's just lines of code.
Implementation is not the difficult part. The difficult part, in my opinion, is adopting the DevOps culture.
There is too much to say on the subject. There is organizational understanding and then there is organizational will.
Organizational understanding involves understanding what DevOps is, which takes up 50% of my time. Because one of the problems I personally have is that "DevOps," taken out of context, no longer makes any sense.
There are lots of practices out there, but which ones make sense for your organization? This is, in a way, how you define what DevOps will look like within your organization.
The second difficulty is people's willingness to change the way they do things, because any change in a company means a lot of work.
To what extent are they willing to devote time and money to meet the challenge?
Is DevOps the future for software developers and all operations engineers?
I don't think so, even though companies have adopted DevOps. Let's start with this example.
Google is one of the pioneers of this "DevOps" culture. We have an SRE that resembles a DevOps implementation; they share similar aspects in terms of automation and working methods.
We have so many SREs who don't deal with software engineering. They have distinct roles and responsibilities.
There are cases where we need software engineers and others where we need them only for a specific aspect.
Software engineers who create banking solutions are therefore people with very specific skills, which are not only technical skills, but also an understanding of the business and the banking sector, as well as all the requirements and rules that make banking software "banking software."
Taking these people away from their work to convert them to DevOps adds no value, because they need to specialize in what they do. The same goes for people who work in AI, machine learning, and data science...
I therefore believe that a software engineer with a vertical specialty should remain so, while a software engineer without a specialty or with a background in automation should move toward DevOps.
Squad has embraced DevOps and DevSecOps by helping its employees develop their expertise through training and feedback. Do you think this is a good strategy?
It's definitely a good strategy if there's demand. Squad is a consulting firm, and there's a real need for it. Training or teaching software engineering, CD/CI design is undoubtedly useful.
People have been doing CI/CD without really knowing they were doing it for a very long time, and those who have been doing it for a while simply write Python or Bash scripts that do all the building and deploying on their behalf, because these scripts are triggered by a system and not by humans.
So, understanding that setting up a CI/CD pipeline, letting it run without thinking about it, means that a developer will be more focused on writing code than debugging the infrastructure. And that has value and is a good strategy.
If an organization has engineers who specialize in a single field, in a large organization, this is probably more productive, because they can build this common infrastructure for software engineers, so they don't have to do it themselves. In a large company, there is added value.
In a small company, you don't necessarily have the luxury of doing so because you probably have 10 or 20 employees.
So, integrating DevOps, with shared responsibilities, is probably the way forward until you reach a significant size that will allow you to have specialized teams.
Today, we work with companies of various sizes, and one aspect that is somewhat related to DevOps when it comes to communities is community cluster management.
It's more efficient and potentially safer. For example, we have clients from large organizations who, once we're there, want to create 20 community groups because they want one microservice per cluster. And I say to them , " Why do you want to do that? It's so unproductive," and " We're going to spread your knowledge across 20 teams."
We try to push these customers toward centralized operations and DevOps teams working on infrastructure software as developers: just code, a Docker file, a command, and then these developers don't have to worry about how it gets into production.
So that's what I would call "Google-style development," because that's how it works. Google developers are productive from day one. They have CI templates, built-in tests, and security features. They don't have to do any of that. They'll probably have to write a small configuration file, but that's it.
For small businesses, this type of knowledge needs to be integrated more fully into the entire team so that everyone is responsible for implementing DevOps practices and then thinking about them when developing applications.
