DevOps in the cloud: Best practices and pitfalls for cloud deployment and development from Copado

Source:zdnet.com

David Brooks, VP of Products at Copado, explains how companies can use DevOps for large-scale cloud deployments and how to avoid common cloud development mistakes.

As cloud computing implementations grow in size and scope, successfully managing the deployment of and development process for those services becomes ever more challenging. And when companies attempt to use traditional software development practices such as DevOps with their cloud services, they often run into unique problems.

To better understand how companies can use DevOps for large-scale cloud deployments, I spoke with David Brooks, Vice President of Products at Copado, which provides a DevOps platform for the Salesforce Platform. Prior to that, David was the initial Product Manager for the Salesforce AppExchange. The video of my interview with Brooks is embedded at the top of this article and a transcript is below.

Today’s cloud computing systems are massive and worldwideBill Detwiler: What makes large-scale deployments of cloud services different and potentially more difficult than traditional on-prem systems and software?

David Brooks: Well, the first thing I would say is scale. The cloud systems today are massive. They’re worldwide. When we got into this game, we saw implementations that were bigger than we expected. You have to remember it’s worldwide users, it’s not just a single organization located in North America with maybe two cities and a couple of hundred users or even a couple of thousand users. It’s tens of thousands of users around the world in multiple time zones, 24 hours a day. The sun never sets on some of these implementations today. There’s hundreds of environments that are involved in this. The velocity with cloud, back in the day when you were releasing an ERP application, your systems of record changed once a year, once every couple of years. How many times do you do a SAP upgrade, right? Not very often if you could help it.

But with, with CRM systems, with sales and marketing and service, you’re doing releases a couple of times a month because your processes are tweaking. And when it comes to systems and engagement, when you’re talking to your customers and your partners and especially with IoT and some of the systems that you’re integrating with today, you’re doing multiple releases a day. So the velocity of release with cloud systems is just much faster than what you had to deal with in the past with some of these on premise systems. And the level of sophistication, a cloud platform is already sophisticated itself, but then you’re also talking about integrations. You’ve got integrations with many different other systems. Imagine that your system provides a map. Well, you don’t do the maps, you integrate with Google maps. And if you’re doing an IoT, you’re going to be tracking devices through some other kinds of service. You may want to bring in weather. So you’re connecting to a weather service and then your external data that you’re connecting with.

So all of these external systems effectively entangle. They’re entanglements and they’re making it more difficult to really isolate the system that you’re working on because you have all these other things to worry about. And security, security is just through the wounds. I don’t know if you saw lately, recently you saw a Marriott was given a $123 million fine for noncompliance with GDPR. That was probably due to some small release that they did that accidentally exposed data to somebody. British Airways fined $230 million because they put data for 500,000 customers at risk. So DevOps is not just release a small feature here and there and then be done with it. The cost of doing it wrong can be actually really, really important and really, really large.

And it’s 24-by-seven service. As I said, the worldwide user base means there is no downtime. You can’t upgrade at midnight because midnight your time is not midnight in the middle of your customer base in Thailand or in Japan or in the middle of Europe. So these releases have to be done with no downtime. You have to be able to incrementally upgrade these systems and provide more functionality because it’s just always on and always there. And again, you want to be predictable and reliable and secure because if you don’t, then you’re going to get slapped with some of these fines even though you’re a U.S. company. I mean, getting slapped with a $123 million fine is not fun.

How to use DevOps for enterprise cloud projects

Bill Detwiler: How can DevOps help companies handle complex cloud deployments and avoid downtime?

David Brooks: Well, it starts with the process. We had several customer advisory boards in Boston and Dusseldorf where we went in and asked our customers, what could we do to make our platform better? And what we got was kind of a surprising answer. We were expecting something about the tools and the processes that we manage and what we got was help us to understand how to improve our process, our delivery process, our strategy. And so what we’ve come to find out is that increasing your velocity and increasing your time to value in the marketplace is in some ways more about making sure that your team is disciplined, that they have the information that they need, that they have the training that they need and that you have a set of tools or a platform like Copado to actually work with you and your process.

