At the turn of the previous century, General Motors and other car manufacturers built huge factories with all of their machinery and forges that were needed to melt the steel. Everything that was necessary to create a car and get it out the door was on-site.
While you may have an innovative product, just like GM had back in the day, a lot has changed since then and you no longer have to do everything yourself. DevOps as a service allows your engineers to focus on the most important thing, your product, instead of having to worry about the infrastructure.
Many businesses all over the world are trying to harness enterprise DevOps as a way of providing software and important updates to their customers, but it is still very challenging for them to implement the DevOps workflow. You will need to find a top-quality provider who brings with them tested CI/CD patterns with a lot of automation mixed in, which will allow you to focus solely on developing and improving your product.
In today’s ever-changing IT landscape, there are tons of IT services companies and agencies that offer DevOps as a service solution. Therefore, how do you separate the good ones from the rest and decide which one works for you? Is it just a matter of technical skills and knowing the DevOps best practices? In fact, it is a combination of technical skills, DevOps knowledge, and plain old consulting skills. Here are some of the things that you will need to keep in mind as you embark on your quests to find a DevOps service provider.
When you have the first meeting with a potential provider, be sure that they are actively listening to what you are trying to convey to them. They need to get the problem statement.
A good DevOps provider will ask you for your feedback in terms of whether or not they understood all of the problems correctly. The keyword here is empathy. They need to be able to put themselves in your shoes. If they were the customer, they would want their service provider to echo the problem statement before getting into all of the DevOps metrics.
Many DevOps providers, especially the most experienced ones, will act instinctively. They have been there, they have done that and they will be in a hurry to start suggesting possible solutions and DevOps KPIs to monitor in order to reach them. Therefore, if the potential service provider is putting in his two cents about release and deployment management or anything else while you are in the middle of describing the problem, this should be a red flag early on in the process.
Also, if you invited them on-site and asked them to identify processes that need to be changed, they should spend at least one week at your company in order to identify inefficient processes. Otherwise, if they spend too little time on the site, what will happen is that they will jump right into implementing a solution to reap all of the benefits of continuous integration. For example, halfway into implementing this process, they will encounter some sort of obstacle that could have been identified and averted from the outset.
Therefore, in addition to inquiring about their technical skills, experience, and overall DevOps IQ, make sure they empathize with you and approach the job methodically.
DevOps is sometimes referred to as “Agile Delivery” since DevOps and Agile are closely related to one another. If we extrapolate this further, many out there think that DevOps implementation is something that can be achieved exclusively in Agile teams.
While most experts would agree that you can fully take advantage of the DevOps methodology inside Agile teams, your company may be using the Waterfall model and there may be some good reasons for this. If this is the case, then DevOps consultants must be able to come up with concepts that can be implemented in order to give you some quick wins. For example, this could be reducing the build and deploy time from several hours to minutes. Such an objective could be viewed as something flimsy by the service provider, but it could take a lot of pressure off your team and allow them to have the necessary time available to look for other things to optimize. If over the course of such optimizations you realize that you are mirroring some basic Agile methodologies, then you should think about making a commitment to such a change.
However, the DevOps provider should not push on your Agile processes as a mandatory condition of implementing DevOps processes.
The DevOps service provider that you hire should have at least five years of experience with automation tools such as Puppet, Ansible, Chef, and SaltStack as well as a high level of proficiency with Python, Ruby, PHP, and Java. They should also be familiar with continuous integration tools Jenkins, CruiseControl, CruiseCrontrol.NET just to name a few. It will also be tremendously helpful if they have experience deploying code, database management, system design, and experience in software architecture.
When interviewing candidates, be sure to ask if they have any project management, risk management, or Scrum Master certifications or at least some experience in these fields. It is not important where the service provider is located since the one that best fits your specific needs may not be in the same city, state, or even country.
It will be necessary for the DevOps consultant to travel to your site location anyway in order to observe and study processes and provide a recommendation on how to fix them and in today’s world it is possible to travel from point A to B in a relatively short amount of time and on budget.
While the service provider does not need to have experience in your particular business area, they should very clearly understand that the business needs of your company and technological changes need to go hand in hand. Everything they do must be based on sound business principles. Be sure to discuss all business outcomes that you would like to see as a result of DevOps implementation before discussing any procedural changes.
While the demands for a DevOps consultant are extremely rigorous, the demands for your engineers are not much lighter. They should have strong automation expertise, capable of designing the building and operating a software stack, and an expert skill level in either Docker, Chef, Puppet, Jenkins, MongoDB which will all be project-specific. Just like with DevOps consultants, engineers need to have soft skills as well. This includes empathy, communication skills, integrity, and a desire to continuously improve and develop their skills.
Most DevOps solution providers are working with many clients and it could, therefore, be very easy for them to start talking about how ineffective the processes are at your company and, most often, the more experience a service provider has, the easier it will be for them to get into this judgmental state.
A good DevOps service provider will do everything they can to avoid such a mindset and try to look for the underlying reasons why such processes exist, to begin with. Instead of telling you how terrible everything is, they should start asking you questions about why you decided to go with such processes. For example, if your build time is two and a half hours, instead of getting in your face and telling you about it, they need to get inside the problem and solve it. Perhaps you are using an old ANT script?
Maybe it’s something else. The bottom line is that they should not come in and be judgmental from day one. They need to get acquainted with all of the processes and then provide their feedback, find out why you are using them and then provide solutions on how to fix it.
There is a lot of information about Agile and its methodology out there that the human element gets lost. If the team members just simply do not get along, it is going to cause problems regardless of methodology. The DevOps service provider needs to be able to assemble a team that understands each other’s problems and is eager to help one another.
In order to assemble such a team, the service provider needs to set an example themselves.
They should organize a team lunch once in a while, promote daily stand-up meetings, talk to the team members in order to address their concerns. You do not need a group of cold unresponsive people, because that is not the definition of a team.
From my personal experience, there was a product team lead who did not attend the stand-up meetings because there was “higher priority” work. As you can imagine, this caused a lot of frustration among other team members since there is no point in having such a meeting to begin with if the team lead does not attend them.
Therefore, the service provider needs to know how to mesh and mold a true team together, one that is on the same page and has the same priorities.
If you do a quick Google search for “DevOps continuous integration tools” or any other tools for that matter, you will be inundated by an avalanche of tools. Pretty much every DevOps consulting service has worked with or provides these solutions and all DevOps solution providers have their own favorite tools.
What ends up happening is that they take their favorite tools and try to fit them in any way possible at every client site there are sent to. Also, they will try to impress you or boost their own ego by throwing the names of all of these tools and babbling about their features.
In most situations, the client is not so tech-savvy and is simply looking for a solution to a business problem. If you bring in somebody for an interview and they start throwing a list of tools at you or using some technical jargon, this is a sign that this is not going to work.
What we suggest is selecting a process that you would like to fine-tune and speaking about this with the prospective service provider. For example, if you are just trying to optimize a build process and they start talking moving the application to the cloud, dismantling a monolithic architecture and 20 tools do it with, take your business somewhere else.
This does not mean that they should not provide you with information on how to optimize ineffective processes, but they should proceed in a gradual fashion. They should provide you with a problem statement, ask if you are willing to think a couple of steps into the future and, if the answer is yes, they should proceed with some grandiose changes.
In fact, the mark of a good consultant is someone who will try to tone down the jargon and explain everything to you in terms that you can understand.
Taking a team that is used to doing something one way, and instilling an Agile mindset and embracing enterprise DevOps will not happen overnight. In fact, it probably will not happen even two or three months later since there are thought processes and working habits that will need to be changed. They should not fight their way through this because this will only increase animosity, hatred, and resentment towards them and they will become increasingly frustrated themselves as well.
A good service provider will sit down with you to have a pow-wow and agree on expectations. When drafting the statement of work with the provider, they need to understand that patients will be necessary and things will probably not run as smoothly as they think and account for all of this. In many situations, an open-source tool, that they may feel is obvious, can take months to adopt. Ask the service provider questions such as how this change will affect DevOps security. What will the change management processes look like? Who will be the business owner and the technical owner?
Speaking of security, there are not a whole lot of DevOps consulting firms who are focused on security from the very beginning, yet security is a key part of the DevOps methodology.
Back in the day, security was the responsibility of an isolated team at the last stage of development. This was not such a big problem when the development cycle lasted for months or even years, but those days are long gone.
A good DevOps outsourcing provider will get security teams involved from the very beginning and create a plan for security automation. This includes determining the risk tolerance and performing a risk/benefit analysis to determine the security controls necessary inside a given app. Just like with the regular DevOps methodology, DevSecOps also requires automating repetitive tasks because it could take a lot of time to perform security checks manually inside the pipeline.
Many DevOps consultants tend to work on a project for a long time and, as a result, they will get stuck in the swamp of everyday deliverables. They will put more priority on the deliverables instead of becoming acquainted with new technologies to stay current with the market. They need to understand that even though they just spent many years working on one project, they need to be able to shift gears and work on something that may be completely different and whatever they did in the past is totally irrelevant.
Did they do any self-learning to be aware of the new technologies on the market? If the answer is “no’ then this is definitely a bad sign.
Most DevOps solution providers are working with many clients and it could, therefore, be very easy for them to start talking about how ineffective the processes are at your company and, most often, the more experience a service provider has, the easier it will be for them to get into this judgmental state.
A good DevOps service provider will do everything they can to avoid such a mindset and try to look for the underlying reasons why such processes exist, to begin with. Instead of telling you how terrible everything is, they should start asking you questions about why you decided to go with such processes. For example, if your build time is two and a half hours, instead of getting in your face and telling you about it, they need to get inside the problem and solve it. Perhaps you are using an old ANT script?
Maybe it’s something else. The bottom line is that they should not come in and be judgmental from day one. They need to get acquainted with all of the processes and then provide their feedback, find out why you are using them and then provide solutions on how to fix it.
While this one might appear to be a no-brainer, setting and keeping up professional integrity is pivotal.
Think about it, you are bringing in somebody who your team members will look up to as a role model, somebody who you will be investing a lot of trust in, granting authority and expect to be a leader providing out-of-the-box solutions.
Everybody will always be looking at them and have tremendously high expectations. They need to be able to convey a message of trust and authority simply by the way they dress, act and go about their business.
The DevOps provider that you choose will have to come in and implement DevOps best practices in order to come up with the necessary solutions to the various challenges that you are facing.
Therefore, do not hire a DevOps provider who believes that DevOps workflows are focused solely on automating mundane operations with the cloud infrastructure. In fact, they are capable of so much more. They need to embrace the entire culture that is DevOps.
Everybody out there is familiar with all of the tools and technologies, therefore the consulting skills that they possess are something that you should focus on. This includes interpersonal skills, educating team members, assembling teams, looking professional this is really what separates the good consultants from the rest.
Subscribe to our newsletter and get the latest insights that help you stay ahead of the curve.
© 2017-2024 All rights are reserved
