Suyash Deo: Good morning, David. It is my immense pleasure to have you on this podcast channel.
David Linthicum: Happy to be here.
Suyash Deo: Thank you. So, for our listeners, a real quick introduction: David Linthicum is a chief cloud strategy officer with Deloitte. He’s been in the industry for quite a long time. He is a speaker, podcaster and an author. So, David, it’s a long track record but I had to summarize in short. But again, thank you for joining the podcast.
Today’s topic is the evolution of DevOps in 2021. So, let’s quickly jump on some of the key questions. I’ll be asking very basic questions because our listeners are also non-technical and operational people.
Question 1 : What is DevOps and why is it inevitable for today’s businesses to adopt?
Answer : DevOps at the end of the day, if you look at it from a higher level, it is really the automation of agile, a better way to perform application design, development and deployment. This is far superior than the waterfall method which I actually started working on and was even teaching college, back in the 80s and 90s. So, the idea is that we’re going to, in essence, continuously improve the software through an agile methodology where we get together to deal with events versus some sort of a schedule or sequence, and how software is delivered.
So, DevOps really is the ability to automate that. And so, it’s the idea that we can actually code applications, say an application that runs on Linux, we can hit a button and it automatically goes through testing, including penetration testing, security testing, stability testing, performance testing. And then moves into a continuous integration process, then moves into a continuous deployment process and then is pushed out to a particular staging area and then it’s pushed out from the staging area to a production server.
The goal of DevOps is really kind of remove the humans from that process even though we haven’t done that completely yet. It is, in essence, to create a repeatable process as leverage with the number of tool sets that are working together to streamline the modification and delivery of software in a way that’s going to be better quality each time the software is delivered. There’s some cultural issues around DevOps as well, by the way, that are just important, it’s the ability to, in essence, understand that thinkers are going to be integrated iterative, the ability to deal with feedback directly from the testers and the operators, the ability to flatten the organization, and have a very open and interactive organization moving forward. And that’s the other side of the coin.
So people have a tendency to look at DevOps as just a tool chain with lots of cool tools, continuous integration, continuous testing, those sorts of things are working together, but it’s really a combination of a toolchain of process, and also a cultural change that’s probably more important than any of the technological changes.
Question 2 : How is DevOps complementing agile from a practical implementation standpoint?
Answer : Again, DevOps is really going to be very much of the automation of agile. So Agile is going to take a cultural change, an organizational change in order to make it effective. And ultimately, we’re leveraging a toolchain within DevOps as a way to automate everything that occurs in an agile environment. So, if we’re getting together on a daily basis to form a scrum and we’re talking about what needs to be changed, then typically the DevOps toolchain is where those changes are going to occur. And so it’s the automation of everything that comes out of an agile environment and when it moves from testing to integration and everything, we just talked about in between and it goes into deployment and then we get operational feedback, also is an agile methodology.
So, the idea is that we’re able to deal with changes to applications and data sets at the speed of need. So as the business needs new versions of the applications and new versions of the database, we’re not going to make them wait anymore as it used to be where we had to make them wait for the next release of the software, we gathered the suggested changes, we put it into a product road map and we came up with some sort of a version number like 1.1, 1.2, and so on. That was allowed when I was in my CTO days.
Now we have no limitations as to when software is going to deliver and so we just deliver it on. We just deliver it out to whomever is going to, whoever needs it when they need, as they need it. And so, I have to drop three or four deliveries a week or three or four code drops a week. That’s perfectly fine. So, we’ll do it via sprints, some very robust and longer-term sprints, but will do it also in short sprints as well, which may take a few days. So, for example, if there’s a bug in the system, we’re not waiting a month for the bug to be fixed, and we’re able to get a version out.
The great thing is, I mean, if you’re dealing with the software as a service system like Salesforce.com and NetSuite, and those sorts of things, every time you log in to these environments, because we are agile and DevOps, chances are you’re running a new version of their software, but you never know as you don’t see 1.1, 2.0 or whatever. It just comes out as a version of their software, and so their version numbers really are kind of related to the moment in time and the sequence is not necessary to be bound to versioning sequence, so it’s a different way of thinking about development.
And you know someone who’s been in software engineering a long time, ultimately, is a lot more productive. But it wouldn’t be as productive today if we didn’t have the DevOps tool chains and the DevOps methodology’s in the concept of DevOps.
Question 3 : Apart from a cultural change, are there any other challenges which you might have observed that companies face while adopting DevOps?
Answer : Yeah, the big thing is going to be funding and also the ability to understand that there’s going to be an accordion of money that has to flow into the DevOps change. And typically they’re moving into cloud at the same time. So I always tell my clients if you’re moving to public cloud computing and you’re doing so for the utility aspect of it, and the changeability and scalability aspect of it, which mostly are, then unless you change your application development infrastructure, which typically now is going to be waterfall based into something that’s agile and DevOps based, you’re not going to be able to take advantage of what cloud computing is.
So I’m asking them to spend money on the migration to the cloud, which is going to be a lot of money, typically more than they typically spend on creating a DevOps toolchain and DevOps organization, and a cultural shift, and doing it at the same time, because you can’t have one without the other. I can’t build a DevOps toolchain and process and then be able to deploy these things on hardware and software. So, we’re building software for three or four hours and we’re waiting three or four weeks for someone to buy the hardware and software and install it into a data center. You know that obviously doesn’t work. So, the cloud is able to solve that.
And likewise, you’re not going to buy cloud if you’re not pushing that many releases of software. There’s no advantage of leveraging the cloud for not leveraging the provisioning capabilities of it. So, one fixes the other, and one can’t really have value without the other.
Question 4 : Do you feel that cloud computing has somehow fueled the need for DevOps?
Answer : I think so. I mean, the reality is, there is a symbiotic relationship. And so, if my clients are building a cloud and they’re still dealing with traditional waterfalls I mentioned earlier, they’re just not going to do that. And the business isn’t going to see the value either. And so they’re going to see that we spent 100 million dollars in this cloud migration and still want to go to the developers. I’m still hearing the word no. Each and every time I tell I need something done in a very short period of time, they don’t have the capability, even though they have the ability to run the platform and provision the resources that they need.
They don’t have the culture and they don’t have the development tools for automation to make that happen on the development side. And it’s the same if you go with just DevOps and you don’t have cloud as a target. It’s not as bad of a problem, but ultimately if you’re not able to allocate the resources that you need as you need them and be able to do so through an automated process on the DevOps side, then you’re not going to see the value you. So it’s truly a 1 + 1 = 3 kind of thing, and if you don’t have one or the other, you’re just not going to see the value in the other side.
Question 5 : Is there any set of tools which you normally recommend to get an idea about which tools are normally adopted or preferred?
Answer : Yeah, there’s a category of toolsets and it’s a great question by the way, so there has to be some sort of development tool, and so that’s going to be around whatever programming language and integrated development environment that you’re leveraging. And with developers. I never limit them to what they’re able to use. My advice to them is to leverage best of breed. In other words, leverage the tools you’re going to be most productive with in terms of developing and deploying software. Next would be integrated and continuous testing tools.
That’s the ability to absorb the system that the developers are releasing, and then run through a set of automated tests to ensure that the basic attributes of the application are intact. And by the way, if something is found and typically something is going to be found in the first iteration, then feedback is sent back to the developer to find what the issue was. And they have an opportunity to correct the problem and then push it back into testing, and these may happen in a matter of 1/2 an hour. This isn’t something that takes a half a day or half a week. And then once it’s tested and validated, it moves into a continuous integration system.
And by the way, you may do so in the reverse. You may have continuous integration first and then move it into testing then integrate various systems or various modules. In other words, if we’re changing just the user interface and not the backend system, there’s a point where we integrate everything together and make sure everything kind of comes together in terms of how it’s configured. We do configuration management, the ability to kind of leverage the application components as well as the infrastructure components that are supporting the application and get it ready as something that’s going to be attested and running as a combined piece of software.
Then we push it to the deployment phase and what the deployment phase is going to do is have a continuous deployment capability and the idea there is to prepare it for movement out into a particular platform. It could be the cloud, it could be on-premises, it could be anything and then ultimately the ability to operate those systems and so we do a few things there.
Number one we do some final testing and deployment. We basically localize the software. We do additional security checks, we move it out into the platform and reversion it, not necessarily with the version number but we keep track of it. Everything along the way is going to be logged and persisted, and so if something goes wrong, it’s all reversible transaction. If the deployment goes wrong and for some reason the software doesn’t work, we’re able to return automatically to the previous version, so we can get the business.
And we’re also able to push it back to the developer to find the issue and the problem and fix it, and then push it back down the line. DevOps tools are getting very adept at doing these automated systems. They are always going to be different. The DevOps engineers always have their own unique way of setting up these toolchains, but the idea then depends on if you’re using containers or serverless technology, or different databases, things like that. The idea basically is to automate everything as much as you can and provide feedback for each step of the way, and to remove a lot of the latency and billing in developing software.
Question 6 : There have been many security breaches around the world. So, DevSecOps has started gaining a lot of attention. How do you see security being managed through DevOps methodology?
Answer : Yeah, DevSecOps is actually a more apt term. I understand why people are saying it, but it’s also confusing because there are people saying DevOps whereas other people calling DevSecOps. But ultimately, it’s the notion that security is going to be systemic in everything you do in a DevOps toolchain or DevOps process, which is absolutely true.
In other words, we build security at the development stage, we build security at how we test. We certainly do security testing and penetration testing. We build security in how we integrate these various application resources. And we build security, certainly, at how we’re dealing with database binding and how we’re dealing with deployment. And so, it’s at every step of the way and everybody is responsible for security.
Where in the olden days, meaning three or four years ago, we had security engineers that were responsible for engineering security in the application. The developers didn’t really understand how they worked and they didn’t understand how the developers work, because it was an external, outside process that became the gatekeeper for the application. Well, that doesn’t work very well into a complex distributed environment. Then the application becomes the single most place to place security hooks to spot breach attempts and things like that.
Certainly, external security systems can do it, but it’s much better if the applications and the databases are able to defend themselves. So, this needs to be built in every step of the way. And by the way, that’s a cultural change. If I say to a typical development organization that you guys are also in the security business and you think about identity access, management, encryption, compliance, all these sorts of things, they’re going to call me crazy.
But the reality is unless they do it, being the experts in building and deploying the applications, there’s no one else that can do it on the list. The security engineers exist, but there are typically writing testing scripts. They’re just typically writing penetration testing. They’re running audits and not necessarily dealing with security using systemic tools and technology.
DevOps Survey
Take our short survey and grab your free guide now! Additionally, get a complimentary 2-hour consultation with our experts.
Question 7 : Do you feel it’s some sort of a sense of urgency for companies to adopt DevOps methodologies at an organizational level?
Answer : Yeah, it’s definitely risen up in the priority levels in the last seven months with the pandemic, where people were working remotely. And the great thing about DevOps is the kind of set up to deal with remote workforces, remote pods and remote sprints. So, only organizations that have a renewed interest in DevOps, whether they’re strong in the cloud or not, have the ability to solve issues in a very distributed way. Leveraging ChatOps, the ability to have people communicate went to another and remote collaboration and all these things that are kind of a part of DevOps that are coming together.
So, the interest, as always, has been there, but it’s accelerated in the last six or seven months because of the pandemic and also the acceleration in the cloud at the same time. So, they saw their systems are vulnerable that they didn’t know and they saw the vulnerabilities that they know existed. And in many instances, the pandemic quarantine towns where they couldn’t get into the data centers and fix things had outages, costing them as much as $1,000,000 a day. And they couldn’t do anything about it until the quarantine was lifted and they could get back in there and fix it.
People who are already leveraging the cloud didn’t have that issue. So, the scalability where other people were managing their infrastructure didn’t have to worry about quarantines or if their data center was wiped out or their servers were stolen, which actually I saw happen one time. All these sorts of things that can occur if you’re owning and maintaining your own data center.
So, the whole hug-your-server crowd in culture has kind of fallen by the wayside. And also, everything has to go through a sequence in order to be solid quality software which is also found fallen by the wayside. So that leaves DevOps, agile and cloud computing as the primary mechanisms for how people are going to deploy new applications and how people are going to port applications from existing data centers into the cloud. So, it’s beyond popular right now.
SUBSCRIBE TO OUR PODCAST
Question 8 : Where do you see the DevOps trend going in 2021?
Answer : I see that trend basically moving into remote work enablement. And so, even though we’re better at remote work enablement today than traditional development frameworks and ops models, it’s really changed in the ops models to change the world that we’re going to be living in over the next few years, even when the pandemic is solved and goes away, which it will eventually.
I think the fact that we’re able to distribute a workforce and still remain productive, in many instances more productive, has kind of changed the outlook and the expectations of how we’re going to build DevOps software.
DevOps is going to morph into how we’re going to do things in a distributed way. That’s going to be the most important thing, even though it’s able to do things in a distributed way today, majority of people who leverage
DevOps or teams that are physically coexisting in the same building, there is collaboration and communication. People are standing up in their cubicles and communicating one to another, which is all a good thing. Ultimately, that doesn’t scale. If you need to hire people who may not live in the town, who can’t get to that particular building and you don’t want to fly them in every week is a soul crushing thing. Your ability to be virtual is going to be your ability to be a strong company.
So, everybody is going to focus on DevOps capabilities. The tool vendors, you already see them ramping up their remote collaboration capabilities, the ability to sync configuration management on a centralized server, typically leveraging cloud computing and also cloud-based DevOps. Certainly, that’s been around for a while.
We’ve had aspects of a DevOps toolchain, Amazon Web Services, Microsoft Azure and Google Cloud platform, but they’re not everything. You still have to leverage third party systems that either install in the cloud or you may leverage them on premise, in some instances. Often, they need to move to a centralized cloud DevOps infrastructure where hopefully the toolchains can all run on demand. So, we’re not moving different eclectic platforms and maintaining different things where some of the stuff is on-premises and some of the substance on our computers. The whole thing really is going to be more efficient if it’s virtual. If it’s pushed out to a centralized system that everybody can access and therefore were not dependent on maintaining hardware and software, is going to free us to be much better at delivering software.
