Share this

How to Know if Hiring a DevOps Consultant is Right for Your Business

DevOps is a set of tools and methods to get your applications from Dev through Deployment to Operations. It automates a reliable path from my app runs on one machine to my app is online for all users and data, secure, scalable, managed, and maintainable.

DevOps isn’t inherently harder or easier than writing application code -- but it represents a different set of engineering tasks, using a different set of tools and skills. For most IT and software engineering groups, improvised measures consume too much of their best talent and time, at the expense of releasing new features that would satisfy end users’ needs. It’s time to streamline and automate the “IT Factory.”

Do I need DevOps at all?

DevOps is taking the world of online computing by storm. You probably need this suite of technologies if you develop or deploy custom software, or customized IT solutions, running on servers. Especially if several of these apply to you:

  • You care about maintainability and deploying new versions.
  • You want to increase productivity and/or reliability through automation.
  • You need to prevent the introduction or security holes.
  • You want to take advantage of cloud features like fault tolerance, auto-scaling, virtual private clouds, or configurable security.
  • You want Continuous Integration, in which new code results automatically in new builds and automated testing.
  • You want Continuous Deployment, in which new builds result automatically in upgrades to the software running on servers.
  • You need to manage a large number of physical or virtual servers.
  • Downtime would be severely disruptive to your business.

Signs a DevOps Consultant is Right for Your Business

Working with a consultant is all about bringing in pre-existing expertise, so that you can focus on what you really do for a living. A qualified consultant has worked on many previous DevOps projects much like your own, knows the DevOps value and is not treating DevOps infrastructure as a “side project” but a central focus. You want to benefit from a team that has lived and breathed DevOps technology, and loves working on it and teaching it.

Most companies smart enough to develop their own IT solutions are smart enough to become DevOps experts if this were their top business priority. The hard decision that needs making: is this really what you want to spend your best engineers’ time on? And the easier question: is it really efficient to reinvent the wheel?

It is very easy to download, install, and take a look at nearly any DevOps tool. But what you’re really paying for is the knowledge and hard-won lessons: the ability to choose the right tools from the toolbox, match them up to the problems and goals you’re facing, get the most of their strengths, and move swiftly around each technology’s weak spots.

The DevOps assessment

When you bring in a DevOps consultant you’ll probably do it because you have a specific project on mind -- something like “I’d like continuous integration” or “we want continuous deployment of our good builds onto AWS cloud servers” or “put our app into Docker containers managed on Kubernetes” or “make sure this app’s going to scale because more users are coming” or “make this analytics app consume many more sources of input data.” That’s as it should be: you’re focused on meeting specific goals right now. But you should demand more.

Risk Assessment.jpgA good DevOps provider will want to do a survey to understand what problems you have already solved, that can be taken advantage of in any solution. And what you want and expect your deployment and operations to look like in the future, so that any chosen technologies help to advance you along that roadmap. And they should be able to help you refine and improve that roadmap, bringing in ideas and expertise they’ve already developed working on prior projects.

Very early in your relationship, you should be asking them for this kind of DevOps evaluation -- whether it’s FP Complete’s Cloud Readiness Assessment or whatever report card or technology survey your chosen provider recommends for you. You’ll be right to ask these questions:

  • Where are we already doing good DevOps work, that should be kept and even spread through more parts of our organization?
  • What improvements should we plan to make, given the priorities we’ve described?
  • Of these improvements, which ones do we seem on track to accomplish, which should we add to our insourcing plans (implement it ourselves) given our existing skills, and which would be more efficient to get from our DevOps provider?

A good DevOps provider should not ask you to swallow a master plan for a massive, all-at-once conversion of your company’s IT systems. That’s far too costly and risky. Instead, a staged rollout is advisable. An assessment should provide ideas for helpful, self-contained projects that can be delivered within several months, and further follow-on projects and broader rollouts that can follow those successes. You should have the ability to continue or discontinue your relationship based on initial results delivered within the first six months, often even sooner.

What should I insource?

Don’t consultants want to do all the work for you? Ideally, no. DevOps consultants used to dealing with serious technical teams understand that you are well equipped to do quite a lot of DevOps yourself. It’s a question of priorities and time-to-market (time to learn and prepare), not a question of whether you can design a complete DevOps system yourself. Consider whether you really ought to.

If you’re in FinTech, you probably want your engineers working on financial models and better analyses -- not making sure that your Continuous Integration system runs, your Continuous Deployment system works, and your data feeds stay connected.Insourcing and Outsourcing - Small.jpg

