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.”
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:
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.
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:
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.
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.
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 24×7 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.
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:
If you can ask a list of questions like this and be happy with the answers, you’ve probably found your DevOps provider.
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.