For example, we worked with Cox Automotive in an implementation and they were coming up to speed on our platform and they started out, they had more than a hundred developers. And just as something as simple as how do I integrate the changes from a hundred developers working in parallel and reliably integrate those, merge those and get those into the production train becomes a real challenge for very large platforms and teams. And what happened was they came up with the strategy and that was good. They came up with a strategy and they tried that and it worked, but it didn’t work as well as they wanted it to. And so they were able to iterate on that. So it’s not just putting together a delivery process and a strategy, it’s being able to iterate on that strategy and make sure that your processes are working and it’s the whole ties in idea that it is going to be continuous improvement of your process. And so it starts with getting that process and that that strategy put in place.

And then having an enterprise class DevOps platform that can give you the tools and the process and the training that you need to execute on these processes and so that you can really get on your fastest path to innovation, just making sure that that whole delivery speed and velocity is going up. And the other thing that I would say is if you’re looking for a DevOps platform, that you need to have a native platform that’s native on the platform you’re developing on because the best way to actually make sure that your processes are working is to use tools that are on the same platform that you’re developing for and giving people a native user experience on that platform.

DevOps best practices for cloud development and deployment

Bill Detwiler: What are some best practices companies can follow when incorporating DevOps into their cloud strategy?

David Brooks: Yeah, so the first thing to recognize is that companies are at different levels of maturity and different levels of adoption. So companies are at different levels, but the individuals in those companies are at different levels as well and recognizing that allows you to start focusing on your best practices. And we came up with a strategy, a model that we call Pathfinder and in the Pathfinder model, we’ve tried to simplify it to the point of talking about five levels of maturity.

And the first level, for example, the developer operations would be select and deploy, where you’re just, you’re starting out with baby steps, being able to take the changes that you made and move them to the next level, going all the way up to a continuous integration, continuous deployment, continuous delivery of functionality. But it turns out that you can’t think about best practices in a single, solitary ladder of success. There are multiple ladders of success. And so when you’re looking at your DevOps program, there’s seven stages of DevOps, right, from planning all the way up to deliver, deployment and release and monitoring. And agile is part of that and if you look at that whole process in DevOps, each one of those seven phases really has several different ladders to success.

Let’s take one, verification. Verification, if you want to get to a continuous delivery, then you need to get really good at automating the validation, automating the quality of your product along the entire way. It’s not only one ladder, it’s SCA, it’s functional testing with something like Selenium, it’s actually compliance. This whole security thing that we talked about earlier, you need to make sure you have some kind of an automated compliance tool because a small change by somebody can really make a big difference. So even within one segment of that seven phase of DevOps process, there are multiple ladders of success that you need to worry about.

So my first recommendation would really be to sit down and look at your process and understand the different phases and understand what you’re doing there and kind of be really honest with yourself about the the grade that you would give yourself on that process and figure out how to get better. Everybody being on a different level is, there’s a great example of that. We worked with MassMutual a couple of years ago, and this was a great example. They got very frustrated with Salesforce in the beginning of their platform experience there. They had only had about 20 or 30 developers working on Salesforce and it was a new DevOps platform for them and so bringing in Copado was an interesting process for them because in addition to bringing in a new set of tools and a new DevOps platform, they had to bring in a new process and they had to iterate on it and they had to really look at what they were doing in each one of these segments with the best practices. How were they using their agile tools?

And if you use, one other very important thing is using a version control system as your source of truth. We find in a lot of companies in a Salesforce environment that they’re using the actual platform itself as the source of truth and you just can’t do that. You need a version control system like Git to do that. And so if you look at that front end of your DevOps process and how you’re using your version control system, even things like what kind of branching strategy am I using? I don’t want to get into the weeds and and into the nuts and bolts, but how you actually form the branches in your version control system has levels of maturity and levels of improvement opportunity for you. So when we were working with MassMutual, we went with them and looked at their process at all those various stages and helped them to understand where they were and where they could improve and where they could move up that ladder of success with each one, and doing it holistically but also individual phases results in an opportunity to move up and up that ladder. So, it’s a matter of looking top down, but it’s also a matter of bottom up trying to improve each of these processes.

