Traditional ops often meant that you needed at least one, if not many ops personnel, to build and maintain your infrastructure. It wasn’t uncommon for your team to have to build a framework from scratch and deploy from it manually.
However, the desire for faster deployments with lower error rates led to the amalgamation of development and operations practices into what we now call DevOps. As DevOps culture grew, more and more tools and features became available that took care of core infrastructure functionalities, until eventually, we came to a point where some companies no longer needed an entire team of full-time DevOps personnel to achieve their infrastructure goals.
If that sounds like you, then it’s worth considering whether fractional operations could help you tackle your backlog and build a more scalable and robust infrastructure.
What are fractional operations?
Fractional operations or fractional ops teams, unlike part-time DevOps engineers, work for multiple companies throughout the week.
Working in person or remotely, fractional ops may perform most of the regular duties of a full-time DevOps engineer, including implementing automation, capturing infrastructure-as-code, as well as creating monitoring and alerting pipelines.
However, as they are not full-time, fractional ops will typically not take regular pager duties. In some cases, they may offer emergency pager during high-traffic times, like Black Friday on the e-commerce calendar.
At stack.io, our fractional ops team focuses on completing cloud infrastructure projects, which include, but are not limited to:
Migrating your infrastructure to a public cloud
Implementing CI/CD pipelines in the cloud
Optimizing your use of a public cloud
Deploying your applications to Kubernetes
Expanding the use of containers
And more!
How is fractional ops different from contract work?
Contract work tends to be one-time only projects, whereas fractional ops want to serve the purpose of a reliable third-party who can act as an extension of your team. Although fractional ops don’t own any part of your infrastructure and you’re not tied to them, the fractional ops model is intended to be a long-term relationship, where they will learn and understand your infrastructure, so that they can complete and upgrade components as needed.
The benefits of fractional ops
Apart from all of the regular benefits of having a DevOps culture, some of the benefits specific to fractional ops include the following.
Not being limited to hiring just one DevOps engineer
Everyone wants a unicorn: someone who has the skills and expertise to handle the entire stack. Some may call this mythical creature a “full stack developer.” However, the reality of the situation is that it’s difficult, if not impossible, to find a single person who has the entire skill set that you need to achieve your infrastructure goals. Understandably, it’s expensive to hire a team full-time, or even part-time, to fill out that skill requirement.
With fractional ops, if you outsource to the right place, you can have access to an entire team of experts for a fraction of the cost.
Only paying for the time that you use, when you need it
When it comes to workload, the pay-for-what-you-need model is great for companies on both ends of the spectrum. After all, in this cloudnative world, your infrastructure scales as needed, why shouldn’t your team as well?
If your web application only has occasional projects or upgrades, then the fractional model is perfect for hiring on a per-need basis.
On the flip side, if you have an extensive backlog, but you don’t have enough engineers to complete all the tasks, fractional ops allows you to hire extra hands without having to worry about over-hiring.
Getting access to extra knowledge and expertise
Of course, fractional ops are always learning too. And they make mistakes. But that’s how they learn to navigate difficult scenarios and solve complex problems (a legitimate team will always have retrospectives and/or postmortems to reflect on issues they come across).
As a result, there are times when your fractional ops hires may need to take some time to learn a new technology or methodology to complete the work. However, the real skill in this cloud-native world is not necessarily knowing the technologies or methodologies themselves, but the ability to learn new ones based on previous experiences. A strong fractional ops team won’t need to have firsthand experience to pick up, formalize, and master a new technology or methodology.
On the flip side, for tasks your fractional ops hires do have firsthand experience with, like setting up auto-scaling on a Kubernetes cluster, you can save a ton on time, money, and resources that would have been spent on learning the new technology or methodology.
Allowing your developers to do just that: develop
If you’re a smaller team that doesn’t have your own DevOps engineer, you may be relying on your developers to take care of your infrastructure. One thing that we’ve learned over the years is that developers usually don’t want to do infrastructure work. So, let your developers develop. Fractional ops can complete your infrastructure projects, so your developers can focus on your app.
Fractional ops myths debunked
The rise of fractional workers, not just ops, brings up some of the same concerns as remote work and flex hours. How can I make sure my hire is doing the work? How can I trust my hire with my company’s information? As such, as with any new employment model, fractional comes with fear mongering myths.
We will proceed with debunking the top myths associated with fractional workers through the lens of ops work.
Myth #1: the quality of work will diminish
One of the biggest concerns with fractional workers is whether working for multiple companies affects the quality of work:
Will a fractional worker be able to quickly switch contexts between the different companies and projects they’re working on?
Could fractional work interfere with or block my other teams?
Is it difficult for my regular team to work with a fractional worker?
To start off, the very nature of infrastructure work makes it easier to context switch between different companies and projects. Your application and infrastructure should be separate enough from one another that a fractional ops doesn’t have to do a deep dive into your app code in order to work on your infrastructure.
As such, infrastructure work should not affect the day-to-day tasks of your developers or other teams. Your app development, staging, and production should continue as-is until your infrastructure projects are complete, and the rollover to a new system or upgrade should also be seamless.
The bulk of the work lies in using infrastructure tools, which remain fairly consistent between different projects (for stack.io, those tools include Kubernetes, Docker, Terraform, and more).
Myth #2: they don’t have your best interest in mind
If you’re hiring fractional workers from another company, naturally they will have their employer’s best interest in mind. This may raise concerns like companies selling you projects that you don’t need, or overcharging you for work that you’re not as familiar with. However, at the end of the day, it’s still in the best interest of a company to do a good job if they want repeat business.
We can’t speak for other fractional ops teams, but at stack.io, one of our top values is transparency. Before doing any work for your infrastructure, we will always break down the costs and back up our recommendations with facts, so you can make the final decision. We would never do anything without your permission—no hidden fees here!
In a worse case scenario, if you work with a company that isn’t a fit for you, you can always find another that does have your best interest in mind. Fractional ops allows you to switch companies, and as a result, ops personnel, without too much overhead since the end product is yours to keep.
Myth #3: it’s not secure
There’s always worry around outsourcing any kind of work, namely around trusting third-parties with your company’s data. When it comes to fractional ops, there is a shared responsibility between both parties to keep your data secure.
For starters, a legitimate company accepting outsourced work will have a non-disclosure agreement (NDA). An NDA is a legal contract between you and the fractional ops team that ensures that the confidential information, knowledge, and materials you share are not leaked to additional third-parties.
However, even without an NDA, outsourcing infrastructure is relatively low risk. This is because, as previously touched upon, your infrastructure is separate enough from your app, that your fractional ops will not need access to your entire code base in order to complete their tasks.
Your fractional ops should only ask for the information that they need, and it’s ultimately up to you which parts of your infrastructure that you give them access to. As long as you maintain the principle of least privilege (PoLP), you can rest assured that the security risks of outsourcing to fractional ops are minimal.
One way that you can ensure PoLP is by off boarding each fractional ops personnel whenever they complete a task, and re-issue access, if needed. If you need help setting up this workflow for your fractional workers, stack.io can help you set it up for our work or any future fractional workers. At the end of the day, you’re always 100% in control of who has access to what.
Myth #4: there’s a higher risk of knowledge loss
When you outsource your work, your team may not learn the intricacies of the latest technologies, but in most cases, you don’t need to. In fact, outsourcing work could actually reduce your knowledge loss since your bus factor is always greater than 1.
If you outsource to a team of fractional ops, you can rest assured that even if the primary member working on your infrastructure leaves, that a company following best practices will have all of the knowledge documented and transferable between team members.
On top of that, since you get a product that you can keep, it should always come with documentation for you to perform maintenance and upgrades yourself later. Most fractional ops teams will also offer additional training and or documentation upon request for an additional fee.
Myth #5: it’s harder to adopt a DevOps culture
You always hear about how DevOps is a culture. “But how can someone be a part of your culture if they’re not always a part of your team?,” you may ask.
This all comes down to how DevOps culture should be a part of your entire workflow, not just the DevOps team. If your team develops a strong set of DevOps values, then it should be easy for your fractional ops to integrate into your culture and work with other teams to achieve your goals.
DevOps values allow your team to stay ahead of the competition and achieve your infrastructure goals. Similar to your core values, DevOps values will differ from team to team, but two examples of DevOps values from AWS include ownership and accountability. As previously mentioned, part of our DevOps culture is the value of transparency. We always encourage our clients to adopt transparency with us as well when informing us of their knowledge levels, expectations, and deadlines.
Preparing your team to work with fractional ops
So you think that fractional ops is right for you, but you don’t know how to get started. Here are a few things that you can do to help you transition into hiring fractional ops.
Create a separate set of centralized credentials for each user
Centralized credentials will help you keep your access secure and organized. You’ll know who has access to what at all times, and it makes it easy for each fractional ops working on your infrastructure to only request access to what they need. An example of centralized credentials would be AWS Identity and Access Management.
It’s simple: all you need to do is provide the credentials as a part of the onboarding process, and then then re-issue the key, change the password, or remove the account when off boarding. Your fractional ops team should be able to walk you through the process of implementing these credential restrictions, if needed.
Communicate using the official communication channels
Fractional ops sometimes will work in-house, but most of the time they are remote workers! As a result, it’s crucial that everyone uses the same set of communication channels. Otherwise, important information could be missed, which in a worse case scenario may lead to extra hours billed for you.
This can be done by setting up joint instant messaging channels, a ticketing system, shared GitHub repos, or all of the above. At stack.io, we have one main point of contact, our Technical Account Manager (TAM), who handles the communications between our team and yours to ensure that both parties are on the same page at all times.
What is a Technical Account Manager (TAM)?
At stack.io, your dedicated Technical Account Manager (TAM) will be your main point of contact for everything you need.
They will be available during core hours (9 A.M. - 5 P.M. ET), so that you can submit requests, ask questions, and get advice.
Have a review process in place
After a project is complete, you get to keep it and all of its components, which means that someone on your team needs to own the product. A review process not only helps you make sure that you are satisfied with the work completed, but it also helps ensure that you pinpoint anything that you don’t understand or need more documentation on.
An example of a review process would be Github’s issues and pull requests.
In addition, if you are in the habit of doing test-driven development, consider providing the fractional ops app tests that they can run after making changes to your infrastructure. This is a great way for them to test your app along the way, so that before a piece of work even makes it to review, it’s already met the standards set out by your team.
Help the fractional ops understand your infrastructure
The fractional ops team will have their own discovery process, but it's good practise for you to have your own onboarding process for fractional workers too. Often, you can just adapt your part-time or full-time process since many of the steps will overlap. This includes setting up accounts and providing the proper documentation on current infrastructure.
Be aware of your own infrastructure and how a team member fits in.
Conclusion
The rise of fractional ops means that you can tackle your infrastructure backlog without an entire team of DevOps personnel.
The tools available nowadays make it easy for a remote team of DevOps to easily work on your infrastructure, while maintaining security, best practices, and stellar communication with your team.
At the end of the process, you’ll receive an end product that likely would have taken you more time, effort, and money to learn and deploy.
Why waste time solving problems that someone else has already solved?
Take advantage of the tools available and increased automation in order to tackle your backlog and achieve your infrastructure goals.
Do you have any questions about how fractional operations fit in your team? Let us know.
