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.
A 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.
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
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
Do you like this blog post and need help with Next Generation Software Engineering, Platform Engineering or Blockchain & Smart Contracts? Contact us.