And that brings up another thing, one of the other best practices that we found is collaboration. You’ve got to be, we say DevOps is a team sport. It’s not just an individual holed up in his cube a cubicle trying to do a little bit of development and passing the code onto, throwing it across the wall to somebody else. You’ve got to collaborate between the developers and the release managers and the QA people, but also the business. And then there’s another aspect of it in Salesforce. When you’re dealing with a no code are low code platform like Salesforce, you think about DevOps as being for developers. But in fact, DevOps is also for your point and click admins and what Salesforce calls accidental admins.

I mean in back in 2002, 2003, I helped to install Salesforce into a company, and I was the admin. I ran the admin team for this company. And I was not planning on being an administrator. I tell you truthfully, I was kind of forced into the role because I was the best guy for the job at the time. But these accidental admins all over the world now on Salesforce are getting in there and they’re going, I don’t know what DevOps is. All I know is I think I can go into setup and I can make these changes and I can save them and my job is done. But you really, a best practice is to get these admins together on the same page as developers. And what does that mean? That means, people think it means that the admin has to know how to use Git, has to go into agile and agile tools like Jira and be able to deal with user stories. And the reality is that they don’t.

If you have the right platform and the right DevOps tools, then you can get on the same process and get on the same page as developers. But it is really important that every member of the team that is working on these changes in your system are on the same process. Cause it’s just death if you have half of your developers are on one process and your admins are sitting off doing something on their own. It just doesn’t work.

Mistakes to avoid with DevOps and enterprise cloud projects

Bill Detwiler: What are some of the biggest mistake that people make when they start a major cloud deployment and upgrade project?

David Brooks: The biggest mistake is they think they can bring a new tool in, they can configure it overnight and then it can just work for them and get done. And so the biggest, as I said earlier, you’ve got to take a look at the process and you’ve got to figure out, okay, are we automating something that’s reasonable? Because the biggest truth is if your process is broken and you automate it, you are going to fail faster. But people say fail faster in the startup world, but fail faster has a much bigger cost in the enterprise world and it’s not the kind of failure you want. You want to be able to make sure that process works, automate a piece of it.

The other biggest challenge or the biggest mistake is people trying to go in there and change everything all at once. I think the one thing that agile has taught us is it’s small tweaks, right? If you look back at the that movie Contact where he says small tweaks, Ellie. Make small changes on your radio dial so that you can dial it in and get going then and get something working and make the progress. And it’s like climbing a hill. You’ve got to climb that first hill and then you’ve got to take a breath and turn around and enjoy the fact that you’ve got to a plateau and don’t try to do every process at the same time.

So for example, when we get Copado installed in our biggest customers, we say, great. Let’s take a step back and let’s figure out how we’re going to get the change management part, the release management part of it done first. Let’s hook into your existing agile system. Let’s hook into your existing GitRepo and let’s do that first. And then once that’s in place, then go to validations. Are you doing selenium testing? Are you doing static code analysis? Are you doing a compliance tool? That you have external Jenkins or team city scripts that you’re running for this? I mean, let’s start doing that. So the biggest mistake would be to try to do everything at once. And the biggest tip I could give would be don’t try to do that. Just go in step by step and collaborate and iterate and bite off a small piece and master that and then move on to the next one cause the job is not done at the end of the implementation. The job is just beginning and it’s all about continuous innovation within your process as well as your company.

ZDNET’S MONDAY MORNING OPENER

The Monday Morning Opener is our opening salvo for the week in tech. Since we run a global site, this editorial publishes on Monday at 8am AEST in Sydney, Australia, which is 6pm Eastern Time on Sunday in the US. It is written by a member of ZDNet’s global editorial board, which is comprised of our lead editors across Asia, Australia, Europe, and North America.