A good consultant should have a  serious dialog with you to understand what you want to have as part of your team soon, what you want to have as part of your team eventually, and what you’d rather never have to think about.

In general, we recommend you insource (A) things you are already very good at, and (B) things that you expect will be core sources of the value seen by your end-users: things you are going to list in your advertisements. You’ll be happy to tell upper management that this is where you’re spending staff time. (Or if you are the boss, you’ll be happy to see that your staff are spending company time meeting actual user needs.) Is your value to your customers partly about how you interact with your cloud provider -- or is this necessary but uninteresting to them?

Insource what’s core to your customers and your business. Use consultants for what’s not. This is “consultant as specialist and outsourcer.” Use consultants too for future core areas where you don’t have expertise , including training (knowledge transfer) as part of the deal. This is “consultant as specialist and mentor.”

A word of caution: there may be cool technologies your people find interesting and fun, where insourcing isn’t the optimal business decision. Don’t ignore the benefits to staff morale of letting them keep a hand in things.

What can I demand from DevOps service providers?

You can expect both consulting work , relying on high-value engineering expertise up front, and routine work, relying on the ability to efficient handle a routine task over time.

A DevOps consultant should break your problem into solvable chunks, and assign properly trained and seasoned engineers to choose and integrate the right tools and DevOps processes (and occasionally customize or create a tool, if needed). You should expect to show them your current systems, but you should not have to specify exactly what tools they must use to meet your needs -- unless you have favorites that you want to insist on.

You should expect a DevOps consultant to provide you with not just recommendations and designs, but to actually implement these solutions, and transfer control of them to your own engineering team at a time of your choosing -- usually in a gradual, graceful handoff with proper person-to-person training as well as documentation.

Based on how you like to work and staff, you’ll need to decide how much ongoing work you want done by a DevOps service provider, and how much you would like to insource. The rates for outsourcing routine work (like server alert monitoring) should be lower than the rates for serious engineering support work (like setting up new cloud systems for increased disaster resistance, or speeding up your build).

At FP Complete we typically prefer to work closely with very smart engineering teams on the client’s side, solving hard problems jointly, so that the client is always free to take the reins on tasks they find interesting and high-priority -- and always free *not* to take the reins on tasks they find distracting away from their line-of-business, or tasks where they prefer to have our constant cross-company expertise involved.

First, use your DevOps service provider for tasks that require expertise you haven’t had the time to develop in-house, but take advantage of their knowledge to jump-start exactly this expertise in your team so you’re not permanently dependent on the DevOps provider. Take over routine tasks when ready after they’ve trained your team, and have your DevOps consultant move on to more tasks that will take advantage of the expertise and brainpower you’re paying for.

Second, use your DevOps service provider for tasks that require a level of focus that it’s not realistic to build inside your own group given the many distractions, mixed priorities, and rules you have to deal with. Don’t want to have a 24x7 monitoring staff? Have your service provider do it. Don’t want to explain to management why your team is using a cutting-edge tool that other groups haven’t adopted yet? Have your DevOps service provider run it.

How can I assess and choose a DevOps consultant?

While DevOps talent is in short supply, you still have a choice of vendors. Your DevOps vendor will be an important part of your engineering effort, at least for a while. Choose them as thoughtfully as any experienced member of your tech team: as a manager who’s hired hundreds of tech staff career, I find the same kinds of questions pertain. Consider these:

  • Have they delivered projects analogous to mine, for satisfied clients who resemble me?
  • Are they smart enough to interact with my team at our level? Do they really understand the world of developers and original solution creators?
  • Do they have much more experience with a range of DevOps problems than my typical team member?
  • How is their expertise with the technologies we expect to need next? And how is their track record picking up new things cost-effectively?
  • Do they know how to listen and learn about what we have and what we need? Do they understand the concept of requirements and priorities?
  • Do they know when to reuse existing tools instead of writing something new?
  • What comes with thier service? Will I have access to colleagues with other skills?
  • Do I believe they can work successfully offsite and remotely? How will we be interacting?
  • Are they team players? Will they transfer knowledge to my team, to grow our own skills?
  • What’s their background? How impressed am I with their cumulative education and experience, pertinent to DevOps work?
  • Are they focused on a low hourly rate, or high productivity per hour or dollar?

If you can ask a list of questions like this and be happy with the answers, you’ve probably found your DevOps provider.

For More Information